ソフトウェア定義ネットワーク

# ソフトウェア定義ネットワーク ## 定義ソフトウェア定義ネットワーク(SDN, software-defined networking)とは、ネットワーク機器の内部で密結合されていたコントロールプレーン(経路制御などネットワークの振る舞いを決定する部分)とデータプレーン(実際にパケットを転送する部分)を分離し、後者を論理的に集中化されたコントローラでソフトウェア的に制御するアーキテクチャである。ここで重要なのは、プレーンの分離それ自体では不十分だという点にある。Scott Shenker が講演 "The Future of Networking, and the Past of Protocols"(ONS 第1回, 2011年)で明確化したように、より良い抽象化には「論理的な中央制御」の提供が必要であり、この二つのアイデア――コントロールプレーンの分離と中央制御――の組み合わせこそが SDN に真の力を与えた。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.1) 最初の具体的なプロトコルである [[OpenFlow]] は、スイッチのデータプレーン(FIB)に対するエントリ設定インターフェースをマッチ/アクションによるフロールールとして体系化した。しかしこの章の主張が繰り返し強調するように、OpenFlow は SDN の低水準の一実装にすぎず、SDN 自体ははるかに大きな概念である。OpenFlow の後継として [[P4]] が、コントロール/データプレーン間インターフェース(P4Runtime)をソフトウェアから自動生成する仕組みを持ち込み、標準化プロセスの速度に縛られないインターフェース進化を可能にした。(Source: ch.5 §5.1, §5.2, §5.3) **この定義は「コントロールプレーン/データプレーン分離+論理的中央制御」という軸で意図的に一般化して書いている**。本書は SDN の適用範囲を L2/L3 スイッチング(本章)にとどめず、無線アクセス網(第9章、RAN インテリジェントコントローラと xApps)、SmartNIC/IPU(第10章)、ネットワーク管理全般(第11章)へと広げていく。したがって本ページの「定義」節は今後、各章の ingest のたびに「同じ制御原理がどの粒度・どのレイヤーで再現されるか」という観点で積み増されることを想定する。 **姉妹書 *Software-Defined Networks: A Systems Approach* の第1章は、上記の定義をより体系立った3つの設計軸へ分解する**。(1) コントロール/データプレーンの分離を開かれたインタフェースとして規定する**ディスアグリゲーション(disaggregation)**——コントロールプレーンが維持する経路表(Routing Information Base, RIB)とデータプレーンが維持する転送表(Forwarding Information Base, FIB)という並行するが別個のデータ構造として現れる。(2) コントロールプレーンを**集中(centralized)か分散(distributed)か**という軸——SDNの第二の設計原理は、コントロールプレーンをデータプレーンから完全に独立させ「論理的に集中化」することであり、その実装自体は複数サーバへ分散させてよい(単一障害点ではない)。(3) データプレーンを**プログラマブルか固定機能(fixed-function)か**という軸——TCAMの容量制約という性能問題と、VXLANのようなプロトコルスタックの想定外の変化という2つの問題が、この軸を重要にした。この章はさらに、SDNの原型的定義をNick McKeownの2013年のプレゼンテーションに帰す:「コントロールプレーンがフォワーディングプレーンから物理的に分離し、単一のコントロールプレーンが複数のフォワーディングデバイスを制御するネットワーク」。この原型的定義は「より狭く」(構成設定インタフェースだけでSDNとみなす)も「より広く」(プログラマブルデータプレーンを含める)も解釈されてきたが、本書(と本 concept の姉妹書であるLambdaNote版)はいずれも拡張的な解釈を取る。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.1, §1.2.2, §1.2.3, §1.3) **第1章が示す3つの設計軸(ディスアグリゲーション・集中対分散・プログラマブル対固定機能)は、第3章でスタックの具体的な層構造とその層間インターフェースとして実装に落とし込まれる**。SDN ソフトウェアスタックは、ベアメタルスイッチ(データプレーンのハードウェア)・Switch OS(スイッチごとのローカルなソフトウェア層)・Network OS(論理的に集中化されたネットワーク全体のコントローラ)・制御アプリケーション(Network OS の上で走るサービス固有のアプリケーション群)という4層からなる。層間には2組の開かれた「API シム」があり、制御アプリと Network OS の間は gNMI・gNOI・FlowObjectives の組み合わせ、Network OS とスイッチの間は gNMI・gNOI に P4Runtime または OpenFlow を組み合わせたもので接続される。いずれも gRPC を伝送プロトコルとする(OpenFlow のみ例外)。この構成はさらに、スイッチ単体の視点(vSwitch や SmartNIC を含むエンドホストの実装まで、物理スイッチと同じ API を持つスイッチング要素として扱う「ネットワーク志向の視点」)と、eBPF/XDP のようなホスト OS カーネル内プログラマビリティを重視する「ホスト中心の視点」という、2つの実装の流儀を持つ。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.1, §3.1.1) **終章(第10章)は、これまでの各章が描いてきた SDN の到達点を、3フェーズからなる歴史的な見取り図(図61)の中に位置づけ、将来展望としての第3のフェーズを提示する**。フェーズ1はディスアグリゲーションと集中制御の確立、フェーズ2(現在、最も先進的な運用者が到達しつつある早期段階)はディスアグリゲートされたコントロールプレーンによるソフトウェアの制御と P4 プログラマブルデータプレーンによるパケット処理の制御の獲得である。新たに立ち上がりつつあるフェーズ3は、検証可能なクローズドループ制御(verifiable closed-loop control)によって運用者がネットワークを定義するソフトウェアの完全な所有権を握り、単に振る舞いを決定できるだけでなく、ネットワークが自らの意図を実装していることを証明できるようになる段階である。この検証可能性(verifiability、あらゆるパケットがオペレータの指定した経路のみをたどり意図した転送ルールのみに遭遇することの保証)は、ディスアグリゲーション(コンポジショナルな構成)を土台に、ネットワークレベルでの意図表明と細粒度・リアルタイムな挙動観測の2つが可能になることで導かれるとされ、SDN の中心的な設計原理である「分離」がそのまま「検証可能性」という新しい価値へ接続される構図を示す。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]]) ## 横断的知見 - **分散システム研究の成熟が SDN の中央制御を実現可能にした、という主張が二つの独立したエッセイで異なる粒度から裏付けられる**: [[システムズアプローチ]] concept(ch.1 出典)は「SDN のスケーリング課題に Hadoop のような分散システムの技法を取り入れる例」を、システムズアプローチが繰り返し要求する「スケーラビリティ」要件の一具体例として簡潔に挙げるにとどまる。一方、本章 ch.5 §5.1 は同じ主張をより具体的に展開し、「スケーリングするうえでボトルネックにも単一障害点にもならないような論理的に集中化されたネットワークコントローラを構築するための技術が何十年にもわたる分散システムの研究と開発を通じて整っていた」ことを、SDN 台頭の不可欠な前提条件として位置づける。ch.1 が一般原則の一例として触れた事実に、ch.5 は歴史的経緯と因果関係(分散システム研究の成熟 → 中央制御の実現可能性 → SDN の受容)を与えている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]]) - **「技術主導か商業主導か」というアーキテクチャ評価軸(ch.2)は、SDN の普及過程そのものが具体例になる**: [[ネットワークアーキテクチャ]] concept(ch.2 出典)は「技術主導のアーキテクチャ」と「商業主導のアーキテクチャ」という対比軸を示しつつ、両者が競合した際の一般的な判断基準は示さず、後続の SDN・5G 章での再訪を待つとしていた。ch.5 の記述はこの問いに具体例で応える。OpenFlow は学術研究コミュニティ(スタンフォード大学、ONF)に端を発した技術主導の取り組みであり、Nicira の VMware による買収、Google・Microsoft の SDN 基盤採用(いずれも2012年)という商業的採用が変革を加速させた。著者は「忘れてはならないのは、この変革がもともと学術研究コミュニティに端を発しているという点だ」と明記しており、技術主導の起源が商業主導の普及に先行し両者が補完し合う経路を SDN は辿ったことが分かる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2) - **ONF という組織的な受け皿(ch.3)と、OpenFlow/P4 という技術的成果物(ch.5)は、SDN の「制御と転送の分離」という原則を維持したまま主役を交代させた**: [[Open Networking Foundation]] は Nick McKeown と Scott Shenker により SDN の活性化のために設立された組織で、その活動には OpenFlow の標準策定(ONF)と ONOS 等のオープンソースプラットフォーム開発(姉妹組織 ON.Lab)が含まれていた(ch.3 §3.1)。ch.5 §5.2 は、その ONF 自身がフラッグシッププロジェクト Aether において「OpenFlow から P4 ベースの SDN へとフォーカスを移しつつある」と述べる。つまり SDN を体現する具体的な技術(OpenFlow → P4)は世代交代しても、それを支える組織原則(ベンダー中立性、オープンインターフェース、オープンソース)は ch.3 が描く ONF の設立理念のまま一貫している。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2) - **SDN のデータプレーン/コントロールプレーン分離という原則が、第10章ではスイッチの外(ホスト側ハードウェア)へ物理的に押し出される動きとして再演される**: ch.5 は SDN の起源をスイッチ内部のコントロール/データプレーン分離として説明する(§5.1)。ch.10 は、同じ P4/PISA というデータプレーンプログラミング技術が、スイッチ ASIC だけでなく IPU/DPU というサーバに接続される計算機インフラ側のデバイスの設計にも使われている経緯を描き、DPU/IPU を「よりプログラム可能なスイッチを生み出そうとする SDN の潮流によって可能になった、新しい領域におけるイノベーション」と位置づける(ch.10 §10.2)。SDN が確立した「制御をソフトウェアで、転送を専用ハードウェアで」という分業パターンが、ネットワーク機器の内部にとどまらず、ホスト側の NIC/IPU にまで拡張されていることを示す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]]) - **RAN のオープン化は「制御と転送の分離」ではなく「内部可視性の開示」という別の軸で SDN 原則を輸入しており、ch.5 が想定していたほど直接的な対応関係にはない**: ch.5 §5.2 は将来 RAN インテリジェントコントローラと xApps が SDN の枠組みに当てはまることを見込んで未解決の問いとしていたが、ch.9 §9.1・§9.3 が実際に描く RAN のディスアグリゲーションは、RIC/xApps という用語には触れず、代わりに Open RAN アライアンス(現 [[O-RAN Alliance]])によるオープンなインターフェース・オープンソースソフトウェアの定義と、従来クローズドだった RAN 内部のキューやスケジューラの挙動を上位層に開示する AQM 対応シグナリングという、より控えめな形で言及される。ch.9 自身が「これはある意味で SDN の概念を RAN の世界に持ち込む試みとみなされている」と留保付きで述べ、「最終的に成功を収めるかどうかは現時点ではまだ未知数」と評していることから、SDN の「論理的中央制御」に相当する要素は RAN 側にまだ確立していないことが分かる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 9 5G：対照的なアーキテクチャ]] 章冒頭コラム「略語だらけ」, §9.1, §9.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2) - **GitOps の集中管理と SDN のコントロールプレーン集中管理は、ch.5 が未解決としていた問いに対し「異なる設計原理」という回答を与える**: 本ページはch.5・ch.9・ch.10の記述をもとに、「GitOps・宣言的な単一情報源はSDNのコントロールプレーンによる集中管理の自然な延長線上にあるのか、異なる設計原理に基づくのか」を未解決の問いとして残していた。第11章§11.2・§11.6を読むと、両者は集中化の対象がそもそも異なることが分かる——SDNのコントロールプレーンが集中管理するのは「ネットワークの振る舞い(フォワーディングルール)」であり、その集中制御自体がAPIを介したプロビジョニングの自動化(Nicira NVPの事例)を可能にした。一方GitOpsが集中管理するのは「システムの構成の記述(コード)」であり、その記述をリポジトリという単一の場所に置くことが信頼できる唯一の情報源を実現する。両者は「集中化によって複雑さを扱いやすくする」という同じ設計モチーフを共有するが、対象(振る舞い対記述)が異なるため、GitOpsはSDNの単純な延長ではなく、独立した設計原理として並存している。ただし第11章はSDNのコントローラが提供するAPI自体をGitOpsのCI/CDパイプラインが呼び出すという統合も想定しており(Aetherの事例)、両者は排他的でなく補完的である。詳細は [[GitOps]] concept を参照。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, §11.6) - **SDN の商業的普及の主動因は研究コミュニティの当初のビジョンでなく「ネットワーク自動化」だったことを、第11章が正面から論じる**: ch.5・ch.2 が記録する「技術主導の起源(OpenFlow)が商業主導の普及(Nicira買収)に先行した」という経路(既出の横断的知見)に対し、第11章§11.6は具体的にどの用途が商業的成功を牽引したのかを明示する——「SDNが最初に商業的な大成功を収めたのは、プライベートクラウドにおけるネットワーク設定の自動化に関する課題への適用であった。研究コミュニティの大半が思い描いていた当初のSDNのビジョンとは違う形であった」。Niciraの買収以前の顧客はすべて何らかのネットワーク自動化プロジェクトのためにNVPを利用していたという事実は、ch.5が記述する「集権型コントローラによる分散アルゴリズムの単純化」という技術的動機と、実際に市場が評価した「自動化による手作業の削減」という商業的価値との間にずれがあったことを示す。詳細は [[ネットワーク自動化]] concept を参照。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.6) - **SDN の「論理的中央制御」という定性的な設計原理は、トラフィックエンジニアリングの文脈では利用率30〜40%→ほぼ100%という定量的な効果として確認できる**: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.1が引くScott Shenkerの主張(単なるプレーン分離でなく論理的な中央制御こそがSDNに真の力を与える)は、これまで本concept ではOpenFlowの技術的経緯や商業的普及という文脈で語られてきた。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] のPerspective節は、GoogleのベアメタルスイッチとSDNのみで構築された私設WAN B4を例に、中央集権的な意思決定によってリンク利用率を一般的なWANの30〜40%(バーストや障害への備えのため保守的に運用される水準)からほぼ100%まで高められたことを具体的な数値で示す。これは、輻輳制御(個々のフローが「どれだけ送ってよいか」を事後的に調整する仕組み)とトラフィックエンジニアリング(そもそも輻輳が起きないよう帯域をネットワーク全体で事前配分する仕組み)が、SDNの中央制御という同一の設計原理のもとで補完関係にあることを示す一次資料である。B4がGoogleの私設WANであるがゆえに、Googleは他のBBRフローとの公平性を気にせず独自の輻輳制御を運用できるという判断は、[[TCP輻輳制御アルゴリズム]] が既に集約する「公平性を放棄できるのは管理ドメインが閉じているから」という知見とも整合する。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] Perspective, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.1) - **Systems Approach教科書は、SDNのコントロール/データプレーン分離という原則そのものは経路制御の古典的アルゴリズムにすでに内在していたと位置づけ、SDNの新規性を「標準インターフェースによる分離の明示化とスイッチ外への物理的な移設」に絞り込む**: 本ページの定義(ch.5出典)はSDNの核心を「分離」+「論理的中央制御」の組み合わせに置くが、その分離の起源自体は詳述しない。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] §3.4は、RIP(ディスタンスベクタ)やOSPF(リンクステート)といったSDN以前から存在する経路制御プロトコルの解説の冒頭で、転送(forwarding、データプレーン)と経路制御(routing、コントロールプレーン)の区別を「しばしば無視される重要な区別」として立て、両者はSDN登場のはるか前から分散アルゴリズムとして実装されてきたと明示する。続く§3.5.2-§3.5.3は、この区別自体は新しくないが、SDNが新しく持ち込んだのは(1)コントロールプレーンをスイッチ内蔵CPUから汎用サーバへ物理的に移す、(2)コントロール/データプレーン間に標準インターフェース([[OpenFlow]])を定義し任意のベンダーのベアメタルスイッチと組み合わせ可能にする(disaggregation)、という2点だと述べる。これは本ページが引くch.5のShenker由来の主張(分離だけでは不十分で論理的中央制御が必要)と補完的であり、Systems Approach側は「分離」概念自体の古さを、LambdaNote版は「分離+中央集権化」という組み合わせの新規性を、それぞれ強調している。さらにSystems Approach §3.5.2は「初期のSDNの段階そのものがベアメタルスイッチへの業界の移行を引き起こした」と因果の向きをSDN→ハードウェアコモディティ化と明示するのに対し、ch.5 §5.1は汎用スイッチ用チップ(Broadcom・Marvell等)の台頭をOpenFlow受容を可能にした環境条件の一つとして挙げており、ハードウェアコモディティ化とSDN普及の因果の向きについて両書は正反対の順序を強調している。両者が排他的な主張というより、SDNとハードウェアコモディティ化が相互に加速し合った共進化(co-evolution)を、それぞれ異なる側から切り取ったものと解釈するのが妥当である。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] §3.4, §3.5.2, §3.5.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.1) - **SDN の起源を「技術主導対商業主導」という二項の軸(既出の横断的知見)で捉えるのに対し、序文(Foreword)はその手前にある産業構造上の動機——ルータベンダーのビジネスモデルと大規模ネットワーク所有者の利害対立——を具体的に描く**: ch.5・ch.2 が記録する「学術研究コミュニティに端を発した技術主導の起源(OpenFlow)が商業的採用(Nicira買収、Google・Microsoftの2012年採用)に先行した」という経路は、*なぜ*所有者側がベンダーからの脱却を欲したかという動機そのものには踏み込まない。序文の著者McKeownはこの空白を埋め、ルータベンダーが「単純で洗練された機器を売る事業では収益性を維持しにくい」というジレンマを抱え、外部APIを最小限にして機能を機器内部に囲い込む戦略(「ネットワーク管理」は冗談扱いされていた)を取った結果、2000年代半ばには数百のプロトコルと1億行超のソースコードを抱える肥大化したルータが業界標準となり、ISPが「stranglehold(締め付け)」を訴え研究コミュニティが「ossification(硬直化)」を警告する状態に至ったと説明する。この産業構造上の行き詰まりこそが、ネットワーク所有者が自らコードを書き自前のスイッチ・ルータを構築する動機であり、ch.5が描く技術的経路(OpenFlow→P4)の背後にある経済的な圧力を補完する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Foreword]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2) - **「SDNの商業的成功の主動因はネットワーク自動化だった」(第11章、既出の横断的知見)という分析に対し、序文はより根源的な動機として「制御そのもの」を挙げ、コスト削減や自動化を副次的な結果と位置づける**: 第11章§11.6は、SDNが最初に商業的な大成功を収めたのはプライベートクラウドにおけるネットワーク設定の自動化への適用であり、これは研究コミュニティが当初思い描いていたビジョンとは異なる形だったと指摘していた。序文はこの「当初のビジョンとのずれ」自体には触れないが、データセンター事業者がSDNの先陣を切った理由を「既製のネットワーク機器では必要な規模のスケールアウトネットワークを構築できなかったから」と説明し、コスト削減(しばしば5倍以上に及ぶ)は結果にすぎず、彼らが本当に求めていたのは制御そのものだったと明言する。両者を重ねると、SDN普及の因果の連鎖は「規模の限界に直面したデータセンター事業者が制御を掌握 → 自前のソフトウェアで自動化を実現 → 自動化こそが商業的に最も広く評価される価値になった」という段階を踏んだと解釈でき、「制御の獲得」と「自動化の実現」は対立する動機ではなく、前者が後者を可能にする前提条件だったことが分かる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Foreword]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.6) - **同じ著者陣による2つの書籍が、Shenkerの2011年講演を異なる粒度で参照し、互いに補完し合う**: 本ページの定義(ch.5『ネットワークシステムについて語るときに我々の語ること』出典)は、Shenkerの主張を「単なるプレーン分離ではなく論理的な中央制御の提供こそがSDNに真の力を与える」という具体的な処方箋として要約する。*Software-Defined Networks: A Systems Approach* 第1章は同じ講演を、「ネットワークの構築・運用という実務は複雑性を管理するための抽象化を切実に必要としている」というより広い中心テーゼとして紹介し、これを理解することが本書全体(システム・プラットフォーム・ツール・インタフェース)を理解する要石(linchpin)だと位置づける。両者は矛盾しないが、ch.1は「なぜ抽象化一般が必要か」という動機を、ch.5は「どの抽象化(分離+中央制御)が採用されたか」という帰結を、それぞれ異なる解像度で説明しており、同一の講演から異なる教訓を引き出す2つの独立した書籍が実質的に同じ結論(コントロール/データプレーン分離だけでは不十分)に収斂している。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.1) - **「制御(Control)」と「構成設定(Configuration)」の区別に、ch.1は更新頻度という定量的な基準を与え、これが第11章のGitOps論(既出の横断的知見)を技術的に裏付ける**: 本ページは既に、GitOpsが集中管理する対象(構成の記述)とSDNのコントロールプレーンが集中管理する対象(振る舞い)が異なるという横断的知見を記録している。ch.1 §1.2.1はこの「振る舞い対記述」という質的な区別に、更新頻度という定量的な基準を追加する——構成設定はおよそ1日あたり数千件のオーダーで更新されるのに対し、制御はおよそ1秒あたり数千件のオーダーで更新される。つまりGitOpsが扱う「構成の記述」はSDNの分類でいう構成設定(CLIやSNMPに相当する低頻度の変更)の領域にとどまり、SDNのコントロールプレーンが担うリアルタイムな制御(秒未満での障害応答)の領域には踏み込まない。この更新頻度の桁違いの差が、両者が「集中管理」という同じ設計モチーフを共有しながら排他的でなく補完的でいられる技術的な理由を説明する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.1, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, §11.6) - **第1章が抽象的に導入した「制御対構成設定」の区別に、第3章は具体的なプロトコルの対応関係を与える**: ch.1 §1.2.1は制御(高頻度)と構成設定(低頻度)を更新頻度という定量的な基準で区別したが、それぞれがどのプロトコルで実現されるかまでは踏み込まない。ch.3 §3.3は Switch OS(Stratum)が公開する API を具体的に対応づける——P4Runtime が Control API に、gNMI/gNOI の組み合わせが Configuration API(歴史的には OAM インターフェースと呼ばれ、多くはコマンドラインインターフェースとして実装されてきたもの)の現代版に、それぞれ相当する。抽象的な区別(更新頻度)と具体的な実装(プロトコルの使い分け)が、同一著者陣による2つの章で補完し合う形になっている。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.3) - **ch.1が未解決の問いとして残していた「集中コントロールプレーンをどの分散システム技術で複数サーバへ分散させるか」という問いに、ch.3はONOSの内部実装(Atomixが実装するRAFT合意アルゴリズム)という具体的な答えを与える**: ch.1 §1.2.2は「コントロールプレーンの実装自体は複数サーバへ分散させてよい(単一障害点批判への反論)」と論じるにとどまり、その分散をどの技術で実現するかは一般化した「分散システム技術」という言葉で済ませていた。ch.3 §3.4は、あらゆるNetwork OSにとって最も重要なサブシステムは「スケーラブルなKey/Valueストア」であると位置づけ、ONOSの場合それはRAFT合意アルゴリズムを実装するAtomixが担うと明示する。これは本ページが既に記録するとおり、SDNの中央制御という設計原理をトラフィックエンジニアリング(Google B4)で定量的に裏づけた横断的知見や、GitOps・ネットワーク自動化との比較で積み上げてきた「集中管理」という設計モチーフに、ハードウェア寄りの具体的な実装技術という新しい解像度を追加するものである。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.2, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.4) - **ch.3が未解決として残していた「表現力(eBPF/XDPの任意プログラム)対検証可能性(P4の固定Action集合)」というトレードオフに、終章(ch.10)は「検証可能性を選び表現力を意図的に制限する」という明確な回答を与える**: ch.3のホスト中心の視点コラムは、eBPF/XDPがOpenFlow/P4と異なりActionを任意のプログラムにできる表現力の高さを挙げるにとどまり、その表現力が形式検証にどう影響するかには踏み込んでいなかった(既出の未解決の問い)。ch.10は、P4データプレーンの検証が現実的である理由を「言語としてループやポインタベースのデータ構造を意図的に排除している」点に求め、これらは一般に解析を非現実的にする要因だと明言する。これは、eBPF/XDPが得る表現力の高さ(任意プログラム)が、まさにch.10の言う「解析を非現実的にする要因」そのものであることを意味し、両者のトレードオフはSDNの著者陣にとって二律背反ではなく「検証可能性を追求するならP4のような制限された言語を選ぶ」という設計判断として明確に片側に倒されていることが分かる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 コラム, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]]) - **ch.10が検証可能性の前提条件として挙げる「コンポジショナル(ディスアグリゲートされた)な構成」は、本ページが既に蓄積してきたディスアグリゲーションの意義(ch.1の3設計軸の一つ、ch.3のAPIシムによる層間分離)に、「検証のしやすさ」という新しい理由を追加する**: 本ページはこれまでディスアグリゲーションを、開かれたインタフェースの規定(ch.1)や層間APIシムによる実装の柔軟性(ch.3)という文脈で記録してきた。ch.10は同じディスアグリゲーションを、検証(verification)の観点から再評価する——「検証は、システム全体がコンポジショナル(すなわちディスアグリゲート)な構成のときに最もうまく機能する。小さな部品ごとに推論できることが検証を扱いやすくする」。これは、ch.1・ch.3が論じてきたディスアグリゲーションの価値(ベンダーロックインからの解放、層間の独立進化)に、「部分ごとの正しさの検証可能性」という、本書がこれまで明示してこなかった第三の理由を与えるものであり、SDNの中心的な設計原理である「分離」がそのまま検証可能性という将来の価値へ接続される構図を示す。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]]) - **序文(Foreword)が描くルータベンダーの「ジレンマ」(単純な機器では収益性を維持できず機能を機器内部に囲い込む)がもたらした「オシフィケーション(硬直化)」の帰結の一つが、ch.10が扱うBGPの検証不能性である**: 序文は、ルータベンダーが外部APIを最小限にして数百のプロトコル・1億行超のソースコードを機器内部に囲い込んだ結果、業界が硬直化(ossification)したと描く(既出の横断的知見)。ch.10はこの硬直化の技術的帰結を、BGPを名指しして具体化する——「ネットワークがどう動作するかを決める分散アルゴリズムは推論が困難であり、BGPはその失敗モードが何十年にもわたり研究者・実務者を悩ませてきた古典的な例」であり、SDNの集中型制御モデルが目指す「構成による正しさ(correct by construction)」とは対照的に、既存の複雑な分散コントロールプレーンの振る舞いを事後的にモデル化しようとする従来の検証アプローチは、現実がモデルと正確に一致しなければ保証にならないという限界を抱える。序文が産業構造の観点から描いた「機能の囲い込みによる硬直化」が、ch.10では「検証不能な複雑さ」という技術的形態として結実していることが分かる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Foreword]], [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]]) - **「OpenFlow コントローラの視点から見た単純なマッチ/アクションモデル」(ch.5 の定義)と、実装がそれを支えるために抱え込む複雑さとの間には、本ページがこれまで扱ってこなかった大きな乖離がある**: 本ページの定義は OpenFlow を「スイッチのデータプレーンに対するエントリ設定インターフェースの体系化」(ch.5 §5.1)として記述し、その簡潔な抽象化がもたらす価値を強調してきた。[[@2015__NSDI__The Design and Implementation of Open vSwitch]] は、この「コントローラの視点では各パケットが一連の OpenFlow フローテーブルを通過し最高優先度のフローが見つかる」という単純なモデルが、[[Open vSwitch (OVS)|OVS]] の実装内部では2層フローキャッシュ・タプル空間探索分類器・4つのキャッシュ最適化・Bloom フィルタベースのキャッシュ無効化(後に放棄)という高度に複雑な機構によって初めて成立していることを示す。SDN の「制御と転送の分離」という設計原理(本ページ既出の横断的知見)は、転送側のインターフェースを単純化することと引き換えに、転送側の実装がその単純さを維持するための複雑さを丸ごと引き受けるという非対称な取引だったことが、OVS の一次資料から具体的に確認できる。(Source: [[@2015__NSDI__The Design and Implementation of Open vSwitch]] §3.1, §4, §5, §6) - **NVP コントローラが要求する「最低15回のテーブルルックアップ」という長いパイプライン(既出、[[ネットワーク仮想化]] concept と共有する知見)が、OVS のフローキャッシュ設計を直接駆動した具体的な因果関係が確認できる**: OVS 論文は、OpenFlow が SDN の低水準の一実装にすぎないという本ページの立場を裏付けつつ、その「多くの flow table lookup」という設計選択(ネットワーク仮想化のような高度なユースケースが要求)自体が、フローキャッシングという OVS の中核設計を必要とした直接の原因だったと明言する——長いパイプラインを持たなければキャッシュはここまで精緻化される必要がなかった。SDN が上位レイヤーに与える柔軟性(長いパイプラインを自由に構成できること)と、それを支える下位レイヤーの性能工学の複雑さは、トレードオフというより「柔軟性の要求が複雑さを直接生成する」という一方向の因果関係にある。(Source: [[@2015__NSDI__The Design and Implementation of Open vSwitch]] §2) ## 未解決の問い - RAN 側の「論理的中央制御」に相当するコントローラは、ch.9 が言及する Open RAN アライアンス(O-RAN Alliance)やクロスレイヤーインターフェースの延長線上にいつ・どのような形で現れるのか。ch.9 は AQM 対応の高レベルシグナリングを挙げるにとどまり、RIC/xApps のような具体的なコントローラアーキテクチャには触れていない(旧版の本節はこの点を「次章以降の課題」としていたが、第9章の刊行時点でもなお未解決である)。 - IPU/DPU 上の P4 データプレーンは、スイッチ ASIC(Tofino 等)と比べて絶対性能(スループット・レイテンシ)でどの程度の差があるか。ch.10 は定性的な位置づけを示すにとどまり、定量比較は本書に出てこない。 - ネットワーク仮想化・サービスメッシュという「SDN のキラーアプリ」的展開の外に、SDN の中央制御原則が失敗した、あるいは撤退した事例はあるか。本書はこれまでのところ成功事例のみを描いている。 - 物理ネットワークの自動化が仮想ネットワークの自動化に比べて進んでいない(第11章§11.6)理由は、SDNのコントロールプレーンが物理ネットワーク機器に対してはまだ十分に確立されていないためか、それとも別の構造的要因(業界のインセンティブ構造)によるものか。第11章はこの二つの可能性を明確に切り分けない。 - 序文(Foreword)が描くルータベンダーの「ジレンマ」(単純な機器では収益性を維持できないため機能を囲い込む)は、SDNが普及した後のホワイトボックススイッチ・ベアメタルスイッチ市場でベンダー側がどう収益モデルを再構築したかまでは説明していない。ベンダー側の視点からの記述(本書第4章 Bare-Metal Switches が扱う可能性がある)と付き合わせて検証する必要がある。 - ~~ch.1が示す「集中コントロールプレーンの実装自体は複数サーバへ分散させてよい」という論法(単一障害点批判への反論)は、具体的にどの分散システム技術(合意プロトコル・シャーディングなど)に依拠しているのか。~~ → **解決**: ch.3 §3.4がAtomix(RAFT合意アルゴリズム)を示した。ONOS自体の内部構造(トポロジー・構成・スイッチ制御の3責務、分散コアの詳細)は第6章でさらに解像度が上がる可能性がある。 - ch.3が示す2つのAPIシムは非対称である——Network OSとスイッチの間(P4Runtime/OpenFlow)は業界標準に近い規定インターフェースだが、制御アプリとNetwork OSの間(FlowObjectives)はONOS固有で標準化されていない。「ソフトウェアスタックを上るほど合意形成が難しくなる」という著者らの一般論(ch.3 §3.4)は、なぜ下位層(スイッチ制御インターフェース)では合意が可能で上位層(Network OS API)では困難なのかを明示的には説明しない。この非対称性の理由は本書のどこかで論じられるか。 - ~~ch.3のホスト中心の視点(コラム)は、eBPF/XDPがOpenFlow/P4と違いActionを任意のプログラムにできる点を挙げるが、この表現力の高さが形式検証(第10章で扱うとされる)にどう影響するのかは本章では踏み込まない。表現力(任意プログラム)と検証可能性(固定Action集合)のトレードオフを本書はどう解決するのか、第10章のingestで確認する必要がある。~~ → **解決**: ch.10がP4の言語制約(ループ・ポインタ構造の排除)を検証可能性の鍵として明示し、「検証可能性を選び表現力を制限する」という設計判断を確認した(既出の横断的知見)。 - ch.10は「SDNのフェーズ3(検証可能なクローズドループ制御)」を新たに立ち上がりつつある段階と位置づけるが、2021年執筆時点での見通しにとどまり、具体的な到達時期やマイルストーンは示さない。本書刊行から5年が経過した現在、フェーズ3はどこまで実現しているか、本 wiki の他ソース(第9章のRICなど)と照合してもまだ確認できていない。 - ch.10はドメイン内(intradomain)ユースケースでは検証可能性を見据えた設計が可能になりつつあるとしつつ、BGPに代表されるドメイン間(interdomain)ルーティングの検証不能性は将来も残り続けるだろうと脚注で留保する。ドメイン内での検証可能性の進展は、ドメイン間ルーティングの設計や標準化にどのような波及効果を持ちうるか、本書は論じない。 - ch.10がVeriflow・Header Space Analysis(HSA)を「フォワーディング挙動が既知・固定の場合にすでに実用化・商用化されている」技術として挙げるのに対し、P4が加える「フォワーディング挙動自体をプログラムし時間とともに変化させる」自由度に、これらの既存ツールがどこまで追随できるのかは本書に具体的な記述がない。 ## 関連 - 概念: [[ネットワーク仮想化]] / [[プログラマブルデータプレーン]] / [[サービスメッシュ]] / [[システムズアプローチ]] / [[ネットワークアーキテクチャ]] / [[集権化と非集権化]] / [[データセンターネットワークトポロジ]] / [[インバンドネットワークテレメトリ]] / [[スマートNICオフロード]] / [[5Gモバイルネットワーク]] / [[GitOps]] / [[ネットワーク自動化]] - 実体: [[OpenFlow]] / [[P4]] / [[Nicira]] / [[Open Networking Foundation]] / [[Nick McKeown]] / [[Martin Casado]] / [[Scott Shenker]] / [[Cisco]] / [[Intel IPU]] / [[O-RAN Alliance]] / [[3GPP]] / [[VMware]] / [[Stratum]] / [[ONOS]] / [[SD-Fabric]] / [[Open vSwitch (OVS)]] / [[Ben Pfaff]] - 関連 MOC: [[Network - MOC]] - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]] — Google B4によるSDNトラフィックエンジニアリングの定量的効果(Perspective節)。 - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] — 転送/経路制御の区別、ベアメタルスイッチ、SDNの基礎的な教科書的説明(§3.4, §3.5)。 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Foreword]] — SDNが生まれた歴史的・産業構造的動機(ルータベンダーのジレンマ、データセンター事業者による制御の奪還)。 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] — SDNの原型的定義(McKeown 2013)、ディスアグリゲーション・集中対分散・プログラマブル対固定機能という3つの設計軸、制御対構成設定の区別。 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] — SDNソフトウェアスタックの4層構造(ベアメタルスイッチ/Switch OS/Network OS/制御アプリ)と層間APIシム、スイッチ実装対ホスト実装の2つの流儀。 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]] — SDNの3フェーズ論、検証可能性(verifiability)とトップダウン制御という将来展望、P4の言語制約と検証可能性の関係。 ## 出典 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Foreword]](Nick McKeownによる序文。インターネットの非集権的拡大、ルータベンダーのジレンマとオシフィケーション、SDNを「制御の移動」とする位置づけ) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]](SDN の歴史・OpenFlow・P4・SD-WAN・サービスメッシュとの類似性) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]](システムズアプローチの要件の一例としての SDN スケーリング言及) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]](技術主導/商業主導アーキテクチャという評価軸) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 3 オープンソースソフトウェア]](ONF の設立経緯とベンダー中立性) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 9 5G：対照的なアーキテクチャ]](RAN のディスアグリゲーションと Open RAN アライアンスによる SDN 原則の輸入) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]](SDN の潮流がIPU/DPUへ結集する経緯) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]](GitOpsとの関係、ネットワーク自動化がSDN商業的成功の主動因だったこと) - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 6 Congestion Control]](Perspective: Software-Defined Traffic Engineering。Google B4によるSDNトラフィックエンジニアリングとリンク利用率の定量的改善) - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 3: Internetworking, §3.4, §3.5. https://book.systemsapproach.org/internetworking.html (転送/経路制御の区別、ベアメタルスイッチとNPU、SDNとOpenFlow/disaggregationの教科書的説明) - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 1: Introduction. https://sdn.systemsapproach.org/intro.html (SDNの原型的定義、3つの設計軸、制御対構成設定の区別) - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]](SDNソフトウェアスタックの4層構造、層間APIシム、スイッチ実装対ホスト実装、ベアメタルスイッチにP4プログラムが必要な理由) - [[@2015__NSDI__The Design and Implementation of Open vSwitch]](Pfaff, B., et al., NSDI '15、Best Paper。OpenFlowの単純な制御モデルを支えるOVS実装側のフローキャッシュ・パケット分類器の複雑さ) - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 10: Future of SDN. https://sdn.systemsapproach.org/future.html(SDNの3フェーズ論、検証可能性、トップダウン検証、INTによるクローズドループ制御)