[論文レビュー] Programming Protocol-Independent Packet Processors

Pat Bosshart, Dan Daly+8 more|arXiv (Cornell University)|Dec 5, 2013

Software-Defined Networks and 5G参考文献 10被引用数 26

ひとこと要約

この論文は、ソフトウェア定義ネットワークにおけるパケットプロセッサをプログラミングするための高水準でプロトコルに依存しない言語P4を紹介する。P4は、異なるハードウェアターゲット上でパケットパースおよび処理論理のランタイム再構成を可能にし、P4プログラムを特定のスイッチアーキテクチャにマップするコンパイラによって低レベルの実装詳細を抽象化することで、柔軟で拡張可能かつベンダーアーキテクチャに依存しないネットワーク制御を実現する。

ABSTRACT

P4 is a high-level language for programming protocol-independent packet processors. P4 works in conjunction with SDN control protocols like OpenFlow. In its current form, OpenFlow explicitly specifies protocol headers on which it operates. This set has grown from 12 to 41 fields in a few years, increasing the complexity of the specification while still not providing the flexibility to add new headers. In this paper we propose P4 as a strawman proposal for how OpenFlow should evolve in the future. We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are deployed. (2) Protocol independence: Switches should not be tied to any specific network protocols. (3) Target independence: Programmers should be able to describe packet-processing functionality independently of the specifics of the underlying hardware. As an example, we describe how to use P4 to configure a switch to add a new hierarchical label.

研究の動機と目的

• OpenFlow 1.xの制限を解決するため、ヘッダーフィールドをハードコードしていること、および新しいプロトコルが登場するたびに拡張性に欠けること。
• 展開済みスイッチにおけるパケット処理のランタイム再構成を可能にし、動的プロトコル更新をサポートする。
• 高水準言語を介してターゲットに依存しないプログラミングを導入することで、パケット処理論理を下位のハードウェアから分離する。
• ASIC、ソフトウェアスイッチ、NPUを含む多様なスイッチターゲットにP4プログラムをマップするコンパイラベースのコンパイルスタックを提供する。
• OpenFlow 2.0の草案としての役割を果たし、将来的にはコントローラーが転送動作を定義するようになり、固定されたスイッチ設計によって制限されなくなることを可能にする。

提案手法

• パケットヘッダ、パーサ、マッチアドゥーステーブル、制御フローをプロトコルに依存しない方法で記述できる高水準のドメイン固有言語（P4）を設計する。
• 2段階のコンパイルプロセスを定義する：まずP4制御プログラムをテーブル依存性グラフに変換し、次にこのグラフをターゲット固有のスイッチリソースにマッピングする。
• パケットパースにステートマシン表現を用い、状態テーブルがフィールド値（例：VLAN ID、EtherType）に基づいて遷移を指定する。
• スイッチの能力に応じて、逐次的、並列的、またはパイプライン化されたテーブル実行モデルをサポートする。
• TCAMによる三値マッチング、RAMによる正確なマッチング、および後処理のためのメタデータ伝搬といった、ターゲット固有の最適化を可能にする。
• 必要に応じて複数のP4テーブルを1つの物理テーブルに統合するルールの合成を許可し、特にリソース制限のあるスイッチにおいて有効である。

実験結果

リサーチクエスチョン

• RQ1 ハードウェアの再設計やプロトコル固有の拡張子を必要とせずに、ネットワークプログラミング言語がどのようにパケット処理のランタイム再構成を実現できるか。
• RQ2 1つの高水準言語が、下位のスイッチアーキテクチャに依存せずにパケット処理論理を表現できるようにするための設計原則は何か。
• RQ3 コンパイラが高水準P4プログラムを、ソフトウェアスイッチ、ASIC、NPUを含む多様なターゲットスイッチに効果的にマッピングする方法は何か。この際、正しさとパフォーマンスを保持する。
• RQ4 パケット処理におけるプロトコルの独立性を実現するメカニズムは何か。これにより、制御プレーンやスイッチファームウェアを変更せずに、新しいまたはカスタムヘッダフォーマットをサポートできる。
• RQ5 言語とコンパイル技術を用いて、コントローラ論理とスイッチ実装との間の責任の分離をどのように達成できるか。

主な発見

• P4は現場での完全な再構成可能性を実現し、ネットワーク管理者がハードウェア変更なしに展開後もパケットパースおよび処理論理を更新可能にする。
• 言語はターゲット固有の詳細を抽象化することで、パケット処理論理をハードウェアから分離し、多様なスイッチプラットフォーム間での移植性を実現した。
• コンパイラは1つのP4プログラムを、ソフトウェアスイッチ、TCAM/RAMベースのハードウェアスイッチ、再構成可能パイプラインを含む多様なターゲットアーキテクチャにマッピング可能である。
• 2段階のコンパイルプロセス（テーブル依存性グラフの生成、次にターゲット固有のマッピング）により、パフォーマンスおよびリソース使用の最適化が可能である。
• ルールの合成を通じて複数のP4テーブルを少ない物理テーブルにマッピングする仕組みを提供し、特にリソースが制限されたスイッチにおいて有益である。
• 現代のASICを用いて、テラビットスルーブラスト速度でプロトコルに依存しないパケット処理が実現可能であることが実証され、このアプローチの実用性が裏付けられた。