韩东海：非常高兴由我和我的资深工程师王宇生给大家做一个关于P4和SDN的交流。VMware对P4感兴趣是一个很自然的过程。我们一直做SDN，包括企业级的NX平台、开源的OVM平台，已经做了几个版本，遇到了一些问题，也解决了很多问题，总结了很多经验教训。我们希望可以使用各种各样的DSL语言上SDN平台变得可编程。可编程不是说SDN平台对外的可编程，这是解决了的问题。而是说SDN平台自身功能的实现的可编程。

举一个简单的例子，在我们自己的控制器上，信息的收集、下发可以用程序来实现，我们现在做实验，灵活性非常高。有新数据要处理的时候，加新的逻辑就变得非常容易。在所有的transport上连接上虚拟机，为上层的应用提供虚拟的网络。这些虚拟的交换机就是新的Topflog交换机，或者是物理的交换机。很不幸，它跟物理的交换机共享一个不好的特性，就是不是可编程的。当你的程序写好了，当你开始编译部署这一刻起，虚拟交换机的功能就已经固定了。当你要加新的功能，或者要加新的协议，要重新再加一些代码，再重新编译，再下发，如果涉及到内核的模块怎么办？有可能需要重启。这些都是不可编程带来的问题。我们看到了这个问题，想解决这个问题。P4的出现就是很自然的过程。把P4和EBBF结合起来，这肯定是一个方向。不能说这是将来终极的解决方案，但它最起码是有趣有益的探讨。

我们今天是跟大家探讨DSL领域相关语言和SDN的结合可能带来的可能性。具体的内容由王宇生给大家做介绍。我们这个平台是纯软件的方案，更能说明P4的魅力，可以把P4这样一个为芯片级的应用而设计的东西拿出来放到软件平台上。

OVN是基于OVS的SDN平台。OVS在OVN上应用各种各样的领域相关的语言，包括P4，怎么样提高系统的灵活性、可编程性。

王宇生：今天谈到的主要话题有两个，一个是从OVS到OVN的发展过程中遇到了哪些问题,对于这样的问题是怎么解决的?另外一个方面就是使用领域专有的语言DSL如何解决开发过程中碰到的问题。两个方面都是围绕着可编程性来讲的。前面有些同事讲过了硬件中的使用，我们是从软件的角度来讲这个问题。

这是OVS项目开始的背景。它跟barefoot考虑的是网络路径上的作用，考虑的是硬件的可编程性。OVS考虑的是软件的可编程性。我们在网络终端做这个事情。

最开始的想法是让网络像计算机一样可以编程。我们发明了openflow，最开始的想法是在硬件、软件上都可以运行。为了使硬件的实现具有便利性，我们定义了非常简单的规则和匹配动作。经过多年的发展，我们把OVS做成了纯粹的软件交换机的解决方案，它不是一般硬件意义上的交换机，不只是支持二层的能力，还有二到层七层。它是可以编程的，你可以把各种想法加在上面。

为了使软件的实现更便利，我们给它加了很多扩展。它渐渐发展成为使用封装协议来实现软件物理网络和虚拟网络之间的分割。

做一个纯粹的软件交换机会有什么问题呢？最重要的问题是它必须非常快，至少要达到线速，否则对底层的物理网络是一种浪费。做到这一点有很多手段，比较重要的手段就是缓存。如果有一个事件可以展示出空间和时间的局部性，缓存就是非常好的手段。

对于OVS来讲，使用缓存以后，数据流会分成两部分，一个是快速通道，一个是慢速通道。很多硬件设备也是这么操作的。在慢速通道里，我们是使用openflow做配置，具有可编程性。在快速通道用的是全局的缓存，所有的flow共享一个缓存，这个缓存会匹配数据包里的所有内容。如果看到了匹配，就会按照匹配所指定的动作进行操作。

做完这件事情以后，我们看到了很重要的是在数据层面，时间复杂度是一个常量，这对于流表编程是很重要的，只要考虑功能就可以，不用考虑性能。不管流表长短，它的时间复杂度都是常量。

接下来，我们遇到性一个问题，就是短生存周期的flow。所谓短生存周期的含义就是不太能运用缓存。假如写一个即时的聊天工具，拿UTG发包。为了解决这个问题，我们使用了巨流表。在内核态不只有一个流表，我们有一组流表，每一个流表会匹配不同的数据包头。为了还能保持原有的常量时间的复杂度，在这样一组流表的基础上再做了一个大的流表，这样就有两层缓存。用这个方法解决了短生存周期流的问题。

还有别的问题，有状态的服务怎么解决？处理一个数据包的时候，它的动作不只是依赖于数据包当前的内容，还依赖于历史内容。假设有一个交换机，允许从1口到2口发起连接，所有反向的连接都禁止，只看一个数据包是不够的。对于这样有状态的服务，数据包必须走快速通道，我们需要在内核使用这样的架构，可以插拔的软件模块。这个软件模块用来复杂有状态的部分的处理，所有的状态信息都保存在可插拔的软件模块当中，我们需要提供新的动作和匹配的语言，以支持这样的能力。通过这个以后就可以支持有状态的服务。

除此之外，还有其他的优化，主要有硬件的卸载，24U、其他算法的优化。做了所有事情以后，软件的交换机达到了两个目的。第一个目的是可编程的交换机。第二个目的，它是非常快的交换机。不管用什么平台，在现有的硬件上，至少超过100万包/秒，延迟在毫秒级以下。如果硬件更好，这个数字会更好。

接下来看看我们缺了什么。OVS只是运行在单一的机器上的软件产品，只用OVS做不了什么事情。有流表也做不了什么事情，因为网络是有许多节点构成的。你需要一种办法，能给所有的网络节点做一个统一的编程，并且可以协同起来，达到数据包走向的任务，我们需要一个控制器。市面上有很多控制器，有开源的，也有闭源的。这个项目是两年以前开始的，它使用的代码库是OVS在一起。它有一个好处，如果下载了OVS，自然就有了OVN，不需要再装其他任何的第三方软件、数据库或者中间件就获得了这样的能力。
OVN是用OVSDB做存储，软件模型是存在OVSDB中的，它同时也是一个通道，你也不用考虑其他第三方的产品。我们已经把OVN和Openstack集成了，可以达到配置虚拟网络的目的。目前实现的功能级是比较完全的，包括二层和三层的能力，都是分布式的能力、分布式的交换机、分布式的路由器。除此之外，四层到七层会提供有状态的防火墙的能力。我们对产品进行了性能测试，在1000个主机的运行环境下，仍然可以很好地工作。

我们看到了一个很完整的场景，有一个完整的软件解决方案，可以配置你需要的虚拟网络。有什么问题呢？可编程性要从两个方面来看。前面讲的是对用户的可编程性，用户可以很方便地实现网络能力。对于OVS和OVN的开发人员来讲是非常不方便的。

如果从第一行的代码算起，到现在为止，应该有9年的时间。我们一共贡献了25万行的C语言的代码。我们有一个非常闪光的开发团队。这些事情做起来并不容易。如果你自己想做修改或者是增强是很困难的。我们怎么从开发人员的角度提高可编程性呢？我们考虑了不同的方法。

首先是P4。下面是P4的概念模型。如果我不说它是P4，我说这是OVS，它基本上也是不错的。我们前端有一个解释器，中间是匹配和动作，到后端是输出。我们做的尝试是希望把OVS的核心代码做重写，用P4来描述这几部分之后，生成一个C语言代码，相当于现有的内核里面的数据代码大概有14000行左右。我们测试了它的性能，它对性能的影响并不太大，我们获得了OVS本身的可编程性。

接下来是另一个尝试。刚刚用了P4，那个编译过程是从P4到C语言，C语言同样也有编译、安装、升级的问题。接下来，我们想尝试可编程性提升到更好的层次上，我们使用了eBPF，它是另一个领域的专有语言，可以描述数据包的处理，eBPF的很多内核已经支持了，它有GIT的支持，我们可以认为它很安全、很快，它是通用的编程语言。第二个尝试是P4作为输入，输出是eBPF，可以直接运行在它的内核里。

再回到OVN的层面。OVN是在控制器层面。使用这个领域的专有语言仍然有很多帮助。第一是Datalog，你可以认为它是人工智能的语言，是基于规则和推理的。从另一个角度来看，可以认为是数据库的查询语言，所有的系统状态是用数据表的形式写出来的，编程语言是查询语言。

Datalog是一个声明式的语言，它有非常好的特点，写完了就是对的。如果写完了一段程序，如果它基本能工作了，一般就不会再出现bug。这是它非常好的特点。它跟传统的编程语言有很大的不同。一般的编程语言是以时间为线索组织你的行为，声明式的编程语言是指明了你的目的，你的行为和时间线索上的动作跟它是完全无关的。
我们在VMware的产品中已经进行了尝试，在一个版本的控制器中使用了1200条规则完成了整个控制器的编程。

OVN是一个控制器，主要是把北向的网络模型转成南向的逻辑流表。考虑到很多时候是在在操作数据和流表的生成。考虑可以用流表编程语言来做这件事情。语言可以定义数据的访问，这个访问主要是针对OSDB。可以定义数据是如何匹配的，定义流表如何生成的。可以用这样的语言重写OVN的部分。OVN现在的状况是用C语言实现，之后可以考虑用定语专用语音来重写。

实际上我们做的事情从最初的目标到现在是一致的，希望网络具有更好的可编程性。这个可编程性分成两个层面，一个是对用户来讲，可以自由地配置网络，达到路由的目的。从软件开发人员来讲，也希望有更好的可编程性，希望在所有的层面上具有动态可编程的能力。
我的介绍就到这里，谢谢大家！