システム アプローチ数週間前、私は「Traceroute は現実ではない」というタイトルの記事を偶然見つけました。これはかなり面白い記事でしたが、ところどころ正しくない点もありました。
タイトルは「鳥は実在しない」というよく知られた風刺的な陰謀論を暗示していると推測します。ですから、この記事も風刺として読むべきかもしれません。私が批評する必要はありません。その仕事はHacker Newsの精力的な寄稿者たちが引き受けており、彼らは今回、非常に優れた批評をしてくれました。
トレースルートのエッセイの中で私が注目したのは、「[MPLS] がトレースルートの期待に応えることはまったく不可能である」という主張です。
これは間違っているとわかっているだけでなく、1996 年にシスコの同僚とタグ スイッチング ヘッダーを設計していたときに、MPLS が traceroute をサポートするようになった経緯を鮮明に覚えています。
(MPLS (マルチプロトコル ラベル スイッチング) は、タグ スイッチングの設計にかなり直接従った IETF 標準であり、ヘッダーはほぼ同じです。)
MPLSの技術史を直接語り直す
コンテクスト
これは白熱した議論だったので、今でも鮮明に覚えています。典型的な「委員会による設計」の状況で、こういった状況が一般的にどうなるかはよく知られています（48バイトセルなど）。とはいえ、最終的には、このケースの方がはるかに優れていたと思います。さて、タイムマシンを1996年まで巻き戻して、MPLSヘッダーが現在の形になり、tracerouteの設定変更も可能になった経緯を振り返ってみましょう。
ルーター会社でのラベルデザイン
1995年にシスコに入社し、当時としては画期的で画期的なATM技術を、シスコのIP中心の製品ラインにどう「統合」できるかを模索するチームの一員となりました。当時すでに多くのアイデアが浮上しており、IETFとATMフォーラムではIP over ATMの標準規格が策定されていました。
1996年初頭、シスコ社内のエンジニア6名ほどが、この「統合」がどのようなものになるかについてアイデアを共有していた頃、ヤコフ・レクターがタグスイッチングの基本的な考え方を概説した2ページの文書を送ってきました。それを読んだとき、このアイデアは私がこれまで見てきたものや議論してきたものすべてよりも質的に優れているように思えました。同僚たちも同意しました。
私たちは、この2ページをアーキテクチャとして具体化し、ルータとATMスイッチの両方を含むシスコ製品ラインへの実装を進めるために、経営陣の支援を迅速に得ることができました。そして、実装を開始する前に決定する必要のある詳細事項の検討に着手しました。重要な詳細事項の一つは、タグスイッチパケットのパケットヘッダーフォーマットでした。
ここで、当時存在していた関連アイデアのいくつかについて触れておくことが重要です。ヤコフの2ページの論文が私たちの設計チームの支持を得た後、私たちがまだ公の場でそれについて多くを語る前に、Ipsilonというスタートアップ企業がステルスモードから抜け出し、次々と発表を行いました。彼らはまた、IPルーティングとATMスイッチングを組み合わせる方法も考案し、そのアプローチを巧みに「IPスイッチング」と名付けました。
彼らの設計は私たちのものとは全く異なっていましたが、当時としては斬新なアイデアとして、システムを動作させるプロトコルを解説する複数の情報RFCを公開するなど、大きな反響を呼びました。Ipsilonをめぐる話題性の高さのおかげで、タグスイッチングに対する経営陣の支持を得るのがはるかに容易だったと言っても過言ではありません。
その後、固定長ラベルをルーティングテーブルの可変長IPプレフィックスに関連付けるというタグスイッチングの中心的なアイデアは、1995年のSIGCOMMでGirish Chandranmenon氏とGeorge Varghese氏によって発明・発表されていたことが判明しました。彼らはそれを「スレッドインデックス」と呼んでいました。この論文はYakov氏の2ページの論文よりも明らかに古いものなので、タグスイッチングとMPLSのこの核となる側面の真の発明者は彼らだと言えるでしょう。
しかし、Yakov の論文も 1995 年の SIGCOMM 論文も、IP パケット内の固定長ラベルをどのようにエンコードするかという問題については触れていませんでした。
1996年に入手可能な最速のルーターを購入したISPの大きな基盤があり、彼らは意見を持っていました
Ipsilonのアプローチは、固定長ラベルを伝送するためにATMセルヘッダーに依存していました。これは、すべてのトラフィックを48バイトのセルで送信することに問題がなければ良いアイデアでしたが、ほとんどのお客様はそれを望んでいませんでした。もちろん、単一の顧客視点などというものは存在しませんでしたが、1996年に入手可能な最速のルーターを購入したISP顧客の大規模な基盤があり、彼らから様々な意見が寄せられていました。
彼らの多くはATMを激しく嫌っていました。当時はネットヘッド対ベルヘッドの戦いが激化しており、その理由の一つは「セル税」でした。ATMはペイロード48バイトごとにヘッダー5バイト（10%以上）のオーバーヘッド（税）を常に課していましたが、これは最良のケースでした。対照的に、20バイトのIPヘッダーは1500バイト以上のパケットで償却可能でした（2%未満）。
当時の平均パケットサイズが約300バイトだったにもかかわらず、IPははるかに効率的でした。また、ATMセル税はIPヘッダーのオーバーヘッドに加えて発生しました。ISPは高速リンクに多額の費用を支払っており、その効率的な利用に熱心でした。
そのため、タグ スイッチング/MPLS で直面した問題は、固定長のラベルを伝送するために IP ヘッダーの上に追加のヘッダーを配置することで、「ラベル タックス」を導入しようとしていたことでした。
ヘッダーを可能な限り小さく保つというインセンティブがありました。設計委員会の一部のメンバーにとっては、それが最も重要な考慮事項でした。しかし、ヘッダーにはラベル以外にも多くのものを詰め込む必要がありました。ラベルはパケット転送を簡素化するためのものなので、（通常）ルーターにラベルヘッダー以外の情報を参照させることはできませんでした。したがって、転送に影響を与えるフィールドはすべてラベルヘッダーに含める必要がありました。
そのようなフィールドの一つに、「サービスクラス」があります。これはIPヘッダーの「サービスタイプ」（ToS）をモデルとしています。ToSの使用法はこの時点では標準化されていませんでしたが、過負荷のルーターに到着したルーティングプロトコルパケットを優先処理するようマークするといった用途に使用されていました。（これらのビットは、後の差別化サービスに関する作業で徹底的に再定義されました。）
当然の選択は、ラベルヘッダーにToSの1バイト全体を含めることでした。しかし、ヘッダーを最小化したいというプレッシャーと、ToSが広く普及していないことを踏まえ、当初は「Class of Service（サービスクラス）」と呼ばれ、後にRFC 3032で「Experimental（実験的）」に改名された3ビットで妥協することになりました。
これは、1996年当時、IPトラフィックに異なるサービスクラスを提供する試みは明らかに実験段階であったという事実を踏まえたものでした。Diff-Serv標準（ToSバイトの6ビットを使用）が登場し、それをMPLSにマッピングしようとした際に、この決定は大きな痛手となりました。（余談ですが、MPLSとDiff-Servの融合領域における私の研究は、おそらくIETFへの最も生産的な貢献だったと思います。）
タグヘッダーに不可欠だとすぐに判断したもう一つのフィールドは、Time-to-Live（TTL）でした。分散ルーティングアルゴリズムの性質上、一時的なループが発生する可能性があり、ループに陥ったパケットは転送リソースを消費し、ループを解消するための更新処理に支障をきたす可能性があります。ラベル付きパケットは（通常）IPルーティングによって確立されたパスを辿るため、TTLは交渉の余地がありませんでした。TTLを8ビット未満にすることも一瞬検討したかもしれませんが（255ホップまでカウントする必要なんてあるでしょうか？）、そのアイデアは却下されました。
ルートアカウント
それでtracerouteの話になります。「tracerouteなんて存在しない」と言っている読者とは違い、私たちはtracerouteの仕組みを理解しており、デバッグに重要なツールだと考えていました。tracerouteはTTLの短いパケットがTTLの期限切れによって破棄されることを前提としているため、どんなトンネルでもtracerouteを動作させる非常に簡単な方法があります。
パケットがトンネルに入る際（ラベルヘッダーが追加される際）に、IP TTLをラベルヘッダーにコピーします。そして、ホップごとに外側のラベルヘッダーのTTLをデクリメントし、トンネルから出る際に外側のTTLを内側のヘッダー（IP TTL）にコピーします。つまり、TTLはトンネルがない場合と全く同じ動作をします。トンネルの途中でTTLが期限切れになる場合、まさにその動作が起こります。
ISPは、ランダムなエンドユーザーがtracerouteを実行することで内部トポロジーを把握できるという事実を好ましく思っていなかった。
トンネルの途中で「ICMP time exceeded」メッセージをどう処理するかという小さな問題がありますが、これはRFC 3032で詳細に説明されています。言い換えれば、MPLSはtracerouteの動作を妨げることはありません。興味深いことに、以前のトンネリングプロトコルであるGREはMPLSと同じ処理を許可していますが、必須ではありません（つまり、GREはtracerouteを破ることができるかどうかです）。
しかし、この話にはもう一つの展開がある。
ISPは、tracerouteを実行することでランダムなエンドユーザーが内部トポロジーを把握できることを好ましく思っていませんでした。そして、MPLS（またはその他のトンネリング技術）は、ISPにとってトポロジーを隠蔽する完璧なツールとなりました。
まず、内部ルータがICMP時間超過メッセージを送信しないようにすることができます。また、パケットがトンネルを出る際のTTLを偽装することも可能です。出力時に外側（MPLS）TTLを内側（IP）TTLにコピーするのではなく、IP TTLを1だけ減らすのです。すると、トンネルパス上に実際にいくつのルータホップが存在するかに関わらず、パケットがトンネルを通過する際にIP TTLは1だけ減算されるため、トンネルは（tracerouteにとって）1ホップのように見えます。私たちはこれを実装で設定可能なオプションとし、RFC 3032で対応させました。
社内では、ISPに出口のTTLを加算するオプションを与えて、トンネルのホップ数がマイナスに見えるようにする、というジョークもありました。ホップ数が多すぎることでネットワークが非効率に見えるのは誰も望んでいませんでした。（TTLの本来の目的はループパケットを破棄することなので、これはひどいアイデアですが、それでも大笑いしました。）
- TCPの輻輳制御がインターネットを救った方法
- コンピュータネットワークの60周年を記念する時が来た
- えーと、ネットワーク自動化では一体何が起こったのでしょうか?
- ネットワークセキュリティについて書くべきではないこと – 経験から語る
いずれにせよ、トンネル経由の traceroute をサポートしないのはオペレータの選択であり、MPLS (またはその他のトンネル技術) に組み込まれた機能/バグではありません。
この話にはまだまだ続きがあります。例えば、ラベルをスタックとして考えるようになった経緯などですが、それはまた別の機会に。MPLSラベルヘッダーの最小サイズを32ビットに抑えるためにあれほど苦労しなかったらよかったのに、と少し後悔しています。しかし、tracerouteを壊すことはしませんでした。ISP側が壊すことを望まない限りは。そして、ラベル税について苦情を言われることなく、ほぼすべてのISPのネットワークにMPLSを導入することができました。
決してすべてが正しく行われたわけではありませんが、ほとんどの利害関係者にとって有効な一連のトレードオフを実現しました。®
