# プログラマブルデータプレーン ## 定義 プログラマブルデータプレーンとは、パケットフォワーディングの振る舞い(パイプライン)をソフトウェアで記述・変更できるデータプレーンを指す。本書では [[OpenFlow]] と [[P4]] という二世代の技術が対比的に描かれる。OpenFlow はデータプレーンの FIB に対するエントリ設定インターフェースをマッチ/アクションによるフロールールとして体系化したが、その仕様自体は固定的なマッチ/アクションの組を定義するにとどまる。P4 はこれをさらに一歩進め、フォワーディングパイプラインの振る舞いそのものをプログラムとして記述する言語であり、PISA(Protocol Independent Switch Architecture)ベースのチップ上にコンパイルすれば、ASIC 実装の固定機能製品と同等の性能・ダイ面積・コスト・消費電力を達成できる。P4 プログラムからはコントロール/データプレーン間インターフェース(P4Runtime)をソフトウェア的に自動生成でき、これにより標準化プロセスの速度に縛られないインターフェース進化が可能になる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2, §5.3) 著者は「プログラム可能対固定機能」という対立軸よりも「パイプラインがオープンかクローズドか」という対立軸のほうが本質的だと主張する。近年は「固定機能」のパイプラインですら柔軟性が高くなっており、プログラム可能かどうかはベンダーがどこまでの変更を許すかという制限の度合いにすぎない。P4 の適用対象はスイッチング専用チップ(Tofino 等)にとどまらず、SmartNIC・IPU・DPDK・eBPF とも統合が進んでいる。(Source: ch.5 §5.3) ## PISA構造とP4アーキテクチャモデル(V1Model・PSA・TNA) *Software-Defined Networks: A Systems Approach* 第4章は、PISA(Protocol Independent Switching Architecture)の内部構造を具体的に分解する。PISAは*Parser*(ヘッダフィールドの位置と種類を識別)・複数の*Match-Action Unit*(SRAM/TCAMベースのメモリで照合し、ALUでアクションを実行する)・*Deparser*(処理済みメタデータをパケットへ再直列化)の3要素からなる。TCAMはワイルドカードマッチ(ternary)を可能にするがSRAMより高価・高消費電力であり、ワイルドカードマッチは可能な限り避けるべきとされる。P4コンパイラは、望ましいフォワーディング挙動を物理的なMatch-Action Unitのスロットへ割り当てる責務(汎用プロセッサのレジスタ割り当てに相当)も負う。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.2) 異なるASICが異なる物理パイプラインを実装する問題に対処するため、抽象(論理)パイプラインを定義する必要がある。これはP4プログラムとして`arch.p4`(コンパイラとの契約。利用可能なプログラム可能ブロック・インターフェース・型を定義する「ヘッダファイル」)という形で表現され、具体例として3つが挙げられる。**PSA(Portable Switch Architecture)**はwrite-once-run-anywhereを目指す抽象目標マシン(Javaの仮想マシンに相当)だが、スイッチベンダーがPSA向けコンパイラバックエンドを提供していないため「紙の上の成果物」にとどまっている。**V1Model**はPSAより単純で、P4_14からP4_16への移植を容易にする参照アーキテクチャとして生まれたが、実務で広く使われる標準となっている(全メタデータをingressからegressへ暗黙的に橋渡しし、チェックサム検証/更新用ブロックを持つ)。**TNA(Tofino Native Architecture)**はBarefoot(現Intel傘下)がTofino向けに定義したベンダー固有アーキテクチャであり、V1Model/PSAが共通性を志向するのに対し、TNAは特定チップの差別化能力を忠実に表現する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.3, §4.3.1, §4.3.2) ## 固定機能パイプラインとの比較(OF-DPA・SAI) 固定機能パイプラインの側にも同型の二重構造がある。ベンダー定義の[[OF-DPA]](Broadcomが自社ASIC向けに提供するハードウェア抽象化レイヤー)と、コミュニティ定義の[[SAI (Switch Abstraction Interface)]](Open Compute Projectが策定する、複数ベンダーの最大公約数機能に絞った論理パイプライン)がそれである。第4章はこの2つを、P4側の「TNA(ベンダー定義)対V1Model/PSA(コミュニティ定義)」という対と構造的に対応づけ、5種類のPipeline/SDK/ASICスタック比較(図26)で、P4アーキテクチャモデルが従来の固定機能スイッチSDKと機能的に等価な役割を果たすことを示す。P4で定義された論理パイプラインを持つ構成のみがP4Runtimeで制御可能であり、これはP4Runtimeインターフェースが当該P4プログラムから自動生成される仕組みによる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.5, §4.6) ## SAIはパイプラインを記述する手段を提供しない(『実践SONiC入門』第9章) 第4章はSAIを「コミュニティ定義の論理固定機能パイプライン」として抽象的に位置づけるにとどまるが(前掲「固定機能パイプラインとの比較」節)、『実践SONiC入門』第9章はSAIによる抽象化がAPIレベルで具体的に何を利用者に与え、何を与えないかを明らかにする。SAIはSwitch ASICの機能(テーブル・レジスタ・処理回路など)をSAIオブジェクトへ抽象化し、CRUD操作を可能とするAPIとして定義される。P4がフォワーディングパイプラインの振る舞いそのものをプログラムとして記述し、コンパイルしてターゲットチップに書き込むのに対し、SAIはパイプラインの構造自体をユーザーが記述する手段を提供しない。パイプラインは機能ごとにSAI仕様側で事前定義され(OCP管理のSAIリポジトリ`/doc/behavioral model`に`pipeline_vXX.vsdx`として保存、現在v10)、SAI APIの利用者はその既定パイプラインが生成するSAIオブジェクト(VLAN・ROUTE_ENTRY・NEXT_HOPなど)にアトリビュートを設定するにとどまる。すなわち「固定機能パイプラインをAPIで抽象化する」とは、パイプライン構造を記述する能力ではなく、既定のパイプラインが公開するオブジェクトを設定する能力を利用者に与えるという意味であり、これはP4の「パイプライン自体をプログラムする」自由度とは異なる次元の抽象化である。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 9 SAI詳細解説［API・オブジェクト・データプレーンパイプライン］]] ch.9 §9.1.1, §9.2.1) SAIのパイプライン記述(マッチ・アクション・テーブルの列、メタデータの受け渡し)は、P4/PISAのMatch-Action Unit記述と同じ語彙("テーブルを順に実行する")を共有しながら、テーブルが物理的に何のメモリ技術(SRAM/TCAM)で実装されるかには一切踏み込まない。PISAのMatch-Action Unitの説明(前掲「PISA構造とP4アーキテクチャモデル」節)がTCAM/SRAMのコスト・消費電力トレードオフまで踏み込むのに対し、SAIはSAIオブジェクトという論理単位までしか抽象化を進めない。テーブル分割(単一テーブルに集約するか複数テーブルに分散するか)の設計トレードオフと具体例は[[パケット処理パイプラインのテーブル分割]]を参照。(Source: ch.9 §9.2.1〜§9.2.3) ## 横断的知見 - **P4 の価値提案は「コントロールプレーンの表現力向上」から「データプレーン自身が観測データを生成する」へと広がった**: ch.5 は P4 を一貫してコントロール/データプレーン間インターフェース(P4Runtime)の自動生成という文脈で語り、フォワーディングルールの記述・検証に焦点を当てる(ch.5 §5.2, §5.3)。一方 [[インバンドネットワークテレメトリ]] concept が扱う INT(In-band Network Telemetry)は、同じプログラマブルデータプレーン(P4)を「コントロールプレーン介入なしにデータプレーン内で直接」テレメトリ情報をパケットに埋め込む用途に転用しており、P4 Applications Working Group(2025)がこれを標準化している。つまり P4 が実現する「パイプラインをソフトウェアで記述できる」という能力は、ch.5 が強調するフォワーディング制御の柔軟化だけでなく、フォワーディングと同時にネットワーク自身を計測可能にするという、ch.5 の射程には無かった応用にまで広がっている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **「オープンかクローズドか」という ch.5 の対立軸は、INT のスイッチ非依存化という設計判断を先取りしている**: ch.5 §5.3 は、プログラム可能性の実質的な価値がベンダーによる変更許容度(オープン性)にあり、固定機能かどうかは二次的だと論じる。INTFusion([[インバンドネットワークテレメトリ]] concept が扱う IFIP Networking 論文)は INT のソース/シンク機能をスイッチから SmartNIC へオフロードし、スイッチ側には INT トランジット機能のみを要求する設計を採る。これは、スイッチベンダーの P4 実装がクローズドであっても SmartNIC 側でオープンな拡張ができれば全体としての「プログラム可能性」を確保できる、という ch.5 の主張の具体的な実装例になっている。(Source: ch.5 §5.3, [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **IPU/DPUは、スイッチASICとは別の場所に置かれた「もう一つのP4プログラマブルデータプレーン」である**: ch.5 は SmartNIC/IPU を P4 の有望な適用対象として名前を挙げるにとどめていた(§5.3)が、ch.10 はこれを具体化する。Intel IPU ファミリの Mount Evans ASIC は、ARM CPU コアに加えて Barefoot Networks 由来の P4 プログラマブルなネットワーキングハードウェアを搭載しており、PISA ベースの完全にプログラム可能なデータプレーンをスイッチ ASIC の外(サーバ側)に持ち込む。ch.10 は、仮想スイッチのような複合機能を丸ごとオフロードするにはオフロードエンジンが完全にプログラム可能である必要があり、部分的なプログラム可能性では機能の一部しか移せずボトルネックが残ると説明する(ch.10 §10.2)。これは、スイッチ ASIC における「プログラム可能対固定機能」という対立軸(ch.5 §5.3)が、IPU/DPU という別のハードウェア形態でも同じ理屈で成立することを示す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]]) - **ch.5の「オープン対クローズド」という対立軸は、ch.4が示す構造(TNA対V1Model/PSA、OF-DPA対SAI)に具体的な裏付けを持つ**: ch.5 §5.3はプログラム可能性の実質的価値がベンダーの変更許容度(オープン性)にあり、固定機能かどうかは二次的だと論じるにとどまるが、ch.4はこれを裏付ける具体的な二重構造を示す。プログラム可能パイプライン側では「ベンダー定義のTNA」対「コミュニティ定義のV1Model/PSA」、固定機能パイプライン側では「ベンダー定義のOF-DPA」対「コミュニティ定義のSAI」という、同型の対立が独立に存在する。つまり「オープンかクローズドか」という軸は、プログラム可能/固定機能という区分を横断して現れる別次元の分類であることが、ch.4のアーキテクチャモデル一覧によって実証的に示される。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.3, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.3, §4.5, §4.6) - **ch.10のMount Evans ASIC(Barefoot由来のPISA)は、ch.4が説明するTNA/PISA構造そのものをスイッチ ASICの外へ持ち出した実例である**: ch.10 はMount EvansがPISAベースの完全にプログラム可能なデータプレーンをIPU上に搭載すると述べるにとどまるが、ch.4はそのPISAの内部構造(Parser・Match-Action Unit・Deparser)とBarefootのアーキテクチャモデルTNAの位置づけ(ベンダー固有、V1Model/PSAより低レベルな能力を露出)を具体的に定義する。これにより、ch.10が指摘する「IPU側のP4プログラマブルデータプレーン」が、スイッチASIC向けと全く同じ設計原理(PISA+アーキテクチャモデル+具体的P4プログラム)の転用であり、IPU固有の別設計ではないことが確認できる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]] ch.10 §10.2, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.2, §4.3.2) - **ch.5・ch.4が語る「プログラム可能対固定機能」の技術的な必然性に、第1章はTCAM容量制約とVXLANという2つの具体的な引き金を与える**: ch.5・ch.4はプログラマブルパイプラインとPISA/P4アーキテクチャモデルの構造を詳述するが、なぜこの区別が重要になったのかという動機には深入りしない。第1章§1.2.3は2つの具体的な引き金を示す——(1) フローテーブルを実装するTCAMの収容エントリ数が限られ、コントローラがパイプラインの詳細を意識せざるを得なくなったという性能問題、(2) VLANの4096通りというタグ空間がクラウドの全テナントを賄うには不十分になり、IETFがVXLAN(仮想Ethernetフレームを UDPパケットでカプセル化する新しいカプセル化方式)を導入せざるを得なかったというプロトコルスタックの想定外の変化。後者は固定機能パイプラインへの対応にハードウェア変更を要するのに対し、プログラム可能パイプラインならソフトウェア更新で追随できる非対称性を具体的に示す一次資料である。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 1 Introduction]] ch.1 §1.2.3) - **ch.4が定義する`arch.p4`という抽象契約(TNA/V1Model/PSA)は、ch.5が示す具体的な自動生成トレースを辿ることで初めて「絵に描いた契約」から実行可能な成果物になる**: ch.4はPISA・アーキテクチャモデル(`arch.p4`)・具体的P4プログラム(`switch.p4`)という3層構造を静的な設計図として提示するが、この構造がどうやって実際に動くコントローラ⇄スイッチ間の通信へ変換されるかまでは踏み込まない。ch.5 §5.2はこの空白を埋め、P4コンパイラが `arch.p4` に従って書かれた `forward.p4` から (1) スイッチングチップにロードするバイナリと (2) `forward.p4info` という protobuf 定義(P4Runtime Contract)の両方を自動生成する具体的なトレースを示す。`p4info` はテーブル・アクション・カウンタ・メータといった `arch.p4` が許した「制御可能な要素」を機械可読な形で列挙したものであり、ch.4が定義した抽象契約(アーキテクチャモデル)が、ch.5では protobuf という具体的なワイヤフォーマットの契約に変換される様子が確認できる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.2, §4.3, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.2) - **P4Runtime(フォワーディング制御)とgNMI(構成)は、ch.5では別々のインターフェースとして並置されるが、両者は「宣言的な仕様からgRPC/protobufスタブを自動生成する」という同じ設計パターンの2つのインスタンスである**: P4Runtimeは`arch.p4`+`forward.p4`というP4プログラムからp4info(protobuf)とgRPCスタブを自動生成し、gNMIはYANG/OpenConfigモデルからgRPCスタブを自動生成する(YANGツールチェーン、図29)。いずれも「モデル/プログラムをコンパイルしてランタイムインターフェースを生成する」という同型のワークフローを持ちながら、ch.5はこの2つを別々の節(§5.2と§5.3)で並べるだけで、両者に共通する設計パターンそのものは明示的に言語化しない。プログラマブルデータプレーンという概念の射程は、フォワーディングパイプラインの記述だけでなく、それを制御するインターフェースの生成過程そのものにも「プログラムから自動生成する」という発想が及んでいることを示す。(Source: ch.5 §5.2, §5.3) - **『実践SONiC入門』のPINS事例は、ch.5が概念として述べる「SONiCとStratumの統合」を、Google一社の具体的な採用理由とデータフロー実装として実証する**: [[SAI (Switch Abstraction Interface)]] concept・[[SONiC]] entityが既に記録するとおり、ch.5 §5.4はPINSを「SONiCとStratumという同じ需要を満たす2つのOSSコミュニティの統合」という抽象的な取り組みとして紹介するにとどまる。[[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.5は、この統合が実際に誰によってなぜ使われているかを一次事例で肉付けする——GoogleはSDNコントローラー「Orion」でB4/Jupyterを制御してきた自社の経験を背景にPINSを[[Open Networking Foundation]]・[[Microsoft]]・Intelと共同開発し、SDNコントローラーの設定をP4Runtime経由でAPPL_DBに登録、P4OrchでASIC_DBへ変換するという具体的なデータフローで実装している。著者はGoogleのようなハイパースケーラー以外でPINSを自社サービスに利用できるユーザーは少ないと評しており、ch.5が描く「2つのOSSコミュニティの統合」という理念が、実際には限られた採用者(ハイパースケーラー)に閉じている状況を示す。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.5, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.4) - **『実践SONiC入門』第9章が示すSAIオブジェクト/アトリビュートモデルの具体的な仕組みは、ch.4が抽象的に述べる「TNA対V1Model/PSA、OF-DPA対SAI」という構造的対応の、SAI側の実装詳細を初めて肉付けする**: ch.4はP4アーキテクチャモデル(`arch.p4`)とSAIをともに「コミュニティが定義する抽象パイプライン」として並置するが、SAI側がどのようなAPI形式(ヘッダファイル・メソッドテーブル・アトリビュート)でこの抽象化を実現しているかには立ち入らない。ch.9はこの空白を埋め、SAIオブジェクトが`SAI_OBJECT_TYPE_*`という型と`sai_object_id_t`というID(または構造化キーを持つ「エントリ」オブジェクト)で参照され、`sai_api_query()`によってメソッドテーブル(`sai_<機能名>_api_t`)を取得してCRUD操作を行う、という具体的な機構を示す。これはch.4の`arch.p4`(P4コンパイラとの契約)に相当するSAI側の契約が、P4のようなコンパイル可能な言語ではなく、CでコンパイルされるヘッダファイルとCRUD APIという形を取ることを裏付ける。(Source: ch.9 §9.1.1, §9.3, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.3, §4.5, §4.6) ## 未解決の問い - SAIのパイプラインが機能ごとに事前定義され利用者が変更できない(ch.9 §9.2.1)のに対し、P4/PISAのMatch-Action Unitはコンパイラが物理スロットへ動的に割り当てる(ch.4 §4.2)。この「事前定義された固定パイプライン」対「コンパイル時に割り当てが決まる可変パイプライン」という違いは、ch.5が主張する「オープン対クローズド」という対立軸(§5.3)とどう関係するか——SAIのパイプラインが事前定義であること自体は、OCPでの合意プロセスが「オープン」であることと両立しうるのか、それとも構造的にクローズドな設計を強いるのか、本書横断では未整理。 - PINSの実際の採用者がGoogleに限られる(ch.2 §2.2.5)という観察は、「プログラム可能パイプライン対固定機能パイプライン」の対立軸(ch.4)における[[SAI (Switch Abstraction Interface)|SAI]]側の広範な普及(多数ベンダー・多数ユーザー)と比べたとき、PINSの採用障壁(SDNコントローラー開発・サービス統合という大規模プロジェクトが前提)がP4プログラマブルデータプレーン一般の普及にどこまで一般化できるか、他のP4採用事例(INT等)と比較検証する余地がある。 - Intel の Tofino 3 開発中止(ch.5 §5.3)は、INT のような P4 ベースの実運用アプリケーションの今後のハードウェアターゲット選定にどう影響するか。SmartNIC・IPU へのオフロードは、この特定チップ依存からの回避策として機能しているか。 - ch.5 が言う「仕様記述言語としての P4」(RFC のエンジニアリング判断を P4 プログラムで補う)は、INT のような標準化団体(P4 Applications Working Group、IETF IOAM)の仕様と実装の関係にすでに現れているか。 - IPU/DPU 上の P4 データプレーンは、スイッチ ASIC(Tofino 等)と比べて絶対性能(スループット・レイテンシ)でどの程度の差があるか。ch.10 は定性的な位置づけを示すにとどまり、本書には定量比較が出てこない。 - V1ModelがPSAより広く使われる理由(ベンダーがPSA向けコンパイラバックエンドを未提供、ch.4 §4.3.1)は、業界の足並みの遅れという実務上の力学であり、ch.5が語る「オープン対クローズド」の理念とは別軸の障壁である。この足並みの遅れはいつ・どう解消されるのか、あるいは解消されないまま固定化するのか。 - OF-DPA/SAIという固定機能側の抽象化とV1Model/PSA/TNAというプログラム可能側の抽象化がch.4の言うとおり構造的に対応するなら、INT(インバンドネットワークテレメトリ)のような新しいプログラマブルデータプレーン応用は、OF-DPA/SAIのような固定機能パイプライン側でも(部分的にでも)実現可能なのか、それともプログラム可能パイプライン限定の応用なのか。本書には記述がない。 - P4RuntimeとgNMIが共有する「宣言的仕様からgRPC/protobufスタブを自動生成する」という設計パターン(ch.5 §5.2, §5.3)は、本書の他の場面(例えばgNOIやNETCONF/RESTCONF向けのXML/JSON生成)にも同型に現れるのか。仮に現れるなら、これはSDNソフトウェアスタック全体に通底する一般原則と言えるが、ch.5はP4RuntimeとgNMIを個別の節で説明するにとどまり、両者を貫く単一の原則としては言語化していない。 ## 関連 - 概念: [[ソフトウェア定義ネットワーク]] / [[インバンドネットワークテレメトリ]] / [[データセンターネットワークトポロジ]] / [[スマートNICオフロード]] / [[ドメイン固有アーキテクチャ]] / [[抽象化(ソフトウェア設計)]] / [[パケット処理パイプラインのテーブル分割]] - 実体: [[OpenFlow]] / [[P4]] / [[P4Runtime]] / [[Intel IPU]] / [[Intel Tofino]] / [[OF-DPA]] / [[SAI (Switch Abstraction Interface)]] / [[Open Compute Project]] / [[Stratum]] / [[PINS (P4 Integrated Network Stack)]] / [[Google]] - 関連 MOC: [[Network - MOC]] ## 出典 - [[@2025__Gihyo__実践SONiC入門 - Chapter 9 SAI詳細解説［API・オブジェクト・データプレーンパイプライン］]](§9.1.1、§9.2、§9.3、SAIオブジェクト/アトリビュートモデルの具体的な仕組み、パイプラインの事前定義性) - [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]](§2.2.5、PINSの具体的な採用事例(Google)とP4Runtime/APPL_DB/ASIC_DBのデータフロー) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]](OpenFlow と P4 の対比、PISA、P4Runtime、オープン/クローズドの対立軸) - [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]](P4 ベースのインバンドネットワークテレメトリへの応用) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]](IPU/DPU上のP4プログラマブルデータプレーン、Mount Evans ASIC) - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 4: Bare-Metal Switches, §4.2, §4.3, §4.5, §4.6.(PISA構造、V1Model・PSA・TNA、OF-DPA・SAIとの構造的対応) - 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(プログラム可能対固定機能が重要になった2つの技術的引き金: TCAM容量制約、VXLAN) - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 5: Switch OS, §5.2, §5.3. https://sdn.systemsapproach.org/stratum.html(P4RuntimeとgNMIの自動生成トレース、arch.p4契約の具体化)