# レイヤリング ## 定義 レイヤリング(layering)は、『The Real Internet Architecture』がネットワークを合成する演算子として数える3つ(ブリッジング・レイヤリング・サブダクション、ch.1 §1.5)のうちの1つであり、著者らが「合成的ネットワークアーキテクチャを最も強く形づくる演算子」と位置づけるものである。その定義は次の一文に尽きる: **あるネットワーク(オーバーレイ、overlay。より高い抽象度を持つ側)のリンクが、別のネットワークまたはブリッジされたネットワークの集合(アンダーレイ、underlay)のセッションによって実装されるとき、そのネットワークはアンダーレイの上にレイヤリングされている**。リンクとセッションはどちらもあらゆるネットワークが持つ普遍的な通信チャネルの概念であるため、この定義に従えば任意の種類のネットワークを任意の他の種類のネットワークにレイヤリングできる。著者らはこれを「ネットワークをレゴブロックのように組み合わせ可能にする特徴」と呼ぶ。(Source: ch.1 §1.5, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.3.1) 機械上でオーバーレイのメンバーAが、同一機械上のアンダーレイのメンバーaから自身のネットワークサービスを得ることを「アタッチメント(attachment、Aのアタッチメントはa)」と呼ぶ。AがBへパケットを送るとき、aはこれを実装セッションプロトコルのメッセージにカプセル化する(オーバーレイパケットがペイロード、ヘッダ/フッタはアンダーレイのものになる)。bは受信時にデカプセル化してBへ届ける。オーバーレイはリンク上でパケットを送信(transmit)・取得(acquire)し、アンダーレイはセッションでメッセージを送信(send)・受信(receive)する、という用語で両者の視点を区別する。(Source: ch.3 §3.3.1) 「レイヤリングとは単にアンダーレイのサービスを使うことである」という別定義は不正確ではないが曖昧すぎる。著者らはこれを、古典的インターネットアーキテクチャにおける「単なる階層的依存(mere hierarchical dependency)」としてのレイヤリングへの逆戻りだと批判する(ch.1 §1.5.2)。古典的アーキテクチャでは各層が固定の機能集合を持ち、層間の関係は上から下への一方向依存にすぎないため、層間インタフェースは上下の機能に合わせて個別に設計せざるを得ず、ほとんどの潜在的なレイヤリングはインタフェースの非互換によって不可能になる。これに対し合成的ネットワークアーキテクチャの各層は、名前空間・ルーティング・転送・セッションプロトコル・ディレクトリを備えた「自己完結したネットワーク」であり、任意の2ネットワーク間のレイヤリングインタフェースは常に同一(リンクとセッション)になる。層の深さも古典アーキテクチャのように固定されず、無制約である。リンクとセッションという普遍概念で合成を厳密に定義することで、初めてモジュラーで汎用的な演算子が得られる。(Source: ch.1 §1.5.2) ## レイヤリングが可能にすること - **検証の分離**: 仮想リンクを持つネットワークは、実装セッションの期待される性能・論理的性質を事実または仮定としてオーバーレイモデルに与えることで、アンダーレイの詳細を知らなくても単独で分析・検証・シミュレーションできる。(Source: ch.3 §3.3.2) - **サービスに影響を与えない実装の交換**: サービスが完全に仕様化され約束通り実装される理想的な場合、レイヤリングは厳密にはオーバーレイのサービスに影響を与えない——アンダーレイは単なる実装手段だからである。同じオーバーレイを異なるアンダーレイに載せ替えても、オーバーレイのサービス自体は変わらない。(Source: ch.3 §3.3.2) - **ディレクトリという不可欠な補助機構**: 動的な仮想リンク(必要なときに生成・削除されるリンク)を持つレイヤリングには、オーバーレイの名前をアンダーレイの名前に対応づける「ディレクトリ(directory)」が必ず必要になる。ディレクトリはオーバーレイ側に置かれることも(依存階層を保つ本来の筋)、両者が密結合な場合には実装上の都合でアンダーレイ側に置かれることもある。ARP(Ethernet側)・DNS(Web側)・データセンターのルックアップテーブル(VXLAN側)は、いずれもこの「ディレクトリ」という同一役割の異なる実装である。(Source: ch.3 §3.3.2, §3.3.4.2, §3.3.5.4, §3.4.5.4) - **同一の合成メカニズムで実現される多様な目的**: 第3章の実例だけでも、性能向上(Resilient Overlay Networks)・プライバシー(Tor)・規模拡張(VLAN、階層化MPLS)・クラウド資源管理(VXLANによるテナントEthernetのデータセンターIPネットワークへのレイヤリング)と、目的は大きく異なるが、いずれも「オーバーレイのリンクをアンダーレイのセッションで実装する」という単一の定義の応用にすぎない。(Source: ch.3 §3.4.1-§3.4.5) - **エコシステムの進化**: レイヤリングのインタフェース(リンク/セッション)は、ネットワークへのユーザインタフェースとまったく同じ形をしている(第1章 図1.11、図1.13)。あるネットワークにとって、自分を利用しているのが分散システムなのかオーバーレイネットワークなのかは区別する必要がない。この対称性のおかげで、既存のIPプロトコル群を変更しないまま、新しいネットワークを上にレイヤリングするだけで新しい通信サービス・利用形態を自由に追加でき、インターネットが大きな変更なしに進化し続けられた「秘密」だと著者らは位置づける。(Source: ch.1 §1.5.1) ## 実インターネットにおけるレイヤリングの目的別の棚卸し(ch.4) RIA第4章は、第3章が個々の実例を通じて示したレイヤリングの汎用性を、**4つの目的別パターン**として体系的に棚卸しする(§4.2-§4.5)。同じ「オーバーレイのリンクをアンダーレイのセッションで実装する」という単一の定義が、目的が違えば異なる設計上の帰結を生むことを示す点が、この章の軸である。 - **目的1: 到達可能性のため(§4.2)**——1つのオーバーレイを複数の異質・非接続のアンダーレイの上にレイヤリングし、共通のパケット形式・プロトコルでアンダーレイどうしを到達可能にするパターン。base Internet自体がEthernet・Wi-Fi・PPP・MPLS等の異質なアンダーレイ群の上に成り立つ、インターネットの創設目的そのものである。設計上の帰結: アンダーレイの異質性を吸収するのがこのパターンの存在理由であり、オーバーレイは単一の抽象を提供すればよい。(Source: ch.4 §4.2, TABLE 4.1) - **目的2: ルーティングのスケーラビリティと柔軟性のため(§4.3)**——1つのオーバーレイと1つのアンダーレイの間で、ルーティング問題を2つの別々の問題に分解するパターン(§4.3.1)。IPトランジットネットワークのMPLS網へのレイヤリング(§4.3.2)は、グローバルBGPルーティングに参加するフォワーダ数を劇的に削減し集約度を上げるという定量的な効果を持つ。設計上の帰結: オーバーレイとアンダーレイが異なる時間スケールでルーティングを最適化する「層化されたNUM問題」(§4.3.3、LAOD)として定式化でき、両者の依存の向き(片方向か双方向か)が設計の性質を決める。(Source: ch.4 §4.3, TABLE 4.2) - **目的3: 資源共有すなわち「スライシング」のため(§4.4)**——複数のオーバーレイが1つのアンダーレイの上にレイヤリングされ、アンダーレイが資源を各オーバーレイへ配分するパターン。base Internetの資源をあらゆるアプリケーションネットワークが共有するという、最も普遍的な事例がこれに当たる。設計上の帰結: アンダーレイの容量が潤沢なら利用量の監視・制御は不要になりうるが(クラウドの通常運用)、容量が有限で実験の妥当性に孤立が必要な場合(VINI)は明示的な帯域割り当てが要る——同じスライシングでも、資源制約の有無が設計の分岐点になる。(Source: ch.4 §4.4, TABLE 4.3) - **目的4: 拡張インターネットサービスのため(§4.5)**——base Internetがしない(できない)ことを提供する仮想エッジネットワークを、base Internetの上にレイヤリングするパターン。他の3パターンと異なり、多くの場合サブダクション([[サブダクション]])との組み合わせを要する——仮想エッジネットワークのメンバーは、サービスを使わない他のインターネットメンバーとも通信する必要があるため、ブリッジングとレイヤリングを同時に行わねばならないからである。設計上の帰結: 目的1-3のパターンが「オーバーレイ/アンダーレイの純粋な階層」で閉じるのに対し、目的4はほぼ必然的にサブダクションという第3の演算子を要求する点で、4つの目的の中で唯一質的に異なる。(Source: ch.4 §4.5, TABLE 4.4) 4つの目的は互いに排他的ではない——例えばクラウドコンピューティングは目的2(テナントIPネットワークとデータセンターネットワークのルーティング分離)と目的3(データセンターネットワークの資源共有)の両方の表に現れ、これは「強調点の違い」にすぎないとRIA自身が明言する。また§4.5.3のAT&Tパケットの例は、単一のパケットの経路の中に目的1(コーヒーショップIPネットワークのWi-Fiへのレイヤリング)・目的2(4Gモバイルネットワークのbase Internetへのレイヤリング、ルーティングスケーラビリティのため)・目的3(アプリケーションネットワークのbase Internet資源共有)のすべてが同時に現れることを示し、現実のネットワークが単一目的のレイヤリングの積み重ねではなく、複数目的が同じ物理インフラの上で共存する複合体であることを裏づける。(Source: ch.4 §4.4, §4.5.3.1, §4.5.3.2) ## 横断的知見 - **第3章の実例列挙(RON・Tor・VLAN・階層化MPLS・クラウド)は「レイヤリングという単一メカニズムが多様な目的に使える」ことを示す帰納的な例示だったが、第4章はこれを目的別の4分類(到達可能性/ルーティングスケーラビリティ/資源共有/拡張サービス)として演繹的に体系化し、各目的が異なる設計上の帰結(アンダーレイの異質性吸収・時間スケール分離・資源制約への応答・サブダクションの要否)を持つことを明らかにする**: 第3章時点の本ページ(旧版)は「同一の合成メカニズムで実現される多様な目的」という横断的知見を蓄積していたが、これはあくまで単一ソース(RIA第3章)内での例示の並びから読み取れる帰納的な観察にとどまっていた。第4章は同じ現象を、著者ら自身の手で4つのパターンとTABLE 4.1-4.4という明示的な分類法に整理し直しており、「目的が違えば同じ定義でも設計上の帰結が違う」という、第3章だけでは見えなかった構造を与える。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 4 The Real Internet Architecture]] §4.2-§4.5) - **『The Real Internet Architecture』が定義するレイヤリング(リンクがセッションで実装される)と、『Computer Networks: A Systems Approach』第9章が定義するオーバーレイネットワーク(物理ネットワークの上に構築されトンネルで貫通する論理ネットワーク)は、同じ「物理の上に論理を重ねる」現象を異なる厳密さで記述している**: [[オーバーレイネットワーク]]概念が記録するSystems Approach第9章の定義は、オーバーレイの各ノードを「物理ネットワーク上にも存在する実ノード」、リンクを「物理ネットワークを貫くトンネル」と説明するにとどまり、標準化プロセスの外側で機能を試す実装上の動機(MBone・RON・end system multicast)に焦点を当てる。これに対しRIA第3章は同じ現象を「リンクがセッションで実装される」という形式的な定義に還元し、この定義さえ満たせば任意のネットワーク対に適用できる汎用演算子として位置づける。両者は矛盾しないが、Systems Approachが「なぜ・誰がオーバーレイを使うか」という実装動機を語るのに対し、RIAは「オーバーレイという現象を形式的に何と定義すればあらゆる場合に一般化できるか」という設計原理を語っており、記述の抽象度の違いが際立つ。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.3.1) - **VXLANという同一の技術が、レイヤリングの形式的定義(RIA)と「効率的で隔離された複製」という仮想化の錯覚(ネットワーク仮想化概念、LambdaNote第5章)という、異なる理論的枠組みから説明される**: [[ネットワーク仮想化]]概念はVL2・Nicira・VXLANを、Popek-Goldbergの「効率的で隔離された複製」という錯覚を実現する技術として位置づける。RIA第3章§3.4.5.3-4は同じVXLANを、テナントEthernetという具体的なオーバーレイがデータセンターIPネットワークというアンダーレイのUDPセッションで実装される、レイヤリングの厳密な定義の一事例として説明し、実装送信/受信テーブルやディレクトリとしてのルックアップテーブルといった実装の内部構造まで踏み込む。仮想化概念が「何を達成するか(利用者に対する錯覚)」を語るのに対し、レイヤリングの定義は「どう実装されるか(リンク/セッションの対応と状態管理)」を語っており、同じ技術の異なる側面を相補的に説明している。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] §5.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.4.5.3, §3.4.5.4) - **階層的MPLS(MPLS-on-MPLS)は、[[MPLS]]概念が記録するFEC・ラベルスワッピングという技術的仕組みだけでは説明が完結せず、レイヤリングの定義を適用して初めて「なぜMPLSリンクをMPLSセッションで実装するのか」という設計意図が見える**: [[MPLS]]概念はSystems Approach第4章に基づき、MPLSをFEC・ラベルスワッピング・LSRという抽象化で説明し、応用としてIP非対応機器の統合・明示的ルーティング・VPN構築の3つを挙げるが、MPLSネットワーク同士の階層化には触れていない。RIA第3章§3.4.4は同じMPLSについて、高速トランジットネットワークがBGP的な単一経路ルーティングでは音声/映像の優先度制御や高速障害復旧に対応できないという問題を、複数の長距離仮想リンクをそれぞれ別のMPLSセッションとして実装することで解決すると説明し、この「MPLSリンクがMPLSセッションで実装される」構造こそがレイヤリングの定義そのものであることを明らかにする。MPLS概念が記録する技術的機構(ラベルスワッピング)と、RIAが与える設計動機(優先度制御・高速障害復旧)は補完関係にある。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.4.4) - **「層(layer)」という同じ語を使いながら、RIAの合成的レイヤリングとSDNソフトウェアスタックの層は分割の軸が全く異なる**: 本ページの定義(RIA第1章・第3章)は、合成的ネットワークアーキテクチャの層間インタフェースが「常に同一」(リンクとセッション)になることをモジュール性の核心として強調する——どの2つのネットワークをレイヤリングしても、インタフェースの形は変わらない。これに対し*Software-Defined Networks: A Systems Approach*第3章が定義するSDNソフトウェアスタックの「層」は、ベアメタルスイッチ・Switch OS・Network OS・制御アプリケーションという4層それぞれが異なる役割を持つソフトウェアコンポーネントであり、層間インタフェース(「APIシム」)も層ごとに異なる具体的なプロトコル組み合わせ(制御アプリ⇔Network OSはgNMI・gNOI・FlowObjectives、Network OS⇔スイッチはgNMI・gNOIにP4RuntimeまたはOpenFlowを組み合わせたもの)として定義される。RIAの層がそれぞれ「自己完結したネットワーク」(名前空間・ルーティング・転送・セッションプロトコル・ディレクトリを備える)であるのに対し、SDNスタックの層はネットワークそのものの分割ではなく、単一のネットワーク(データプレーン)を制御するソフトウェアの役割分担の分割であり、RIAが批判する「単なる階層的依存」(層ごとに固定の機能集合を持ち、インタフェースを個別設計せざるを得ない構造)の形に近い。両者は「層」という語を共有しながら、前者はネットワークの合成を、後者はソフトウェアの役割分担を、それぞれ質的に異なる対象として分割している。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 1 Introduction]] §1.5.2, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.1) - **「層(layer)」という同じ語が指す第3の分割軸として、SONiCのUser Space/Kernel Space/Hardwareという実行特権・物理層に基づく分割がある。これはRIAの合成的レイヤリング(ネットワークの合成)ともSDNソフトウェアスタックの層(ソフトウェアの役割分担)とも異なる**: 本ページが既に記録する「層」の多義性(RIAの合成的レイヤリング vs. SDNソフトウェアスタックの層)に、[[SONiC]]([[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]] 図7.1)が示すUser Space(各種コンテナ内のモジュール群)・Kernel Space(Platform/Network/ASIC Drivers)・Hardwareという3層構造が第3の意味を加える。この分割は、OSのプロセス実行特権(ユーザー空間かカーネル空間か)と物理層の違いによる分割であり、RIAのように「どのネットワーク同士がリンク/セッションで合成されるか」を問うものでも、SDNスタックのように「制御アプリ・Network OS・Switch OS・ベアメタルスイッチという役割分担」を問うものでもない。SONiCの文脈では、User Space内でさらにサブシステム(コンテナ)への分割が行われており(§定義参照)、この意味でのSONiCの「サブシステム分割」はRIAが批判する「単なる階層的依存」に近い——各層(User/Kernel/Hardware)は固定の役割を持ち、層間インタフェースは(ドライバという形で)個別に設計される。3つの「層」概念はいずれも巨視的には「上位が下位に依存する」形を取るが、分割軸(ネットワークの合成/ソフトウェアの役割分担/OS実行特権と物理層)がそれぞれ独立であることが、3ソースの比較で初めて明確になる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]] ch.7 §7.1.1、[[@2024__PrincetonUP__The Real Internet Architecture - Chapter 1 Introduction]] §1.5.2、[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.1) ## 未解決の問い - SDNソフトウェアスタック(ch.3)の層間APIシムは、層ごとに個別設計された具体的なプロトコル組み合わせであり、RIAが批判する「単なる階層的依存」に近い構造に見える。RIA自身がSDNのようなコントロール/データプレーン分離アーキテクチャをレイヤリングの枠組みでどう位置づけるのか(あるいは位置づけないのか)は、本wikiではまだ検証できていない。RIA第6章のP4プロトタイプ実装([[P4]]エンティティが既に記録)がこの接続の手がかりになる可能性がある。 - RIA第1章§1.5.2が古典的インターネットアーキテクチャを「層間関係が単なる一方向依存にすぎない」と批判する一方、Systems Approach第9章のオーバーレイの語りは古典的な階層モデルへの明示的な対比を持たない。両者を接続すると、Systems Approachが暗黙に前提する「レイヤリング=階層的依存」という理解は、RIAの批判が正しく当てはまる典型例なのか、それとも既にリンク/セッションに近い実装(トンネル)を暗黙に取っており批判の対象外なのか、本wikiではまだ判定できない。 - RIA第3章はレイヤリングを「サービスに影響を与えない実装の交換」と位置づけるが、これは「サービスが完全に仕様化され約束通り実装される理想的な場合」に限定されている。現実の(underspecifiedな、あるいは実装に欠陥のある)ネットワークでは、レイヤリングの選択(どのアンダーレイを使うか)がオーバーレイのサービスにどう漏れ出すか、本章は詳細を明かさない。第4章・第5章での深掘りが必要。 - ディレクトリ(ARP・DNS・VXLANのルックアップテーブル)をオーバーレイ側に置くかアンダーレイ側に置くかの選択は、本章では「実装上の都合」としか説明されない。この選択が生むトレードオフ(依存階層の純粋性 対 実装効率)を定量的・体系的に論じた文献は本wikiにまだない。 - ~~第4章はレイヤリングの全事例を比較・要約すると予告されている(ch.3 §3.3.2)。第4章のingest後、本ページの「レイヤリングが可能にすること」節を実インターネットの階層棚卸しの観点から拡張する余地がある。~~ → **解決**: 第4章は「レイヤリングが可能にすること」を拡張するのではなく、目的別の4分類(到達可能性・ルーティングスケーラビリティ・資源共有・拡張サービス)という独立した軸を導入した。上記「実インターネットにおけるレイヤリングの目的別の棚卸し(ch.4)」節に統合済み。 - 第4章§4.5は、拡張サービスのための目的4だけが他の3目的と異なりサブダクションをほぼ必然的に要求すると読める。しかしなぜ目的1-3(到達可能性・ルーティングスケーラビリティ・資源共有)ではサブダクションが必要にならないのかについて、本書は明示的な一般論を与えていない——個別の実例からの帰納にとどまる。目的とサブダクションの必要性の関係を一般的に特徴づける理論は、第5章・第6章で示されるか。 - 第4章§4.3.3が要約するLAOD(Layering As Optimization Decomposition)の「層化されたNUM問題」は、目的2(ルーティングスケーラビリティ)の定量モデルとして提示されるが、目的1・3・4のレイヤリングにも同様の定量モデルが適用できるかは本書では検討されていない。特に目的3(スライシング)は資源配分そのものが主題であり、NUM問題の枠組みと親和性が高いように見えるが、本書はこの接続を明示的には論じない。 ## 関連 - ソース: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 1 Introduction]](§1.5 合成演算子の導入、§1.5.1 ユーザインタフェースとの対称性、§1.5.2 古典的アーキテクチャとの比較) / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]](§3.3-§3.4 定義と実例) / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 4 The Real Internet Architecture]](§4.2-§4.5 目的別4分類の棚卸し) / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]](SDNソフトウェアスタックの層構造。RIAのレイヤリングとは分割の軸が異なる対照例) - 概念: [[ブリッジング]](もう一つの合成演算子) / [[サブダクション]](拡張サービスの目的でほぼ必然的に組み合わされる第3の演算子) / [[オーバーレイネットワーク]] / [[ネットワーク仮想化]] / [[MPLS]] / [[階層的ルーティングとアドレス集約]] / [[シムレイヤー]] / [[砂時計モデル]] / [[ソフトウェア定義ネットワーク]] - 実体: [[The Real Internet Architecture]] / [[SONiC]] ## 出典 - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 1, §1.5; Chapter 3, §3.3, §3.4; Chapter 4, §4.2-§4.5. - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.4. https://book.systemsapproach.org/applications.html - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 4: Advanced Internetworking, §4.4. https://book.systemsapproach.org/scaling.html - 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第5章 §5.4. - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]](SDNソフトウェアスタックの4層構造と層間APIシム。ch.3 §3.1) - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第7章 §7.1.1(図7.1 User Space/Kernel Space/Hardwareの3層構造).