为OVS插上P4可编程的翅膀

作者简介：张渐修，任职于上海同悦信息科技有限公司从事P4交换机市场工作，Wechat: Tooyumzjx。

从OpenFlow到P4，软件定义网络(SDN)为提高网络的灵活性和可定制化而不断努力奋斗。目前SDN正在集结兵力的战场，是创建高性能、低开销的完全可编程的网络解决方案。

SDN街头霸王- Open vSwitch

从OVS诞生至今，无论是纯SDN解决方案、硬件加速还是不同类型的叠加网络，OVS都在实战中证明了其成熟度和产品质量，从它支持的平台范围就可以证明这项技术的成熟度。

"OVS既可以作为Hypervisor内运行的软交换，也可以作为交换芯片的控制栈。它已经被移植到多个虚拟化平台和交换芯片组。它是XenServer 6.0、Xen云平台中的默认交换机，也支持Xen、KVM、Proxmox VE和VirtualBox。它还被集成到许多虚拟管理系统中，包括OpenStack、openQRM、OpenNebula和oVirt。内核数据路径随 Linux 一起发布，Ubuntu、Debian、Fedora 和 openSUSE 也有相应的软件包。FreeBSD 和 NetBSD 也支持 Open vSwitch。Open vSwitch的开发版本已被移植到DPDK中。"

另外值得一提的是当年惊鸿一现的OpenSwitch，就是利用OVSDB和vswitchd OVS守护进程作为核心组件。

因此，OVS可以完美地适用于任何SDN场景（例如OpenStack Neutron-网络连接即服务），由此实现网络控制平面与转发平面的物理分离具备操作和功能上的优势。

OpenFlow：一门古老的武术

OVS区别于其他软件交换机的关键要素之一就是对OpenFlow协议的原生支持，而且具有多种扩展功能。因此，OVS既可以作为L2/L3交换机、纯OpenFlow交换机，也可以作为混合OpenFlow交换机运行。

OpenFlow为SDN的发展打下坚实基础，一度成为SDN的代名词，因此时至今日依然有很多项目采用OpenFlow做为协议接口。

让我们回到令人心生畏惧的“恐龙时代“，回忆一下软件历史上强大而危险的“汇编”。通过左侧高级语言和右侧汇编语言的对比可以发现，这两种编程语言不仅是格式上的区别，而是软件进化的两个阶段。今天的高级编程语言编译器可以生成与经验丰富的工程师编写的汇编代码一样优化和高效的二进制代码。

同样，从OpenFlow到P4的演进也是SDN的两个阶段。P4和P4Runtime是SDN技术发展下一时代的最佳候选者，它们为应对当前和未来的网络挑战提供了新的灵活性和可编程性。因此，现在有一些尝试用P4来支持OVS。 这样做的目的很简单，就是为了减少新的OVS功能和协议的开发时间。为了支持一个新的功能，工程师通常做法是编写一个描述这个功能的P4程序，用某一个特定的P4编译器将程序翻译成C代码，然后用新生成的C扩展编译OVS。

但是如果审视一下这个流程，我们可能要认真考虑下面几个简单的问题。

1. 需要支持一个新的协议的开发周期是多久？
2. 是否准备好面对代码变更带来的风险和挑战？
3. 客户的环境（云平台、管理程序、交换机芯片的SDK）是否依赖于OVS的特定版本？
4. 客户是否可以忍受每次为OVS修改P4代码时都要重新安装OVS？

最常见需要对OVS修改的情况是在OVS之上移植一个新的SDN应用（负载均衡器、NAT等）即定义新的OpenFlow规则，或者通过OVS/OpenFlow实现一个新的Overlay网络。

有没有更优的方案呢？先来仔细看看OVS的功能。OVS手册的ovs-fields和ovs-actions部分详细描述了OVS支持的所有OpenFlow匹配和动作。除了可以用于操作标准的以太网/IP/MPLS数据包字段（OpenFlow协议的早期版本）的匹配和操作之外，OVS的最新版本支持许多特性和扩展，这些特性和扩展极大地扩展了OVS管道的功能：关联匹配字段、4/8/16字节寄存器、连接跟踪字段、封装/解封装操作、重新提交操作、多路径操作、堆栈Push/Pop操作等等。

寄存器，堆栈，OpenFlow是不是像汇编语言一样强大呢？我们能不能用另一种更自然的方式对OpenFlow流水线进行编程呢？答案是肯定的，不需要像上面的方案一样每次都编译新的OVS，我们可以依然沿用成熟的OpenFlow接口，只是利用高级语言对图1中的OpenFlow Pipeline流水线做编程，下面对比是个很好的示例。

P4技术，OVS的军刀

简单地设想一下，工程师只用高级的P4语言编写应用程序，而P4编译器做剩下的事情：生成相应的默认OpenFlow规则，并为P4Runtime接口定义模板。对OVS版本没有依赖性，不需要重新编译代码或重新安装应用程序。数据平面仍然是通过OpenFlow协议进行配置，但是，这次的规则是由守护进程中介模式注入的，它根据P4编译器生成的模板将P4Runtime消息翻译成OpenFlow规则。如下图所示，P4的编程结构V1Model很好的解决了上述问题。

目前V1Model已经非常成熟，Parser对数据包根据预先定义好的格式进行解析，并提取头部的各个字段，比如如果三层包头的协议字段是0x0800则是ip报文，如果是0x0806则是arp报文，然后会进行不同的处理；Ingress/Engress流水线分别是数据处理逻辑的入口和出口；TM则对队列进行排序做流量管理；最后Deparser对数据包进行重组。

当然这种方法需要面对OpenFlow本身的限制，就像之前提到的问题一样，如果需要经常添加新协议的支持，那么PISCES或其它类似的项目可能是更好的选择。但是，考虑到OpenFlow既可以用规范定义的数据包字段和动作来操作，也可以实现厂商对新协议或动作的扩展。那么既想基于OVS的成熟版本用于各种SDN应用的原型设计，又不想深入学习OpenFlow，那么P4到OpenFlow的映射方法是个很完美的选择。只需要为OVS插上P4可编程的翅膀，而不需要更换整个OVS的心脏。