# P4 P4 は、フォワーディングのパイプラインをプログラムするための言語であり、今や SDN ソフトウェアスタックの中核を成す。[[OpenFlow]] の柔軟性から生まれた「データプレーン自体もプログラム可能であるべき」という圧力がチップベンダーに働いたことで登場した。P4 で記述されたプログラムからは、コントロール/データプレーン間インターフェースである P4Runtime をソフトウェア的に自動生成でき、標準化プロセスの速度に縛られないインターフェース進化が可能になる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] ch.5 §5.2) ## 仕様言語としての側面 P4 には「フォワーディングパイプラインをプログラムするツール」という側面だけでなく、「パイプラインの実装方法とは独立に、その振る舞いを仕様として記述する手段」という価値もある。Google のような企業も振る舞いの定義をハードウェア抽象化レイヤーとして使い始めている。著者 Larry Peterson は、ネットワーク事業者がベンダーに要件を指定する標準的な手段として P4 プログラム(および P4Runtime)が使われるようになり、RFC に記述されるようなエンジニアリング上の判断や設計根拠を P4 プログラムが補うようになる可能性を展望している。(Source: ch.5 §5.3) ## PISA と性能特性 PISA(Protocol Independent Switch Architecture、P4 で動作を定義できるスイッチ用パイプライン構造)ベースのチップ上にコンパイルされた P4 プログラムは、ASIC で実装された固定機能製品と同等の性能・ダイ面積・コスト・消費電力を達成できる。この定量的な同等性が P4 の市場受容の前提だった。2023年に Intel が専用チップ Tofino 3 の開発中止を発表したが、これは P4 コミュニティが半導体性能の向上に頼らず言語そのものの価値を証明する局面への転換点になり得ると評価されている。P4 の適用対象は SmartNIC や IPU にも拡張されつつある。(Source: ch.5 §5.3) ## 「オープン対クローズド」という対立軸 P4 をめぐる議論では「プログラム可能対固定機能」よりも「パイプラインがオープンかクローズドか」という対立軸のほうが本質的である。パイプラインがプログラム可能かどうかは、ベンダーがどこまでの変更を許すかという制限の度合いにすぎず、この制限の影響を最も強く受けるのは新機能を実験したい研究者である。(Source: ch.5 §5.3) ## サービスメッシュとの関係 P4 でプログラミングされたパイプラインは、Envoy のサイドカー・eBPF/XDP のカーネルモジュールと並んで「プログラム可能なフォワーディングエンジンとしてエンドツーエンドなサービスの接続性を実装する選択肢」の一つとして位置づけられる。サイドカーの一部の機能を P4 のスイッチングファブリックにオフロードできる可能性があり、性能と表現力の良いとこどりの最適な適用箇所は仮想スイッチや SmartNIC になり得る。(Source: ch.5 §5.6) ## 教科書におけるハードウェア側の位置づけ [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] §3.5.2は、P4が動作させるハードウェア側の構成をより低レイヤーの視点で補完する。ベアメタルスイッチが搭載するNPU(Network Processing Unit)は、SRAM(パケットバッファ)・TCAM(Ternary Content Addressable Memory、ワイルドカード付きの表引きを可能にするメモリ)・(Match, Action)ペアの多段パイプラインという3要素で構成され、複数段のパイプラインが複数パケットを並行処理することでTbps級のスループットを達成する。P4はこの多段(Match, Action)パイプラインの振る舞いを記述する言語として位置づけられ、上記のPISA(Protocol Independent Switch Architecture)という抽象化と対応する。ch.5がP4の言語的側面(ハードウェア抽象化レイヤー、ベンダー要件記述手段としての将来性)を論じるのに対し、こちらはP4が対象とするチップ内部の物理的な処理段(SRAM/TCAM/パイプライン)を具体的に説明する。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] §3.5.2) ## PISAパイプラインとアーキテクチャモデル(V1Model・PSA・TNA) *Software-Defined Networks: A Systems Approach* 第4章は、上記のPISA(第4章での正式名称はProtocol Independent Switching Architecture)を構成するParser・複数のMatch-Action Unit(SRAM/TCAM+ALU)・Deparserという3要素を具体的に説明し、それをP4がどう抽象化するかを掘り下げる。P4プログラムは`forward.p4`(フォワーディング挙動を定義する開発者向けプログラム)と`arch.p4`(P4コンパイラとの契約であり、利用可能なプログラム可能ブロック・インターフェース・型を定義する「ヘッダファイル」)の2種類に分かれる。`arch.p4`の具体例として、コミュニティ寄りのPSA(Portable Switch Architecture、write-once-run-anywhereを狙う抽象目標マシン)・実務で広く使われるV1Model(PSAより単純、P4_14からの移植を容易にする参照アーキテクチャ)・ベンダー定義のTNA(Tofino Native Architecture、Barefootが自社チップ向けに定義)が挙げられる。P4アーキテクチャモデルが定義するのは(1) ブロック間インターフェースのシグネチャ、(2) extern(チェックサム・暗号化などの追加固定機能サービス)の型宣言、(3) コアP4言語型の拡張(`range`・`lpm`などのマッチ型)の3つである。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.2, §4.3) 実際のP4プログラムはヘッダ宣言・パーサ(状態遷移図)・イングレス処理(`action`と`table`によるMatch-Action)・イグレス処理・デパーサ(`emit`による再直列化)・スイッチ定義(`V1Switch(...)`)という6ブロックの定型構造を持ち、ループ・ポインタ・動的メモリ確保を持たないC言語に近い構文で書かれる。P4は`table`定義のみを行い実際のエントリ投入(コントロールプレーンからの書き込み)はP4Runtimeが担う、という役割分担が第4章で明示される。従来型L2/L3スイッチ相当の機能を実装するプログラムは`switch.p4`(Barefootの非公開実装)や`fabric.p4`(V1Model向けのオープンソース版、SD-Fabricで使用)と呼ばれ、下記「本番リーフスパインファブリックでの具体例」の`fabric.p4`と同じ系譜にある。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.3.2, §4.4) ## 固定機能パイプラインとの比較(OF-DPA・SAI) 固定機能スイッチングチップにも論理パイプラインの抽象化層が存在し、P4アーキテクチャモデルと機能的に対応する。ベンダー定義の[[OF-DPA]](Broadcom)はTNAに相当し、コミュニティ定義の[[SAI (Switch Abstraction Interface)]]はV1Model/PSAに相当する。P4アーキテクチャモデル(`arch.p4`)+具体的プログラム(`switch.p4`)という2層構造は、従来の固定機能スイッチにおける「論理パイプライン定義+SDK」という2層構造と同じ役割分担を果たす、という比較が第4章の結論部(比較節)で示される。P4で定義された論理パイプラインを持つ構成のみがP4Runtimeで制御可能であり、これはP4Runtimeインターフェースが当該P4プログラムから自動生成される仕組みによる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.5, §4.6) ## 合成的ネットワークアーキテクチャのプロトタイプ実装(The Real Internet Architecture 第6章) *The Real Internet Architecture* 第6章は、レイヤリングとサブダクションを標準化された演算子として実装する具体例として、P4 によるプロトタイプ実装を報告する。合成的ネットワークアーキテクチャ(compositional network architecture, CNA)のレイヤリングインターフェース(オーバーレイのリンクをアンダーレイのセッションが実装する構造)は、P4 プログラムがコンパイルされるプログラマブルパケット処理チップ上のハードウェアパイプラインとして実現できる。この実装では、パケットに対する全ての操作(オーバーレイ・アンダーレイ双方に論理的に属する操作を含む)が、バッファリングを伴わない一連のハードウェアパイプラインステージとして逐次実行される点が、ソフトウェア実装(バッファを介した4つの実装アクション: linkTransmit・linkAcquire・sessionSend・sessionReceive)と最も異なる。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 6 Ideas for a Better Internet]] ch.6 §6.2.2.2) このプロトタイプはさらに、[[モジュラー検証]]の議論(§6.3)で示唆される「過度な一般性の除去による最適化」の具体例としても使われる。汎用的な実装は8段のハードウェアステージを要するが、「オーバーレイのリンクは全て仮想リンクである」「このマシン上のアンダーレイメンバーは制御メッセージを送受信しないユーザメンバーに過ぎない」という2つの特殊化の仮定を組み込むだけで、論理分岐の多くを除去し4段のパイプラインへ最適化できる。結合された段のマッチアクションテーブルは元のテーブルのjoinであり、元の関係の多くが関数であるため、結合後のテーブルは元の最長テーブルより大きくならない。この事例は、汎用的な構造を特殊化する際、少数の仮定でも大きな最適化効果が得られることを示す。最適化には2つの安全原則が伴うべきだとされる: (1) 設計者はどの機能を排除しているかを理解せずに一般性を除去してはならない、(2) 最適化は将来の拡張性のためできる限り可逆であるべきである。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 6 Ideas for a Better Internet]] ch.6 §6.5.1, §6.5.2) ## 本番リーフスパインファブリックでの具体例: fabric.p4(SD-Fabric) *Software-Defined Networks: A Systems Approach* 第7章は、[[SD-Fabric]] の転送プレーンを実装するP4プログラム`fabric.p4`を、P4の本番採用例として報告する。`fabric.p4`はBroadcom OF-DPAパイプラインを緩く参考にしつつSD-Fabricが不要とするテーブルを省いて単純化されており、ONOSのFlowObjective API(Filtering・Forwarding・Next)に対応する構造を持つ。上記の『ネットワークシステムについて語るときに我々の語ること』第5章が語るP4の言語的側面(ハードウェア抽象化レイヤー、ベンダー要件記述の将来性)や『Computer Networks: A Systems Approach』第3章が語るチップ内部の物理構造(SRAM/TCAM/パイプライン)を、この`fabric.p4`は具体的な本番プログラムとして補完する。特徴的なのは、プリプロセッサ条件分岐(`#ifdef`)によってUPF(4G/5Gモバイルネットワーク)・BNG(Fiber-to-the-Home)・INT(Inband Network Telemetry)という拡張機能を選択的に組み込める点である。これは低レベルな設定可能パイプライン構築手法であり、実行時に動的に機能を追加できるような高水準な言語構成は今後の研究課題として著者ら自身が認めている。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 7 Leaf-Spine Fabric]] ch.7 §7.4) ## P4Runtimeという独立した制御インターフェース(第5章) *Software-Defined Networks: A Systems Approach* 第5章は、P4 言語そのものと、実行時にテーブルエントリを読み書きする制御インターフェース [[P4Runtime]] を明確に分離して扱う。P4 コンパイラは (1) 各スイッチングチップにロードされるバイナリと、(2) そのチップを間接的に Switch OS 経由で制御するランタイムインターフェース(P4Runtime Contract、`p4info` という protobuf 定義として specify される)の両方を生成する。[[Stratum]] はこの P4Runtime を、[[gNMI]]・gNOI と並ぶ3つの主要ノースバウンドインターフェースの一つとして公開する。P4Runtime の詳細な機構(gRPC メソッド、`p4info` の構造、コントローラ側での利用例)は専用ページ [[P4Runtime]] に切り出した。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.1, §5.2) ## UPF(User Plane Function)のP4実装(第9章) 第9章は`fabric.p4`への`upf`拡張を、5G Mobile CoreのデータプレーンであるUPF(User Plane Function)をプログラマブルスイッチへオフロードする具体例として報告する。UPFが担う追加タスクは3つある。(1) 基地局との間で送受信するGTP-over-UDP/IPパケットのカプセル化/デカプセル化、(2) オペレータが提供したいQoSレベルに応じたパケットのキューイング。この2つはP4と配下のプログラマブルスイッチで素直に実装できる。(3) 最近移動したUE宛のパケットを、対応するセッション状態が遷移中の間「保留」してパケットロスを防ぐ処理。これは現行のP4スイッチでは扱えないため、代わりにサーバ(またはサーバに接続されたSmartNIC)へパケットを一時的にリダイレクトしてhold-and-replayする。P4/プログラマブルスイッチがそのまま実装できる範囲と、サーバ側にオフロードせざるを得ない範囲の境界線を示す実例になっている。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 9 Access Networks]] ch.9 §9.4) ## 第3章(Basic Architecture)によるスタック概観での位置づけ *Software-Defined Networks: A Systems Approach* 第3章は、P4 をスタック概観図(図15)の左側に「関連する P4 Toolchain」として置き、後続章の詳細に先立つ最も抽象的な導入を与える。§3.2 は、固定機能チップ(Tomahawk)であっても P4 プログラムが要る理由を「コントロール/データプレーン間 API の生成には、フォワーディングパイプラインの形式仕様が要るから」という一般論として説明する——`forward.p4` はプログラマブルチップではパイプラインを *規定* し、固定機能チップでは単に *記述* するにとどまるが、いずれの場合もツールチェーンは `arch.p4` と合わせてこの `forward.p4` を用いて制御/データプレーン間の API を生成するため、両ケースで必要になる。この一般論は、上記「PISAパイプラインとアーキテクチャモデル」節が詳述する第4章の `switch.p4`/`fabric.p4` や TNA/V1Model/PSA の分類より手前にある。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.1, §3.2) ## 検証可能性の鍵としての言語制約(第10章) *Software-Defined Networks: A Systems Approach* 終章(第10章)は、P4 の言語的制約そのものを検証可能性(verifiability)の鍵として位置づける。P4 データプレーンはネットワークの「グラウンドトゥルース」(実際にどうパケットを転送しているか)を捕捉し、汎用言語で書かれ複雑になりがちなコントロールプレーンと異なり、効率的でフィードフォワードなパイプライン構造・単純な型・限定的な状態しか持たないようコンパイルされる。P4 が言語としてループやポインタベースのデータ構造を意図的に排除していることが鍵であり、これらは一般に解析を非現実的にする要因である。汎用ソフトウェアの検証は一般に不可能でも、この制約ゆえにデータプレーン検証は強力かつ実践的になる。転送の振る舞いが既知・固定であれば、フォワーディングテーブルの状態そのものがネットワークの挙動を規定するという考えは Veriflow や Header Space Analysis(HSA)によってすでに実用化されており、P4 はここに「フォワーディング挙動そのものをプログラム(時間とともに変化させることも)できる」という新しい自由度を一つ加えるにすぎないと位置づけられる。この検証可能性の機会をさらに具体化した文献として、本章は Jed Liu らの "p4v: Practical Verification for Programmable Data Planes"(ACM SIGCOMM 2018)を挙げる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]]) ## 関連 - [[OpenFlow]] — P4 が部分的解決を与える先行技術 - [[Open Networking Foundation]] — ONF のフラッグシッププロジェクト Aether が OpenFlow から P4 ベースの SDN へフォーカスを移している - [[Nick McKeown]] — P4 Forum への投稿でコミュニティの懸念に応えた人物 - [[ソフトウェア定義ネットワーク]] / [[プログラマブルデータプレーン]] / [[インバンドネットワークテレメトリ]](P4 ベースの応用例) - [[モジュラー検証]](P4 プロトタイプが具体化する過度な一般性の除去による最適化) - [[SD-Fabric]] — fabric.p4 が転送プレーンを実装する対象 - [[OF-DPA]] / [[SAI (Switch Abstraction Interface)]] — 固定機能パイプライン側で対応する抽象化層 - [[P4Runtime]] — P4 プログラムから自動生成される実行時制御インターフェース(第5章) - [[ソフトウェア定義アクセスネットワーク]] — UPFのP4オフロードが位置づけられるアクセスネットワークへのSDN原則適用という文脈 - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]] - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 3 Internetworking]] - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 7 Leaf-Spine Fabric]] - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 9 Access Networks]] - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] - [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 6 Ideas for a Better Internet]] - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 10 Future of SDN]] — P4 の言語制約(ループ・ポインタ構造の排除)が検証可能性を可能にする鍵として位置づけられる ## 出典 - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 5 SDN：ソフトウェア定義ネットワーク]](ch.5 §5.2, §5.3, §5.6) - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 3: Internetworking, §3.5.2. https://book.systemsapproach.org/internetworking.html - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 6, §6.2.2.2, §6.5.1, §6.5.2. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 7: Leaf-Spine Fabric, §7.4. https://sdn.systemsapproach.org/trellis.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 4: Bare-Metal Switches, §4.2, §4.3, §4.4, §4.5, §4.6. https://sdn.systemsapproach.org/switch.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 5: Switch OS, §5.1, §5.2. https://sdn.systemsapproach.org/stratum.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 9: Access Networks, §9.4. https://sdn.systemsapproach.org/access.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 3: Basic Architecture, §3.1, §3.2. https://sdn.systemsapproach.org/arch.html - 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