P4和POF的对比

一、简介

软件定义网络（SDN）技术的发展已经历了多年，新技术层出不穷。OpenFlow作为其中的一个代表性协议，已经进化了多个版本，并被工业界和学术界广泛接受和使用，但是受OpenFlow协议规范的约束，用户对网络设备数据平面的操作仍然受到OpenFlow协议已有字段的限制。虽然OpenFlow近年来已从12个字段逐渐扩展到40多个字段，但是对于设备商或者是用户来说仍然有一些问题不能解决。具体来说，用户无法随心所欲的定制适用于特殊场合的私有协议；设备厂商则需要被迫更新硬件设备以不断适应OpenFlow新版本的迭代。为此，Nick McKeown，Jennifer Rexford等人提出了P4，全称为Programming Protocol-Independent Packet Processors。P4是一种对底层设备数据处理行为进行编程的高级语言，用户可以直接使用P4语言编写网络应用，之后经编译对底层设备进行配置进而使其完成用户的功能需求。与此相类似的还有华为公司推出的POF，全称为Protocol Oblivious Forwarding。POF最终实现的功能与P4类似，也是提高底层设备的可编程性。作者认为，POF更偏向于OpenFlow的进阶版本，或者说是在OpenFlow的基础上进行的升级扩展，但是比OpenFlow具备更强的协议灵活定制能力。P4和POF都是针对OpenFlow目前存在的问题而推出的新技术，P4和POF都给予用户对数据操作更大的权限，都可以实现任意已存在的或将来出现的协议，两者都能达到所宣称的协议无关，对底层设备的高可编程性。简言之，两者其实都朝着SDN的最终目标迈进了一步。为了更好地学习与研究，我们从总体架构、协议描述、单表定义、多表跳转、与控制器通信这五个方面对P4和POF进行了归纳和对比，使读者更好的了解两种技术的异同。由于技术较为新颖，作者接触两者时间也还不久，才疏学浅，故如有纰漏，还请斧正。

二、总体架构

2.1 P4

P4是一种高级编程语言，它的三个目标是：（1）可重配置，程序员可以修改已经配置过的交换机的数据处理方式。（2）协议独立，交换机不需要绑定任何专用的网络协议。（3）目标独立，程序员描述数据处理行为时能够不受底层硬件的特性所约束。所以程序员只需要使用P4语言进行编程就可以对底层交换机进行配置。具体过程就是，程序员编写高级语言程序后，编译器将其翻译为表依赖图TDG（Table Dependency Graph）来帮助分析依赖关系，再将TDG映射到不同的转发设备上。这里的设备可以是相对慢一点的软件交换机，也可以是更快的基于ASIC的交换机。

P4与众不同的地方在于有一套自己的抽象转发模型，如图1。

图1 P4抽象转发模型

在此基础上，P4 的编程模型可分为两个阶段：第一个是配置阶段，通过有向图的方式定义具体转发逻辑的协议解析过程。这个解析图用来配置转发芯片前端报文解析器。这个阶段还定义了主体控制程序，主要包括转发流程所涉及的各个流表、流表之间的处理依赖关系以及各个流表匹配后可能执行的动作集合。第二个阶段是运行时的流表控制，主要任务是软件定义网络应用驱动的流表表项的下发、修改、删除以及表项匹配动作的选择。

配置完成之后，设备接收到数据时，parser会识别出报文内的头字段并进行提取，然后match+action表对其进行匹配并执行匹配到的第一条表项的动作。match+action表又分为入表和出表，两者稍有差异，入表会决定报文进入哪个队列以及最后的出端口，而出表更注重于对报文头字段的调整。此外报文在不同阶段间还可以携带被同样视为头字段的metadata。metadata可以携带一些报文本身不含有的中间信息，以便操作处理，比如入端口，传输目的地，队列，时间戳等。

2.2 POF

相比于P4的复杂结构，POF的结构相对简单。首先需要管理人员使用UI配置协议和metadata（可用来存放不同协议的字段）。然后控制器以POF特有的形式（type，length，offset）将协议及metadata存储在协议库内。最后POF直接针对硬件进行配置，无显式编译过程。底层设备内的流表由控制器配置，或由应用通过OpenFlow通道下载到指定设备或通过控制器上的GUI手动配置。配置流表项时，控制器上的应用可能会参考协议库来建立流表项的匹配字段和指令。

图2 POF架构

POF处理报文的过程有些类似于OpenFlow。POF逐层地对报文进行解析，每层可有多张流表，但每张流表不能涵盖多个协议。所以当需要用来自多层协议的多个字段时就可以引入metadata来进行处理。

三、协议描述

P4有着名为header的数据结构，每个header内含一个有序列表fields，表里储存的是协议各个字段的名字和长度，还可以用字段释文来对值域和变长字段的最大长度进行限制。这里以标准的以太网和VLAN来举例：

可以看出，P4对协议的描述十分类似于C语言的结构体，不同的header就是不同的结构体，fields里包含的各个字段及就是结构体内的各个变量，各个字段在物理存储器上占据的偏移地址是通过对结构体进行编译为机器指令和地址的过程来确定的。

POF的方式则更加偏底层（也更接近本质），它将所有协议字段（包括metadata在内）都用{type，offset，length}的形式表示。type用来表示字段类型，0表示是报文数据，1表示是metadata字段，offset表示字段的起始位置距离当前协议头的距离，length即表示字段长度。以MAC协议举例：

图3 MAC协议

三个字段，dst,src,type，表示形式如下：

dst: {0, 0, 48}; #dst字段是报文数据，起始位0bit，字段长度48bit

src: {0, 48, 48}; #src字段是报文数据，起始位48bit，字段长度48bit

type: {0, 96, 16}; #type字段是报文数据，起始位96bit，字段长度16bit

显然，POF的表示方式更加类似于汇编语言，在地址偏移的设计上显得尤为突出。

在协议描述方面两者本质上没有区别，都用自己的方式对协议字段进行了描述，而且都可以通过类型、字段大小和字段偏移描述任意目前已有的或是将来出现的协议规范。

四、单表定义

P4定义的表数据结构table含有三个属性，reads属性表示哪个字段进行匹配，actions属性列出流表对报文可应用的动作，max_size属性表示表应该支持多少项。以P4自己举的mTag为例：

在POF中控制器会将所有协议存储在协议数据库内，操作人员可以通过控制器的用户界面来配置协议。应用按照服务需求并且参考协议数据库来建立流表，再通过OpenFlow通道将所有流表的流表项下载到指定的设备。与OpenFlow比，POF在定义流表方面并无太多变化。

五、多表跳转

P4有一个特有的控制流用来管控表之间的跳转，其本质就是一个由函数，条件句，表参考组成的程序。

以mTag为例：

图4 mTag流程图

经过parser分析后，第一张表源检查核实报文和其入口的一致性，同时从报文中挑出mTag，记录报文在metadata中是否有mTag，以免之后重复。接着处理图中间的本地交换表，如果miss就意味着报文不是发给本地主机的，就转到下面的mTag表。最终数据都会由最右边的出口检查表处理，它会在遇到未知报文目的地时向SDN控制堆栈发送通知。

其程序如下：

程序中通过条件句来进行判断下一步要转向哪个表，当对表进行匹配时，不同的表就相当于调用不同的函数。

POF类似于OpenFlow，在POF的指令中有一个指令是Goto-Table，该指令命令microcode和表进行匹配。其结构如下：

Type表示指令类型（用于区分不同指令这里就是指Goto-Table），next_table_id表示要搜索的表，match_field_num表示要匹配的字段个数，fields_array[]存储要匹配的字段。

以POF举的IPvX为例：

图5 Goto-Table 指令举例

在图左上角的流表0中MAC头字段的目的地址和类型被用来作为匹配字段。表0中有一个流表项指令为Goto-Table，指示microcode转到流表1继续处理，在表1中IPvX的源地址作为匹配字段。当一个以太网类型是IPvX的报文在流表1中匹配时，流表项中的Goto-Table指令将指示microcode让报文处理指针先向前移动14字节（MAC头字段长度），然后取出距离指针64bit偏移的源地址字段。最后microcode将会使用取出的源地址字段作为匹配值到表1中进行匹配，并按照匹配到的流表项做下一步处理。

可以看出，POF的Goto-Table指令与汇编语言的地址跳转十分相似，都是指向指令的要执行的地址。这是因为POF设计的时候就是定义的平台独立的底层指令集，复杂的操作都可以通过组合低级指令来实现。这就使得其对设备的操作空间更大，可实现的功能更多。

六、与控制器通信

由于P4的定位是高级编程语言，所以P4可以定义任意自己想要的配置。它可以让设备与SDN控制器通过OpenFlow通信，也可以通过本地的交换机操作系统控制，一切皆因P4程序设计而定。在P4语言中，OpenFlow只是一个程序，两者可以协同工作。事实上也已经有了名为openflow.p4程序，就是用P4语言编写的实现OpenFlow功能的程序。

POF则需要分两种情况，一种是与POF控制器通信，另一种是与OpenFlow控制器，假定两者都使用的是POF设备。

POF设备与POF控制器：这种情况比较简单，无论POF设备是软件还是硬件，都使用OpenFlow协议与POF控制器进行通信。控制器负责管理设备的资源如流表，组表，计数器等。POF设备会在握手的时候向控制器报告各种资源的容量。硬件实现是以华为的核心路由器为基础，在其控制层添加POF硬件抽象层来配置POF流表，并在转发引擎中添加microcode剖析和执行POF指令实现的，其软件架构如下图。

图6 POF设备的软件架构

可以看到上方的MPU内有OpenFlow连接管理，下方的LPU内有OpenFlow Parse和OpenFlow Encap分别处理控制器到交换机和交换机到控制器的数据，再下面就是额外添加的POF硬件抽象层，最下面是转发引擎驱动，转发引擎。

POF的软件交换机是在LINUX上用一个类似的POF驱动和软件转发代码实现的，其可实现的转发功能与POF硬件设备几乎是一样的。POF使用和OpenFlow1.3相同的控制命令，大部分控制命令的数据结构也保持不变。POF只修改了OpenFlow1.3的转发指令/动作的数据结构。

POF设备与OpenFlow控制器：两者之间还是使用OpenFlow通道，但是在POF设备内有一个翻译模块，可以将收到的OpenFlow指令参考之前建好的协议数据库转换成POF指令，进而执行操作，其架构如下图。

图7 第一种：将OF指令翻译为POF指令

可以看到，底层还是POF驱动和POF转发引擎，只需要在翻译模块中将OpenFlow指令翻译为POF指令即可。OpenFlow控制器如果有用来配置POF设备协议数据库的控制命令就可以支持新的协议。此外在这种模型下，一些OpenFlow控制器上现有的应用可能不符合之前的限定所以有可能不能正常工作需要重新编写。

另一种模型可以有效避免上述问题，此模型将POF作为OpenFlow指令的扩展部分但其指令类型与OpenFlow指令类型不同，其架构如下图。

图8 第二种：扩展OF指令使其包含POF指令

设备内有两个驱动可以分别解析不同类型的指令，底层的转发引擎需要能够执行OpenFlow和POF两种指令，这就需要在NP的指令缓存中存储更多地microcode。这种模型更为理想，所以POF希望可以将POF计划包含进OpenFlow，最终不再需要支持当前的OpenFlow而只支持POF即可。

七、总结

P4和POF的目标都是使底层设备可编程性更强，但是POF的语法更贴近于原来的OpenFlow协议规范，并使用类似汇编语言的语法对网络设备进行编程，对不同设备的编程目前采用基于解释翻译而并非编译的方式实现。而P4则提出了高级语言和相应的编译系统，最终通过编译器后端的支持可以对各种设备进行编程。无论是何种架构都可以通过其编程编译实现，进而真正实现SDN的愿景。以上便是作者阅读学习P4和POF协议规范的过程中所做的一点微小的工作，如果有什么问题或不足，十分欢迎提出并讨论！