P4とは簡単にいうと「パケットを受け取った際に、そのパケットの中身により処理を行い、送信するまでの動作を
記載するプログラミング言語」です。
例えば特定の特徴を持つパケットを受け取った際には異なるルート情報に書き換える（情報を乗せ換える）、と
いったパケットごとの処理が可能になります。

ユースケースとしても上記のようなパケットごとに処理を変えるような、パケットベースの制御や
パケットヘッダを書き換える（定義したヘッダを加える）ことによる、NW機器がまだ実装できていない機能の実現等が
あげられます。
前者はNW機器の設定でいうPBRに近いものとなりますが、P4は前述の通りプログラミング言語の為、ある程度の自由度もあり、
使い様によってより柔軟なNWを構成できる可能性があると言えます。
また、特定形式のパケットを使って制御を行うという観点からP4QCN（P4で実現する輻輳技術）のようなものも存在します。
　　　　　　　　　　　　　　　　　　　　　　　　図1 P4のユースケース例

ところで「パケットを処理」というと、DPDKを思い浮かべる方もいるかもしれません。
DPDKはパケットを高速処理する為のライブラリとネットワークドライバです。
よってプログラム（C)にてライブラリ(DPDK)を活用する事で高速なパケット処理が可能となります。
その点でP4はそのものがプログラム言語になる為、正確には立ち位置が少し異なります。

DPDKについて詳しく知りたい方は、まずはこちらからご確認ください。
DPDKを使うアプリケーション例をご覧になりたい方は、こちらをご確認ください。

DPDK＋CとP4を「パケットを処理するプログラム」と見た時に適用先は広い、という点は共通しています。

種類	適用先
P4	P4対応スイッチ(P4対応ASIC搭載)や汎用サーバ(正確にはCPUでx86等)等。
DPDK＋C	汎用サーバ用アプリやホワイトボックススイッチ用ソフトウェア等。

一方で違いはというと、一般的な傾向として以下のようなことがあげられるかと思います。

概要	説明
実装の敷居について	P4はパケット処理用の特化言語でもある為、 個人的な主観もあるが、DPDKと比較すると、 実装はしやすい印象。 また、P4のできる範囲内においては少ない労力で 実現が可能。 DPDKはパケット処理用のライブラリであり、 細かい制御や処理はプログラム（C)側で実装する必要があることから、 P4より敷居が高い印象。 また、DPDKとC言語を組み合わせる為、使用する際に相応の 労力がかかる。
ユースケースの広さ について	P4は受け取ったパケットから、そのパケットをどう処理するか といったデータプレーンがスコープとなる。 また、受け取ったパケットの統計を取って新たなパケットを生成する、 といったことはできない、といった一部制約もある。 DPDKはあくまでライブラリであり、多くの処理は ライブラリを呼び出すプログラム(C)で記載する分、自由度が高い。 例えばP4では実現できない統計パケットの生成や、データプレーンと コントロールプレーンの同時実装も可能。
適応先と性能について	P4を汎用サーバ上で実装する場合は性能がネックになりがち。 （その為、P4に対応できる専用マシンでの活用が主） 一方のDPDKは「高速化用」のライブラリ群でもある為、 汎用サーバの性能を高いレベルで引き出すことが可能。 ※適用先の機器のスペックや、実装方式により、 　達成できる性能値は異なる為、どちらが早いかという単純比較は難しい

P4の中身についてもう少し見ていきましょう。
以下の図をご覧ください。

　　　　　　　　　　　　　　　　　　　　　　　　図２ P4で操作可能な範囲

P4では入り（ingress)と出(egress)の処理を記載できます。
具体的なプログラムでは、パケットがどのような構造か、パケットヘッダの情報をまず定義した上で
解析する情報を記載し、該当パケットのアクション（どのような処理を行うか）を記載します。

上記でも軽くは触れましたがP4は正確にはASIC（＝SmartNICの一種)を扱う為の言語でもある為、
似ていて当然ではありますが、一致するパケットの解析（マッチング処理）と、アクションの指定を行う
DPDKによるSmartNIC処理と流れが似ていますね。

※ DPDKによるSmartNIC操作についてはこちらをご参照ください

アクションの具体例としては「該当のパケットのコピー/ドロップ」「ヘッダ情報の追加や更新」などがあげられます。

ここからは本題のNOSの話に入っていきます。
NOSと組み合わせる場合、多くはP4対応ホワイトボックススイッチに
NOSを入れるケースがほとんどです。

P4スイッチに対応可能なNOSもいくつか存在しますが、
以降では弊社でかかわった事がある2つのNOSを紹介します。
それぞれ何が嬉しいのかといった点も触れていきます。

① Stratum

Stratumはホワイトボックス用のOSSなNOSで
その特徴はコントロールプレーン（制御機能）を実装していない点にあります。
その為、データプレーンとして活用され、コントロールプレーンは
コントローラとなる別マシンから制御を受ける事となります。

この際にコントローラから制御を受けるIFとして P4 Runtimeが使用されます。
P4 RuntimeとはざっくりいうとP4で動く機能を制御する為のAPIです。

つまりP4よりStratumを載せた機器はパケットの細部処理を行いつつ、
コントローラによりNW機器の集中管理が行えるようになる、といえます。

　　　　　　　　　　　　　　　　　　　　　　　図3 コントローラとStratumについて

これにより、ハードウェア(NW機器)とソフトウェア(NOS)の分離だけでなく、
第1回の最初にNWディスアグリゲーションの例としてSDNコントローラの例を
あげたように、コントロールプレーンとデータプレーンの分離も可能となります。

　　　　　　　　　　　　　　　　　　　　　図4 Stratumによるディスアグリゲーション

弊社ではStratumをP4 Runtimeを使って制御する調査に実績があります。

② SONiC

こちらは前回の第1回でも紹介したNOSとなります。
少しだけおさらいすると、本NOSもホワイトボックス用のOSSなNOSであり、
例えばBGPのような動的ルーティングとそれによるパケット転送が可能なものとなります。

こういったNOSとP4を組み合わせて使用できると何が嬉しいのか、という点ですが、
できる事は従来のNOSと変わらず、「NW機能の提供（＝制御も転送も行う）」となります。
一方、P4はNW機能自体というよりはパケットを見て、そのパケットをどう制御するか、が
観点となってきます。
よって、見ているポイントが異なる為、ユースケースも異なり、組み合わせる事で、より柔軟な
NW制御が可能となります。

　　　　　　　　　　　　　　　　　　　　　　　　　　図5 SONiCとP4の違い

組み合わせの例としては例えばSONiCの機能としてBGPで動的ルーティングを可能としつつ、P4により特定の構造のパケットは
加工して別ルートを通るようにして、より細かいQoSや制御を実現する事が可能とする、などがあります。

具体的なSONiCとP4言語で書いた自作プログラムの連携方法という意味では、こちらのAPRESIA Systems様の資料が
大変参考になりますので、ご興味があれば是非ご確認ください。

　　　　　　　　　　　　　　図6 SONiCとP4の連携アーキテクチャ（APRESIA Systems社様事例）

なお弊社ではSONiCを扱った実績もある他、ONL(Open Network Linux) +P4という組み合わせで検証した実例があります。

まず、実環境への導入という観点について記載します。
NOSとP4の組み合わせは、NOSによってホワイトボックススイッチだけでなく、汎用サーバで実現できるものもありますが、
汎用サーバの場合は機能的な実験で用いる場合が多く、基本的には性能的な観点からNW専用機器を使う事がほとんどです。

また、これはP4自体の課題でもありますが、P4による制御は条件分岐を多くすると管理含め煩雑化する為、関連して
複雑な処理もさせづらいという点のデメリットがあります。
独自言語ならではの癖といってもよいかもしれません。

更に第1回でも触れたNWディスアグリゲーション観点からNW機能（制御および転送機能）はNW機器に、
パケット書き換えはP4機器に、といったように役割に応じて分けて使われる場合もあります。
これはP4機器はパケット書き換え等の簡易処理を行うための補助機器として用いられる傾向があるともいえます。

　　　　　　　　　　　　　　図7 SDNコントローラとW機器、P4の役割に応じたユースケース例

「NW機能と細かいパケット処理の同時実行」という考え自体がユースケース含めまだ検討段階であることが
使い分けの理由の1つと考えられますが、他にも耐障害性の向上メリットや性能観点の確認といった
細かい確認事項も想定されます。
よってNOS自体の進歩やHWのさらなる性能向上、保守コスト低減の観点から分離した機能の統廃合という
トレンド発生すると、こういった技術も普及が進むかもしれません。