- 記事の名称：プロトコル独立パケットプロセッサのプログラミング
- Bosshart P、デイリーD、イザードMら：記事の原点。プログラミングプロトコルに依存しないパケットプロセッサ[J]。ACM SIGCOMMコンピュータコミュニケーションレビュー、2013、44（3）：87-95。
抽象：
プログラミングプロトコルに依存しないパケットプロセッサP4プロトコル独立パケットプロセッサをプログラムするための高レベルの言語であります
SDNとOpenFlowの制御プロトコルのSDN制御プロトコルのP4などと一緒に一緒に働きます
現在明示的プロトコルヘッダ、オープンフローを指定するか、明示的にプロトコルヘッダの動作を指定します
実際には、フィールド12から41歳までのフィールドのこのグループ内の複雑さのフィールドを増やすこと、それは仕様の複雑さを増します
柔軟性を提供していないが、それでも新しいヘッドを追加するための柔軟性を提供していません。
本論文でstrawmanの提案として、私たちは、オープンフローが将来開発されるべきであるか説明するために、勧告としてわらP4を提案します：
- 再構成可能なフィールドのフィールドでの再構成可能性：スイッチが配備されている場合は、プログラマはそれがデータパケットを処理する方法を変更することができるはずです
- プロトコル独立プロトコルの独立性：スイッチは、特定のネットワークプロトコルに縛られるべきではありません
- 独立一定の独立性をターゲット：独立したプログラマは、基盤となるハードウェアパケット処理の詳細を説明することができるはずです。
一例として、我々は新たなレベルのラベルを追加するには、スイッチP4を設定する方法について説明します。
1.はじめに：
過去5年間で、仕様はますます複雑に成長している（表を参照してください 
ソフトウェア定義ネットワーク（SDN）事業者はネットワークプログラミングを制御することができます
一般的な、オープン、ベンダに依存しないインタフェースSDN異なるハードウェアおよびソフトウェアベンダーからの転送を制御可能な制御装置（例えば、オープンフローのような）一般的な、オープン、ベンダに依存しないインタフェースを有する平面
抽象的ルールテーブルへの単純なインタフェースを開始ルールオープンフローの単一テーブルの抽象化は、データパケットにダースヘッダフィールド（例えば、MACアドレス、IPアドレス、プロトコル、TCP / UDPポート番号など）を一致させることができます
パケットを解析し、我々は、スイッチの将来は、共通の、オープンインタフェース（すなわち、新しい「オープンフロー2.0」APIを介してコントローラアプリケーションを可能にする、データ・パケットと一致するヘッダフィールドを解析するための柔軟なメカニズムをサポートする必要があると思われるヘッダフィールドと一致）
プログラミングは、プログラミングの新しい世代によってサポートされる必要があり、将来のスイッチの柔軟性がはるかに簡単にスイッチ・チップから、各チップは、マイクロコード・プログラミングと同様、自身の基礎となるインタフェースを有している提供することができます。
プログラミングProtocolindependentパケットプロセッサ（P4）本稿では、簡単に高レベル言語のプロセッサをプログラムするためのプロトコルに依存しないパケット（P4）について説明
一般的なインターフェースP4は、ネットワークプログラミングの抽象化のレベルを増加させるように働き、エージェントは、コントローラとスイッチとの間のインターフェースとして使用することができます
P4を設計するとき、我々は、3つの主要な目標を持っています：
- 再構成可能性
- プロトコルの独立性
- 自立の目標
論文は以下のとおり。
我々は、第1スイッチフォワードの抽象モデルをご紹介します。
次に、我々はあなたが独立したプロトコルパケットの処理に依存を記述するために新しい言語を必要と表示されます。
その後、我々は、ネットワークオペレータは、新たなパケットヘッダフィールドをサポートし、複数の段階で処理したいインセンティブ、の簡単な例を与えます。
最後に、我々は、ターゲットスイッチにコンパイラP4プログラムをマッピングする方法を話し合います
2. ABSTRACT転送MODEL：
我々の抽象モデルでは（図2）は、直列、並列に配置されたマッチ+アクションの多段階、続いてプログラマブルパーサ、または両方の組み合わせを介してフォワードパケットスイッチ
プログラマブルスイッチングによって前方経由パケットプログラマブルパーサ抽象モデル、及びパーサーにデータパケットを転送し、一致+アクション複数のは、シリアル、パラレル、または両方の配置の組み合わせステージ。
オープンフローからは、我々のモデルは3つのプロモーションです。
第1の固定パーサを前提とし、オープンフローは、固定されたパーサを想定して、我々のモデルは、新しいヘッドを定義するためのプログラム可能なパーサをサポートしています。
次に、直列に接続されたオープンフロー一致+アクション段階を仮定すると、我々のモデルでは、それらは並列または直列に接続されていてもよいです。
プロトコルに依存しないプリミティブ第三に、我々のモデルは、スイッチでサポートされているアクションがのプロトコルに依存しないプリミティブであることを前提としています。
私たちは、となりますどのようにデータパケットを処理するために、（例えばスイッチASIC、NPU、リコンフィギュラブルスイッチ、ソフトウェアスイッチ、FPGAは固定された関数として）異なる技術（例えばイーサネット・スイッチ、ロードバランサ、ルータなど）抽象モデル異なる転送デバイスをまとめます私たちは公共の抽象モデルがパケットを処理する方法を示すために、共通言語（P4）を設計することができます。
ターゲット非依存のプログラム従って、プログラマは、ターゲットのプログラム独立を作成することができ、コンパイラは比較的遅いソフトウェアスイッチから最速のASICベースのスイッチに、異なる転送装置の種々にマッピングすることができます
設定し、前方移入モデルは、動作制御の2種類で構成されています設定および塗りつぶし
配置操作编程解析器，设置match+action阶段的顺序，并指定每个阶段处理的头字段。配置确定支持哪些协议以及交换机如何处理数据包
填充操作向配置期间指定的match+action表添加（和删除）项，填充确定在任何给定时间应用于数据包的策略
3. A PROGRAMMING LANGUAGE：
the abstract forwarding model 我们使用抽象转发模型来定义一种语言来表示如何配置交换机以及如何处理数据包
然而，我们认识到许多语言是支持的，而且它们可能具有我们在这里描述的共同特征
using the declared header types and a primitive set of actions 这促使P4使用命令式控制流程序，来描述使用声明的头类型和基本操作集的头字段处理
4. P4 LANGUAGE BY EXAMPLE：
考虑一个示例L2网络部署，在边缘使用由两层核心连接的拓扑框架（TOR）交换机
我们通过深入研究一个简单的例子来探索P4。许多网络部署区分边缘和核心,终端主机直接连接到边缘设备，而边缘设备又通过高带宽核心互连。整个协议被设计为支持这种架构，主要目的是简化核心的转发。
4.1 P4 Concepts
P4程序包含以下关键组件的定义：
- Headers 头：头定义描述一系列字段的顺序和结构。它包括字段宽度的规范和字段值的约束。
- Parsers 解析器：解析器定义指定如何识别数据包中的头和有效的头序列。
- Tables 表：match+action表是执行数据包处理的机制。p4程序定义一个表可能匹配的字段和它可能执行的操作。
- Actions p4支持从简单的协议无关原语构造复杂的action。这些复杂的操作在match+action表中可用。
- Control Programs 控制程序：控制程序确定应用于数据包的匹配+操作表的顺序。
4.2 Header Formats
A design begins with the specification of header formats
For example, standard Ethernet and VLAN headers are specified as follows:
The mTag header can be added without altering existing declarations mTag
（可以在不更改现有声明的情况下添加mTag头）
字段名表示核心有两层聚合。
4.3 The Packet Parser
p4假设底层交换机可以实现一个状态机，该状态机从头到尾遍历数据包头，并在运行时提取字段值，提取的字段值将发送到match+action表进行处理。
4.4 Table Specification
为了完整性和以后的讨论，我们给出了控制程序引用的其他表格的简要定义：
接下来，程序员将描述如何在match+action阶段匹配定义的头字段以及匹配发生时应执行的操作。
matches on the L2 destination and VLAN ID 在我们的简单mTag示例中，边缘交换机匹配二级目标和VLAN ID，并选择要添加到头的mTag。
defines a table 程序员定义一个表来匹配这些字段
apply an action 并应用一个操作来添加mTag头
reads属性声明要匹配的字段
actions属性列出表可以应用于数据包的可能操作
max size属性指定表应支持的条目数
表规范允许编译器决定它需要多少内存，以及实现表的内存类型。
4.5 Action Specifications
a collection of primitive actions P4定义了一个原始动作的集合，从中可以生成更复杂的动作
每个P4程序声明一组由动作原语组成的动作函数，这些动作函数简化了表的说明和填充
parallel execution P4假设在动作函数中并行执行原语。
P4的基本操作包括：
- set field：将头中的特定字段设置为值
- copy field：将一个字段复制到另一个字段
- add header：将一个特定的头实例（及其所有字段）设置为有效
- remove header：从数据包中删除头（及其所有字段）
- increment：增加或减少字段中的值
- checksum：在一些头字段集（例如，IPv4校验和）上计算校验和
4.6 The Control Program
一旦定义了表和操作，剩下的唯一任务就是指定从一个表到下一个表的控制流
Figure 4 shows a graphical representation of the desired control flow for the mTag implementation on edge switches
5. COMPILING A P4 PROGRAM：
map the target-independent description onto 为了让网络实现我们的P4程序，我们需要一个编译器将目标无关的描述，映射到目标交换机的特定硬件或软件平台上
5.1 Compiling Packet Parsers
对于具有可编程解析器的设备，编译器将解析器描述转换为解析状态机，而对于固定解析器，编译器仅验证解析器描述是否与目标解析器一致
5.2 Compiling Control Programs
does not explicitly call out dependencies 第4.6节中的命令式控制流表示法是一种指定交换机逻辑转发行为的便捷方法，但并未明确调用表之间的依赖关系或并发机会。
因此，我们使用编译器来分析控制程序，以确定依赖项，并寻找并行处理头字段的机会
我们简要地研究了如何在不同类型的交换机中实现mTag示例：
-
Software switches
-
Hardware switches with RAM and TCAM
-
Switches supporting parallel tables
-
Switches that apply actions at the end of the pipeline
-
Switches with a few tables
6. CONCLUSION：
SDN的承诺是单个控制平面可以直接控制整个交换网络。
OpenFlow通过提供一个独立于供应商的API来支持这个目标。然而，今天的OpenFlow的目标是固定功能的交换机，这些交换机识别一组预先确定的头字段，并使用一组预先定义的操作处理数据包。控制平面无法表示如何处理数据包以最好地满足控制应用程序的需要。
我们建议朝着更灵活的交换机迈出一步，这些交换机的功能是可以指定的，可以在现场更改。程序员决定转发平面如何处理数据包，而不必担心实现细节。编译器将命令式程序转换为表依赖关系图，该图可以映射到许多特定的目标交换机，包括优化的硬件实现。
我们强调，这仅仅是第一步，它被设计为OpenFlow2.0的草案，为辩论做出贡献。在这个方案中，交换机的几个方面仍然没有定义（例如，拥塞控制原语、排队规则、流量监控）。然而，我们相信，拥有一种为特定目标生成低级配置的配置语言和编译器的方法将导致未来的交换机提供更大的灵活性，并释放软件定义网络的潜力。