オーバーレイネットワーク - yuuk1's Digital Garden

# オーバーレイネットワーク ## 定義オーバーレイネットワーク(overlay network)とは、既存の物理ネットワークの上に構築される論理ネットワークである。オーバーレイの各ノードは物理ネットワーク上にも存在する実ノードであり、アプリケーション固有の方法でパケットを処理・転送する。オーバーレイノード間のリンクは物理ネットワークを貫くトンネルとして実装され、中間のオーバーレイノードは内側ヘッダ(IHdr)に基づき転送判断を行ったうえで外側ヘッダ(OHdr)を付与して物理ネットワークへ送出する。オーバーレイのアドレス空間は物理ネットワークのアドレス空間と一致する必要がなく、URL・ドメイン名・XMLクエリ、あるいはパケットの中身そのものに基づくルーティングも可能である。複数のオーバーレイが同一の物理基盤上に並存でき、オーバーレイを何重にも積み重ねる(ネストする)こともできる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4) 著者はオーバーレイネットワークを、ルータやスイッチを標準化プロセスを経ずに拡張できる「インターネットへ新機能を導入する主流の手段」として位置づける。ネットワーク事業者や企業の管理者が見知らぬ他者の作ったソフトウェアを自社のルータに載せることは決してないため、実験的な機能(新しいIPのバージョン、新しいルーティング戦略、新しい検索アルゴリズム)を試すには、ルータそのものではなくエンドホスト上でオーバーレイとして実装し、既存ルータをトンネルで貫通する以外に現実的な選択肢がない。本章が扱う具体例は大きく3系統に分かれる。(1) ルーティングオーバーレイ(MBone・6-BONE・end system multicast・RON)、(2) ピアツーピアネットワーク(Gnutella・構造化オーバーレイ・BitTorrent)、(3) コンテンツ配信ネットワーク([[コンテンツ配信ネットワーク]]を参照)。(Source: ch.9 §9.4, §9.4.1) **ルーティングオーバーレイ**は追加のアプリケーション層処理を持たず、代替の経路制御戦略だけを提供する。MBoneはIPマルチキャストをユニキャストルーティングの上にオーバーレイとして実装し、6-BONEはIPv4ルータをトンネルで貫通してIPv6を段階展開した。end system multicastはルータの協力なしにホストだけでメッシュオーバーレイを構築し、その上でDVMRPのようなマルチキャストルーティングアルゴリズムを走らせてマルチキャストツリーを得るという2段階の設計を取る。RON(Resilient Overlay Network)は、BGPが必ずしも最短経路を選ばずポリシーに強く左右される結果、インターネットでは三角不等式が成立しないという観測を突き、数十ノード規模でN×N の能動的経路品質監視を行い最適経路への切り替えと障害からの高速回復(2001年の実測で64時間・32件の障害を平均20秒未満で回復)を実現した。RONの発想は今日のSD-WANという商用の名前で実践されている。(Source: ch.9 §9.4.1) **ピアツーピアネットワーク**もオーバーレイの一種であり、ノードは共有したいオブジェクトを持つホスト、リンク(トンネル)はオブジェクトを探すために辿るホストの列を表す。Gnutellaのような非構造化オーバーレイはTTL付きの`QUERY`メッセージをフラッディングし信頼性の高い検索を得る代わりにスケールしない。Pastry等の構造化オーバーレイは[[一貫性ハッシュ法]]によりノードとオブジェクトを同じ大きなID空間へ配置し、共有プレフィックスに基づくルーティングテーブルで対象ノードへ$log_{16}N$ホップ程度で到達する分散ハッシュテーブル(DHT)を構成する。BitTorrentはファイルをピース単位に分割・複製し、trackerまたはDHTベースの「peer finder」ネットワークでピア発見を行い、chokingによる互恵的な帯域配分でフリーライドを抑止する。(Source: ch.9 §9.4.2) 『The Real Internet Architecture』第3章は、オーバーレイネットワークという語そのものを定義することはせず、代わりに[[レイヤリング]]というより一般的な合成演算子の一事例としてオーバーレイを扱う。第3章の定義では、オーバーレイとは「レイヤリング関係において、リンクがアンダーレイのセッションによって実装される側(=より高い抽象度を持つ側)のネットワーク」にすぎない。この定義に従えば、RON・Tor・VLAN・階層化MPLSネットワーク・データセンターのテナントEthernet(VXLAN)はすべて「オーバーレイ」であり、レイヤリングの厳密な定義(リンクとセッションの対応、ディレクトリによる名前解決)さえ満たせば、トンネル技術やアプリケーション層かどうかを問わずオーバーレイと呼べることになる。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.3.1, §3.4) ## 横断的知見 - **ch.9のオーバーレイはアプリケーション層でエンドホストが構築する論理ネットワークだが、[[ネットワーク仮想化]]が扱うVXLAN・MPLS VPNはネットワーク基盤(スイッチ・ルータ・データセンターファブリック)そのものがトンネルでオーバーレイを構築するという、同じ「物理の上に論理を重ねる」原理の異なる実装層を示す**: 本ページの定義は「エンドホストが物理ルータの協力なしにトンネルでオーバーレイを構築する」という、ネットワーク事業者の統制が及ばない場所での機能導入手段としてオーバーレイを説明する(end system multicast・RON・Gnutella等はいずれもホストのみで完結する)。これに対し[[ネットワーク仮想化]]が記録するVXLANは、まさにデータセンターのネットワーク機器自身がVXLANトンネルエンドポイント(VTEP)としてオーバーレイを構築し、24ビットのVirtual Network Idで数百万規模のテナントを分離する仕組みである。同様にMPLSレイヤ3 VPNは、サービスプロバイダのルータがラベルスタックによるトンネルとBGPによる経路配布でオーバーレイを実現する。両者とも「物理ネットワークの上に論理ネットワークを重ねる」という本ページのKey Takeaway(virtualization)と同一の原理に立つが、ch.9の系譜(P2P・end system multicast)は標準化プロセスの外側でエンドホストが機能を持ち込む手段としてオーバーレイを使うのに対し、VXLAN/MPLS VPNの系譜はネットワーク運用者自身が正規の手段としてオーバーレイを使う点で、担い手と統制の主体が対照的である。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] Perspective, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.4.3) - **RONが体現する「標準化を経ずに機能を試す」という設計動機は、[[砂時計モデル]]が論じる遅延バインディング(late binding)の実践例として読める**: [[砂時計モデル]]は、複雑な意思決定を設計プロセスの後半まで遅らせることでくびれを最小に保つという原則を、TCP・TLS・DHCP・URIといった「くびれの外で積み上がった機能」の系譜から論じてきた。本ページが扱うRON・end system multicast・MBoneはいずれも、IPくびれやルータの標準化プロセスを経ずに新しい経路制御・マルチキャスト機能をエンドホスト上のオーバーレイとして先に試すという、遅延バインディングと同型の設計判断を示す。すなわち、オーバーレイは「くびれの外側で新機能が実験され、実証されたものだけが正規の層(ルータ機能・標準プロトコル)に昇格する」という、砂時計モデルが描くくびれの動的な性質を、個々の技術のライフサイクルとして具体化したものと解釈できる。ただしこの解釈は本ページの独自の統合であり、両章が明示的にこの接続を論じているわけではない点に注意。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.1) - **『The Real Internet Architecture』第5章は、オーバーレイを「エンドホストが標準化プロセスの外側で機能を導入する手段」としてではなく、既存の合成メカニズム(新セッションプロトコル・ミドルボックス挿入・特殊用途ルーティング)を全て内包する最強の単一メカニズムとして定義し直す**: 本ページの定義(ch.9出典)は、オーバーレイを「ルータの協力なしにトンネルで構築される論理ネットワーク」という実装面から説明し、標準化プロセスの外側で機能を試す手段(end system multicast・RON・Gnutella)として位置づけていた。[[@2024__PrincetonUP__The Real Internet Architecture - Chapter 5 Patterns for Enhanced Network Services]] §5.5.4は同じ対象をアーキテクチャ論の側から捉え直し、レイヤリング(オーバーレイの追加)は新しいセッションプロトコルの導入・ミドルボックス挿入・特殊用途ルーティングという他の全ての拡張メカニズムを内包できる点で「一挙に手に入れる('having it all')」最強のメカニズムだと位置づける。具体例として、Torの長寿命な仮想リンク(ユーザーセッションより永続的でオーバーレイ効率とプライバシー保護を両立)、SEATTLEのEthernet規模でのモビリティ対応(単一の論理集中フォワーディングテーブルをシャーディングして実現)、内側/外側2つのネットワークヘッダによるミドルボックス挿入時の名前変換問題の自動解決(図5.7)を挙げる。ch.9の「標準化を経ずに機能を導入する手段」という説明とch.5の「複数メカニズムの統合」という説明は矛盾せず、前者が誰がなぜオーバーレイを使うかを、後者がなぜオーバーレイがそれほど強力かを補完的に説明している。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4, §9.4.1, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 5 Patterns for Enhanced Network Services]] §5.5.4) - **RONが持つ性能監視ベースの経路選択と、TRIA第5章が一般化する「オーバーレイの特殊用途ルーティング」は、同一の設計パターンの実例と再解釈の関係にある**: 本ページはRON(Resilient Overlay Network)を、BGPが三角不等式を満たさないという観測に基づき能動的経路品質監視で最適経路への切り替えを行う個別の研究成果として記録していた。TRIA第5章§5.5.4.3は、この振る舞いを「オーバーレイはアンダーレイより少ないメンバー数を持つため、ルーティング問題がより小さく管理しやすくなる」という一般原理の一事例として再配置し、同じ原理の他の実例としてモビリティ・マルチキャストの特殊ルーティング(§5.6・§5.7)を並置する。RONの個別最適化がなぜアーキテクチャ的に可能なのかを、TRIAは「メンバー数の少なさ」という構造的理由に還元して説明している。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4.1, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 5 Patterns for Enhanced Network Services]] §5.5.4.3) - **TRIA第3章はオーバーレイを独立した概念として定義せず、[[レイヤリング]]という演算子の一事例に還元することで、第9章・第5章が個別に論じてきた多様なオーバーレイ(RON・Tor・P2P・CDN)を単一の形式的定義の下に統合する**: 本ページがこれまで蓄積してきた知見は、ch.9(実装動機からの説明)とTRIA第5章(「having it all」という強力さの説明)という、いずれも「オーバーレイとは何であるか」を前提としたうえでの議論だった。これに対しTRIA第3章は「オーバーレイ」という語自体を第一級の概念として立てず、レイヤリング(リンクがセッションで実装されるという関係)における抽象度の高い側を指す相対的な役割にすぎないと位置づける。この視点では、RON(§3.4.1)・Tor(§3.4.2)・VLAN(§3.4.3)・階層化MPLS(§3.4.4)・データセンターのテナントEthernet(§3.4.5)はすべて同一の定義の異なる実例であり、「オーバーレイの一般的な性質」を論じるにはオーバーレイ概念そのものよりも[[レイヤリング]]概念の方が基礎的な単位になる。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.3.1, §3.4) - **VXLANの具体的な誕生経緯(SDN本第1章)は、本ページが記録する「オーバーレイは内側ヘッダ(IHdr)で転送判断を行い外側ヘッダ(OHdr)を付与して物理ネットワークへ送出する」という一般的な構造(ch.9)の、運用者主導オーバーレイにおける具体例を与える**: 本ページの定義(ch.9出典)は、オーバーレイの一般的なパケット処理を内側/外側ヘッダの対として説明するが、具体的なヘッダフォーマットには立ち入らない。*Software-Defined Networks: A Systems Approach* 第1章§1.2.3は、この一般構造の一具体例としてVXLANの誕生経緯を語る——VLANタグの4096通りという空間がクラウドの全テナントを収容するには不十分になったため、IETFが導入したVXLANは、従来手法(仮想化されたEthernetフレームを別のEthernetフレームでカプセル化)と異なり、仮想Ethernetフレームを丸ごとUDPパケット(=IHdrに対するOHdr)でカプセル化する。VXLANは[[ネットワーク仮想化]]概念が既に記録するVTEP・24ビットVirtual Network Idという運用面の説明を、なぜこの方式(UDPカプセル化)が選ばれたのかというプロトコル史の側面から補完する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.3, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.4) - **GENEVE(ch.8)は、VXLAN(ch.1)が抱えていたヘッダ空間の限界を、可変長オプションという形で解決した後継カプセル化であり、両者は同じ問題系列の連続する2世代を示す**: 本ページの既存の知見は、VXLAN誕生の経緯を「VLANタグの4096通りという空間がクラウドの全テナントを収容するには不十分になった」という**アドレス空間の限界**への対応として記録していた([[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] §1.2.3)。[[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] §8.3.1が説明するGENEVEは、これとは別の限界——VXLANヘッダの限られた空間ではトンネルの片端から他端へ仮想ネットワークに関するメタデータ(パケットの論理送信元ポート等)を渡すのに不十分だったという**メタデータ運搬容量の限界**——に対応する。両者はVXLANという同一のカプセル化に対して異なる時期に異なる限界が露呈した2世代の解決策であり、GENEVEはVXLANとよく似たヘッダ構造を保ちながら可変長オプションを追加することで、ソフトウェア実装者(Nicira等)が求める拡張性とハードウェア実装者が求める固定ヘッダの扱いやすさの妥協点を模索した。IETFの標準化プロセスを経て生まれた点もVXLANと共通する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.3, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.3.1) - **RFC 7348(VXLAN 本体)を一次資料として読むと、本ページが ch.9 由来で記録する「オーバーレイは内側ヘッダ(IHdr)で転送判断を行い外側ヘッダ(OHdr)を付与して物理ネットワークへ送出する」という一般構造を、運用者主導オーバーレイの最も具体的なレベルで確認できる**: RFC 7348 §5 は VXLAN のカプセル化を、内側 MAC フレーム(IHdr に相当)に VXLAN Header(8 byte、24 bit VNI)・Outer UDP/IP/Ethernet Header(OHdr に相当)を順にプリペンドする4層構造として定義する。VTEP(VXLAN Tunnel End Point)はハイパーバイザー内・物理スイッチ・物理サーバのいずれにも実装可能なステートレスなトンネル終端であり、VM 自身は一切それを意識しない。この一次資料の精度は、SDN 本第1章が要約する「VLAN タグの4096通り不足への対応」という誕生経緯の記述よりも踏み込み、STP/マルチパスの制約・マルチテナント隔離・ToR テーブルサイズ不足という3つの独立した動機(RFC §3)を明らかにする。(Source: [[@2014__RFC__Virtual eXtensible Local Area Network (VXLAN) - A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks]] §3, §4, §5) - **RFC 8365(EVPN の NVO 転用仕様)は、本ページが記録する「運用者主導オーバーレイ」(VXLAN・階層化MPLS・データセンターのテナントEthernet)に、制御プレーンという第4のレイヤーを明示的に追加する**: 本ページの既存の知見は、TRIA第3章がVXLANを「レイヤリング関係において、リンクがアンダーレイのセッションによって実装される側」と定義することで、RON・Tor・VLAN・階層化MPLS・データセンターのテナントEthernetを単一の形式的定義の下に統合してきた(§3.3.1, §3.4)。しかしこの定義はいずれもデータプレーン(トンネルによるリンクの実装)の話であり、そのオーバーレイ上で MAC/IP アドレスをどう学習・配布するか(制御プレーン)には立ち入らない。[[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]] は、VXLAN・NVGRE・MPLS over GRE というデータプレーンカプセル化の上に [[EVPN]](BGP ベースの制御プレーン)を載せる標準的な組み合わせを定義しており、「オーバーレイをレイヤリングの一事例として形式化する」という TRIA のデータプレーン中心の枠組みに、運用者主導オーバーレイが実際にどう制御プレーンを持つかという層を付け加える。(Source: [[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]] §1, §5.1) ## 未解決の問い - GENEVEはVXLANの限界(メタデータ運搬容量の不足)を解決するものとして設計されたが、ch.8はGENEVEが実運用でVXLANをどこまで置き換えているか、あるいは両者が併存し続けているかには触れていない。VXLANの広範な普及(2012年以降のデータセンター実装)とGENEVEの標準化(RFC 8926)の間には数年の空白があり、この間のカプセル化選択の実態は本wikiではまだ追えていない。 - TRIA第5章が示す「オーバーレイはメンバー数が少ないほどルーティング問題が管理しやすくなる」という原理は、本ページが記録するRONのスケーラビリティ限界(数十ノード規模でのN×N監視)を裏から説明しているように見えるが、TRIA自身はこの数値的な限界には触れていない。RONの実測データとTRIAの一般原理を定量的に突き合わせる余地がある。 - RON論文が示した「数十ノード規模でのN×N監視」というスケーラビリティの限界は、SD-WANという商用実装でどう克服されているか(あるいは克服されず、SD-WANも同様に小規模な拠点間接続に用途が限定されているか)は、ch.9の記述だけでは判断できない。 - end system multicastが構築するメッシュオーバーレイの品質(物理トポロジをどれだけ正確に近似できるか)は、本章では「両方の実験・実運用経験が良好な結果を示唆する」とされるにとどまり、定量的な評価指標は示されない。 - オーバーレイがルータの統制外で機能を導入する手段だとすれば、ネットワーク運用者がオーバーレイトラフィックを識別・規制する動機(輻輳制御の公平性、セキュリティポリシー)とオーバーレイ側の要求はどう調停されるか。本章はRONの「オーバーレイが乱立したときネットワークが持つか」という問いを未解決のまま残す。 - [[ネットワーク仮想化]]が扱うVXLAN/MPLS VPNのような「運用者主導のオーバーレイ」と、本ページが扱う「エンドホスト主導のオーバーレイ」を統一的に分類する枠組みは、本wikiではまだ構築されていない。オーバーレイの分類軸(誰が構築するか、標準化の有無、隔離目的か機能拡張目的か)を整理した文献の追加ingestが必要。 - TRIA第3章が「オーバーレイ」を[[レイヤリング]]の相対的な役割に還元したことで、「オーバーレイ固有の性質」と「レイヤリング一般の性質」の境界がどこにあるのかが不明瞭になった。例えば本ページが記録するch.9の「複数オーバーレイの併存・ネスト」という性質は、レイヤリング一般の性質なのか、それともオーバーレイ(エンドホスト主導という文脈)に固有の性質なのか、TRIAの記述だけでは判断できない。 ## 関連 - ソース: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]](§9.4 オーバーレイの定義、§9.4.1 ルーティングオーバーレイ、§9.4.2 ピアツーピアネットワーク) / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]](§3.3-§3.4 レイヤリングの一事例としてのオーバーレイ) / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 5 Patterns for Enhanced Network Services]](§5.5.4 レイヤリングによる"having it all"、Tor・SEATTLEの実例) / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]](§8.3.1 GENEVEの標準化経緯とVXLANとの対比) / [[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]](§1, §5.1 制御プレーンとデータプレーンカプセル化の組み合わせ) - 概念: [[レイヤリング]](オーバーレイを一事例として包摂するより一般的な合成演算子) / [[ネットワーク仮想化]](VXLAN・MPLS VPNという運用者主導のオーバーレイ) / [[砂時計モデル]](遅延バインディングとの接続) / [[一貫性ハッシュ法]](構造化オーバーレイのID空間配置) / [[コンテンツ配信ネットワーク]](オーバーレイに近いがredirectorによる間接転送を使う点で異なる) / [[セッションアーキテクチャ]](オーバーレイの特殊用途ルーティングが要求するセッションアフィニティ) / [[EVPN]](運用者主導オーバーレイの制御プレーン) - 実体: [[Larry Peterson]] / [[Bruce Davie]] / [[GENEVE]] / [[VXLAN]] / [[Open vSwitch (OVS)]] / [[OVN]] ## 出典 - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.4 Overlay Networks. https://book.systemsapproach.org/applications.html - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 3, §3.3, §3.4; Chapter 5, §5.5.4, §5.6.2. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 1: Introduction, §1.2.3. https://sdn.systemsapproach.org/intro.html(VXLANの誕生経緯とUDP/IPカプセル化) - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 8: Network Virtualization, §8.3.1. https://sdn.systemsapproach.org/netvirt.html(GENEVEの標準化経緯とVXLANとの対比) - Mahalingam, M., et al., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014. https://www.rfc-editor.org/rfc/rfc7348.html - [[@2018__IETF__A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)]](RFC 8365 §1, §5.1)