• Name of article：Programming Protocol-Independent Packet Processors
• Origin of the article：Bosshart P , Daly D , Izzard M , et al. Programming Protocol-Independent Packet Processors[J]. Acm Sigcomm Computer Communication Review, 2013, 44(3):87-95.

ABSTRACT：

programming protocol-independent packet processors p4是一种高级语言，用于编程独立于协议的包处理器

conjunction with  SDN control protocols p4与诸如OpenFlow的SDN控制协议一起工作

explicitly specifies protocol headers 目前，OpenFlow还是显式地指定其操作的协议头

increasing the complexity 这组字段在几年内从12个字段增加到41个字段，实际上增加了规范的复杂性

not providing the flexibility 但仍然不能提供添加新头的灵活性

as a strawman proposal 在本文中，我们提出p4作为一个救命稻草一样的建议，来说明OpenFlow在未来应该如何发展：

• Reconfigurability in the field 现场可重构性：一旦交换机被部署，程序员应该能够改变其处理数据包的方式
• Protocol independence 协议独立性：交换机不应绑定到任何特定的网络协议
• Target independence 目标独立性：程序员应该能够独立于底层硬件的细节描述包处理功能。

作为一个例子，我们描述了如何使用P4配置一个交换机来添加一个新的层次标签。

1. INTRODUCTION：

Over the past five  years, the specification has grown increasingly more complicated  (see Table

软件定义的网络（SDN）使运营商可以编程控制其网络

common, open, vendor-agnostic interface SDN有一个通用的、开放的、与供应商无关的接口（如OpenFlow）使控制平面能够控制来自不同硬件和软件供应商的转发设备

the abstraction  of a single table of rules OpenFlow接口一开始很简单，抽象出一个规则表，可以匹配十几个头字段（例如，mac地址、ip地址、协议、tcp/udp端口号等）上的数据包

parsing packets and  matching header fields 我们认为，未来的交换机应该支持灵活的机制来解析数据包和匹配头字段，从而允许控制器应用程序通过一个公共的、开放的接口（即一个新的“OpenFlow 2.0”api）

编程可以提供未来交换机所应该支持的灵活性，编程新一代的交换机芯片远非易事，每个芯片都有自己的底层接口，类似于微码编程。

Programming Protocolindependent  Packet Processors (P4) 本文简要介绍了一种用于编程协议独立包处理器（P4）的高级语言的设计

serve as a general interface P4提高了网络编程的抽象层次，可以作为控制器和交换机之间的代理接口

在设计P4时，我们有三个主要目标：

• 可重构性
• 协议独立性
• 目标独立性

论文概要如下。

我们首先介绍一个抽象的交换机转发模型。

接下来，我们将说明需要一种新的语言来描述依赖于协议独立的包处理。

然后，我们给出一个简单的激励示例，其中网络运营商希望支持一个新的包头字段并在多个阶段处理包。

最后，我们讨论编译器如何将p4程序映射到目标开关

2. ABSTRACT FORWARDING MODEL：

In our abstract model (Fig. 2), switches forward packets  via a programmable parser followed by multiple stages of  match+action, arranged in series, parallel, or a combination  of both

forward packets  via a programmable parser 抽象模型中，通过一个可编程的解析器来交换转发数据包，然后是多个match+action阶段，这些阶段以串行、并行或两者的组合方式排列。

从OpenFlow出发，我们的模型进行了三个推广。

assumes a fixed parser 首先，OpenFlow假设一个固定的解析器，而我们的模型支持一个可编程的解析器来定义新的头。

其次，OpenFlow假设match+action阶段是串联的，而在我们的模型中，它们可以是并联的或串联的。

protocol-independent primitives 第三，我们的模型假设动作是由交换机支持的独立于协议的原语组成的。

我们的抽象模型概括了不同转发设备（如以太网交换机、负载均衡器、路由器）和不同技术（如固定功能交换机ASIC、NPU、可重构交换机、软件交换机、FPGAS）如何处理数据包，这使得我们能够设计一种公共语言（P4）来表示如何根据我们的公共抽象模型处理数据包。

target-independent programs 因此，程序员可以创建独立于目标的程序，编译器可以映射到各种不同的转发设备，从相对较慢的软件交换机到最快的基于ASIC的交换机

Configure and Populate 转发模型由两种类型的操作控制：配置和填充

配置操作编程解析器，设置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的草案，为辩论做出贡献。在这个方案中，交换机的几个方面仍然没有定义（例如，拥塞控制原语、排队规则、流量监控）。然而，我们相信，拥有一种为特定目标生成低级配置的配置语言和编译器的方法将导致未来的交换机提供更大的灵活性，并释放软件定义网络的潜力。