OpenFlow正处在十字路口?

在SDN的初期阶段，各种可能性大量存在。这样的想法让从业者非常兴奋，并且吸引了大批的开发人员。OpenFlow就是早期的一颗SDN明星，这 个出自斯坦福大学的验证概念指出了规划网络的一种全新的方法。很多人甚至将SDN与OpenFlow混为一谈，好像除此之外SDN就没有其他可能性存在 了。

情况当然并非如此，但在SDN初期的炒作阶段，这种想法也是可以理解的。OpenFlow进展神速，因为有开放网络基金会(ONF)在后面推动，很快便连续发布了已迭代多次的OpenFlow主规范版本。

然而最近一段时间，OpenFlow的进展似乎陷入了停滞。业界对它的热情也在逐渐减退。ONF发布OpenFlow主规范的步伐也已放缓。这些天来，就连厂商自己举办的SDN发布会，也不再强调OpenFlow有多么多么神奇了。

SDN已经用多个品类的产品创造出了属于自己的行业，其中一些产品根本没有用到OpenFlow。而在今年春季于美国纽约召开的开放网络用户组会议 上，OpenFlow也不再是一个主要的讨论话题。有些厂商对在自己的产品中增加对OpenFlow的支持兴趣不高，甚至表现出厌恶情绪——这其中就包括 大牌厂商思科和Juniper。不过另一些厂商，像惠普和博科，则依然将OpenFlow视为其生态系统的重要组成部分。

OpenFlow似乎已走到了一个十字路口。从用户的角度来看，这种情形似乎颇让人惊讶，也引发了一个疑问：长期来看，OpenFlow在SDN的发展中究竟还能不能发挥重要作用?

这个问题的答案在于要理解OpenFlow究竟是什么。简单来说，OpenFlow其实就是为网络设备编程转发表的一种工具而已。

可是……事实就是如此。OpenFlow就是一个工具。但也不要因此而贬低OpenFlow。OpenFlow的确是一个工具，但它是一个有用的强大的工具。OpenFlow可提供的功能有如下一些：

●一个标准化的界面，可将厂商特定的硬件抽象出来。而可与OpenFlow对话的控制器则可针对支持OpenFlow的设备进行编程。

●一种对网络进行集中编程的方法。

●一种可进行“例外编程”的简易方法，用于处理网络中不能遵循正常最佳路径的例外流量。

一直在使用OpenFlow的厂商自然会指出，OpenFlow并未完全标准化。从某种意义上说，一些厂商为其添加了很多附加功能，对其做了扩展。 事实的确如此，不过值得指出的是，这些厂商(包括Big Switch、NEC和VMware)正在与ONF合作，力图将这些扩展纳入到OpenFlow的标准中去。这样的进程颇类似于过去其他厂商处理扩展与标 准的情形。要说业界要完全抛弃OpenFlow似乎不太可能。一直在使用OpenFlow的厂商则试图与业界同行尽量保持一致。

有些厂商可能会认为OpenFlow贬低了硬件的作用，OpenFlow作为一个标准化的界面不可能完全展现出硬件芯片所具备的所有功能。毕竟像思 科和Juniper这类厂商是希望用其硬件芯片来实现差异化的。这样做并没错，但却改变不了所有网络都拥有一个与流量转发和访问控制相关的通用功能根集合 的事实。这一点的确是与芯片无关的。

那么，假如OpenFlow只是一个工具，又有什么特殊的理由要强调其重要性呢?

在SDN的初期，业界为这些新工具而兴奋也属正常，因为如果没有这些工具，SDN就无法将其想法变为现实。作为一个行业来说，我们已经开始了超越工 具而进入这些工具给网络所带来的现实阶段。因此，关注的重点也开始向各种用例、产品和SDN的运营转移。换句话说，普通的网络消费者不会去买SDN或者 OpenFlow，而是会在SDN逐渐成为主流时，去购买这些工具所带来的各种功能。

厂商如何使用OpenFlow

我们现在知道SDN不仅仅意味着OpenFlow。我们也知道，网络的软件编程就是不用OpenFlow也能完成任务。OpenFlow只是很多工 具中已被证明对于软件定义范式很有用的一种而已。但我们也不能犯轻易放弃OpenFlow或者将其已有影响贬低到一文不值的错误。所以，有些厂商已开始在 自己的几款商用产品中用到了OpenFlow。下面就是一些实例。

●惠普在其多款产品中用到了OpenFlow。惠普的VAN控制器利用OpenFlow，可以在一些应用如网络优化器中对交换机进行编程。该优化器可为微软Skype商用版(即Lync)提供动态QoS编程能力。

●博客的Vyatta控制器运行OpenDaylight代码，并可将OpenFlow作为编程选项之一。

●就连思科也在其为数有限的几款交换机平台上提供一些OpenFlow支持。

●别忘了，OpenFlow还是Open vSwitch中的重要工具，而后者正在持续普及中。

我们还可举出更多的例子来，但关键是要认识到很多厂商要么是在应用中使用OpenFlow的，要么是在某个硬件平台上对其提供支持的。 OpenFlow还远未达到无所不在的程度。作为行业来说，我们尚未达到可以假定任何一个交换机平台都具备OpenFlow功能的地步。即便 OpenFlow成了一种标配，我们也不能确定哪些具体功能获得了支持，或者得到支持的功能是否能用于规模化扩展。

为了解决这些问题，并让OpenFlow在未来具有更多的可预见性，ONF专门成立了各种工作组、社区和提案组。

其中一个工作组是转发抽象工作组(FAWG)。FAWG正在制定描述OpenFlow功能的一种方法，目的是为了便于硬件抽象层(HAL)的编写者们更容易在其芯片中实现OpenFlow。

FAWG的一个重要关注点就是表类型范式(TTP)。FAWG的主席Curt Beckmann称，“TTP的一个(可选)用途就是分清两件事：在给定的上下文中如何使用转发功能，以及如何通过OpenFlow来控制转发功能。”总 之，TTP的目的就是要为更便捷地使用复杂的OpenFlow指令铺平道路，因为在OpenFlow 1.0版之后，有些指令内容会变得越来越具挑战性。

FAWG是一个例证，说明ONF正在与行业合作(+微信关注网络世界)，力图让越来越复杂的OpenFlow功能更便于使用。这样的合作需要时间，但已经有了一些初期的成果。

例如领先的以太网芯片供应商博通就已在2014年12月发布了“下一代”开放交换机传输规范，称为OF-DPA 2.0。OF-DPA 2.0采用了TTP，还有OF 1.3.1中可以找到的很多丰富的功能。关键之点在于，这一进展正在让OpenFlow这一具有强大能力的网络编程工具变得更容易使用，更能够清晰地表达 出复杂的应用需求。

OpenFlow的未来看上去一片光明。本文作者在研究了SDN的很多企业用例之后发现，普遍来说，企业正在转向可以进行流量操控、流量安全和实现网络虚拟化的技术。更有趣的是，在大多数情况下，上述分类中的很多解决方案都将OpenFlow作为了编程工具。

而OpenFlow的互操作性也已成为厂商们严肃讨论的话题。例如NEC最近就宣布了与阿朗企业集团的合作，在这一合作中，NEC早已存在的ProgrammableFlow控制器将采用OpenFlow对阿朗企业的交换机硬件编程。

正因为有了这些进展，我才敢说OpenFlow的未来的确是一片光明的。OpenFlow已经在准备成为一个杰出的平均器——成为不断成长的开放网络运动中的一个关键性要素。

我说“杰出的平均器”，意思是指OpenFlow可用于消费芯片上复杂而丰富的各种功能，而且是在跨多个硬件平台的规模化扩展中使用，如此一来，垂 直集成的堆栈就会变得不那么重要了。网络业者一般所用的网络硬件都配有自带的芯片、与之相伴随的CLI(命令行接口)以及某种特殊类型的API(应用接 口)，这些组件一般都是紧密集成在一起的。假如OpenFlow最终能够变得无处不在，那么交换平台本身也会变得不那么重要了，至少不会比在其上运行的应 用更重要了。

这将在开放网络的解耦进程中发挥很好的作用，企业或服务提供商可以选择白盒交换机来运行他们自行选定的可兼容的网络操作系统。这将为他们提供多种运营选择、降低厂商锁定风险，并有可能带来成本节约。

OpenFlow能与这些价值观很好地吻合，为SDN控制器的开发人员提供一种可预测的方式来对硬件编程。一旦网络业进入这个开放的世界，爆发式的 创新就会发生。一旦一个可预测的、抽象的网络平台能够投入使用，那么面向SDN应用、运营灵活性以及提升整体IT效率的市场就将被打开。

OpenFlow或许正处在一个十字路口，但它不会迷路，更不会消失。我个人的强烈感觉是，OpenFlow最好的未来还没有到来。