SDN核心技术OpenFlow

SDN核心技术OpenFlow：

OpenFlow是由斯坦福大学的Nick McKeown教授在2008年4月ACM Communications Review上发表的一篇论文OpenFlow: enabling innovation in campus networks首先详细论述了OpenFlow的原理。

1 OpenFlow简介

OpenFlow是由斯坦福大学的Nick McKeown教授在2008年4月ACM Communications Review上发表的一篇论文OpenFlow: enabling innovation in campus networks首先详细论述了OpenFlow的原理。由该论文课题可知OpenFlow提出的最初出发点是用于校园内网络研究人员实验其创新网络架构、协议，考虑到实际的网络创新思想需要在实际网络上才能更好地验证，而研究人员又无法修改在网的网络设备，故而提出了OpenFlow的控制转发分离架构，将控制逻辑从网络设备盒子中引出来，研究者可以对其进行任意的编程从而实现新型的网络协议、拓扑架构而无需改动网络设备本身。该想法首先在美国的 GENI研究项目中得到应用，实现了一个从主机到网络的端到端创新实验平台，HP、NEC等公司提供了GENI项目所需的支持OpenFlow的交换机设备。OpenFlow其架构见下图：

▲图 1.1 OpenFlow概念架构

Openflow的思路很简单，网络设备维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配。

这种控制和转发分离的架构对于L2交换设备而言，意味着MAC地址的学习由Controller来实现，V-LAN和基本的L3路由配置也由Controller下发给交换机。对于L3设备，各类IGP/EGP路由运行在Controller之上，Controller根据需要下发给相应的路由器。流表的下发可以是主动的，也可以是被动的，主动模式下，Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发;被动模式是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间。当一个Controller同时控制多个交换机/路由器设备时，它们看起来就像一个大的逻辑交换机，各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡，类似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架构中可以看到影子，Cisco称之为nV(Network Virtualization)技术。

OpenFlow 1.0的流表分为Match Fields、计数器和指令集三个部分，Match Fields是报文匹配的输入关键字，计数器是管理所需，指令集是决定报文如何转发，最基本的转发行为包括转发给某个端口、封装改写报文后转发以及丢弃。 OpenFlow 1.1增加了对MPLS以及UDP/SCTP传输层协议的支持，同时针对流表开销过大的情况设计了多级流表，并增加分组策略功能。

2 “Open”还是”Flow”

Nick同学借着GENI项目完成了OpenFlow的初始概念实验后开始向产业界推销，目前已知Arista Networks, IBM, Juniper Networks, Hewlett-Packard以及NEC等厂商在其部分交换机中支持OpenFlow协议。从其经历来看，其绝非是一个象牙塔中的单纯研究者，而是时刻和产业界保持了密切的联系。Nick 1986-1989年在HP实验室从事网络技术研究，1995年参与了Cisco的GSR12000路由器的架构设计，并且也是CrossBar的设计者之一，并且先后创建了Abrizio和Nemo System公司，后者在2005年以$12.5M卖给Cisco公司。2009年又不甘寂寞，创建了以推广OpenFlow为目标的Nicira公司，该公司是开源OpenFlow Controller NOX的维护者。

2011年3月21日，由德电、Facebook、 Google、微软、Verizon、Yahoo!发起成立了Open Networking Foundation，旨在推进实现基于OpenFlow的开放网络，参与者众多，从交换芯片的博通、Broadcom到网络设备的提供者Cisco、 Juniper、NSN、Force10、Ericsson、NEC以及数据中心解决方案提供者IBM、HP、VmWare、Citrix以及运营商 NTT等等。网络设备提供商中阿朗、华为、中兴缺席，阿朗缺席可以理解，毕竟数据中心不是其产品方向。

除了在Datacenter中的应用外，OpenFlow的拥趸者还提出了采用OpenFlow实现网络虚拟化的架构，以支持虚拟网络运营商，其中开源的FlowVisor作为网络虚拟控制层(相当于HyperVisor)，将网络资源根据VLAN、IP分段等各种信息进行切片，分发给上层的Open Flow Controller(相当于Guest OS)进行，在各个VNO(虚拟网络运营商)的Controller上VNO可以采用脚本编程来控制其租用的虚拟网络的各种转发、QoS策略。该模式也同样适用于数据中心运营商提供VPC(Virtual Private Cloud，虚拟私有云)业务时将网络虚拟化和计算存储打包出售给租户。

虽然Nick同学忽悠了这么大的阵势，还是有很多人疑惑openflow的价值到底在哪里，是Open还是Flow?这个问题首先可以否认”Flow” 的价值，原因很简单，是否控制到细粒度的Flow取决于应用，应用没有控制流的需求，则Flow毫无价值，”Flow”只是Openflow能提供的最大限度的控制能力而已，目前在ONF关注的数据中心交换网中没有谁打算控制精确到n(n>=5)元组的流，除非是应用在防火墙控制上。

那么”Open”呢?的确包括Nick本人在内一直强调的都是”Open”是价值之所在，Open之后，研究者、运营商可以采购任意厂商的标准接口设备，自己DIY网络，甚至可以采用交换信息厂商提供的公版设计交换机加上OpenFlow Controller就可以组成自己所需的网络，并且Controller的开放软件架构使得网络控制的实现就像Web编程一样简单，采用Python、 JAVA Script这样的脚本加上开源算法库、一个不需要了解太多网络协议细节的开发者几天就可以实现一个新的网络拓扑算法开发、部署。这在流量模型尤为复杂运营级数据中心确实非常有吸引力。在这样的一种场景中，网络设备市场就变成了如同PC那样的市场，卖网络设备硬件的就成了卖大白菜的，大家最后只能比拼价格和工艺设计了。但是，即使这种悲惨的场景成为事实，谁又会是PC化的网络市场中提供Windows的微软呢，Openflow体系的NOS将会谁是赢家? 交换网络相对简单，但是L3之上各种协议散落在数十年积累的数千篇IETF RFC中，谁能够有实力实现一个如此复杂的网络操作系统而又让运营商放心呢?我想仍然可能是今天的网络设备巨头Cisco、Juniper们，产生意外的可能极小，但是产业链已经被家常，竞争的焦点已经发生了转移

从NGN引入控制承载分离架构的经验来看，没有一个领先厂家愿意开放媒体网关的控制接口，也几乎看不到商用的开放接口组网案例，因此可以推断即使OpenFlow广为业界采用，”Open”成为现实必定困难重重。如此一来 Openflow能够留下的就是单厂商自己实现的控制转发分离架构以及控制器开放软件架构带来的降低开发周期、新功能快速面世能力。控制和转发分离架构在 NGN带来的好处是两方面的1)对于设备供应商而言，不必为两种完全不同的能力塞在一个空间、功耗、成本均受限的一个盒子中而又保证足够的可扩展性而苦恼，两种硬件平台、软件架构可以分离发展，分别实现最优设计。2)对于运营商而言，可以获得部署上的灵活性和管理上的便利，媒体网关由于要汇聚流量，靠近用户可以节省电路资源、减少时延，控制器部署集中在更高位置，与运营商的集中管控战略一致，方便降低Opex。这些好处在Openflow架构中类似。

有人会争辩说上述好处采用集中网管也可实现，不错，所谓殊途同归，技术层面上来讲没有一种技术是不可替代的，但是产业链、经济性也就是市场是最终的评判者。如果采用网管来实现的话，实现Openflow同等的能力需要网管服务器参与到转发的在线决策中，那样网管服务的可靠性指标要提升几个数量级，并且要定义网管接口可以将未命中策略的流量引出来，那不过是另外一种形态的Openflow，就如同Cisco的nV技术一样。

3 OpenFlow对产业链的影响

如上节所述，OpenFlow隐隐约约有将网络设备市场PC化的可能，但目前尚缺一个类似于类似于微软的基于OpenFlow的网络设备操作系统提供商。理论上，运营商会喜欢网络控制接口，技术流的运营商也乐于DIY自己的网络，比如数据中心的拥有者Google、Facebook的服务器已经采用大量定制化的廉价服务器搭建自己的计算服务设备，对于网络，他们也已经开始通过ONF启动了DIY之旅。

DIY之后，网络设备价值链的核心分化，网络交换芯片，尤其是FlowTable处理器将是一个核心价值所在，控制器(也就是前述的网络操作系统)软件系统也是价值核心，有了这两个组件，大量廉价网络设备硬件将涌现在市场之上，这使得硬件市场利润摊薄。但是这种开放性将使得网络创新速度加快，尤其是当这个领域有幸诞生新的固执摩尔定律的Intel和开源Linux操作系统。

通信领域的产业周期中，创新的功能走的是一条运营商提出需求 ->设备供应商分析需求->标准组织标准化->设备供应商实现->运营商测试并采用的超长路径，周期以数年计算，而互联网业务提供商往往集运营商和供应商于一身，创新功能的采用从需求发现->设计->开发->上线在一个商业实体中完成，并且功能开发过程中可以不断获得用户的反馈而改进设计，这是所谓的Web业务开发的”永远是Beta版本”的概念，应用到网络设计中，运营商可以自行设计网络拓扑算法，并且可以根据网络性能统计进行迭代调整。由此可见此种OpenFlow的远景可能结果是将网络创新从供应商巨头垄断转变为运营商主导创新。

4 OpenFlow面临的技术难点

Openflow的推广除了面临上一章所述的产业博弈的问题外，目前还面临着一些技术的难点。其中之一就是路由器/交换机中广为使用的快速查找TCAM 存储器成本的问题。在传统设备中，需要采用TCAM的表包括FIB、MAC、MPLS Lable和ACL表，每个表的匹配字段长度不一，分开设计，并且设计了最大容量，以期达到最小的开销。而在Openflow设备中，不再区分匹配长度短的FIB、MAC、MPLS Lable表以及较长的ACL表，一律采用最大长度的FlowTable记录代替，对于OpenFlow1.0而言，Flow table的匹配字段长度长达252比特，而一般IPV4 RIB TCAM匹配字段长度只有60-80个比特，开销增加了3倍以上，而对于路由器的线卡而言，TCAM成本占了约20-30%，功耗也占了很大一部分。因此如何减少FlowTable尺寸将是OpenFlow体系面临的一个极大问题，此外，TCAM体系下FlowTable记录的动态插入算法将更为复杂。

OpenFlow1.1设计了多级流表来减少Flowtable的开销，将流表进行特征提取，分解成多个步骤，形成流水线处理形式，从而降低总的流表记录条数，比如原始流表共有10000条，分解成先匹配VLAN+MAC，再匹配IP和传输层头部的两个独立流表，每个流表的数量可能均小于1000条，使得流表总数小于2000条。但流水线式架构使得匹配时延增加，而且流量的生成、维护算法复杂度提高，至今也未见到针对真实网络的效果评估报告。

OpenFlow的关键是通过OpenFlow将网络转发的原子操作抽象出来，并以流表来驱动流程，我们所论述的一切好处是建立在OpenFlow FlowTable能够很好地将Primitive和WorkFlow抽象，支持设计新的协议在大部分情况下的确可以通过只修改Controller的逻辑来实现这一假定上。在OpenFlow最初应用的Switch领域，OpenFlow已经有杀鸡用牛刀的嫌疑了。但是路由网络，尤其是包含有大量用户控制逻辑的边界路由器，如BRAS、无线网络的GGSN/PDSN/xGW等设备，OpenFlow需要扩展将用户控制逻辑抽象为原子操作和流程，那可能已经不适合叫FlowTable，叫AccessControlTable更合适，转发操作本身的匹配规则、转发操作中也需要增加对现存的各种接入协议和表征接入会话的协议字段的支持，比如PPPoE、GTP-U、PDP激活操作的匹配和转发封装支持。

5 结论

从需求面上讲，控制转发分离、集中控制的确可以为运营商带来好处，对设备上自身的设备软件架构也有借鉴作用，但是”Open”出来的驱动力不足，面临产业的博弈，诸多市场后进者可能会借OpenFlow博上位，但是市场既得利益者必定会持反对态度。有人会提出，我的设备本身就是控制、转发分离的架构了，我将控制功能出来就行了，没错，Cisco们看起来就是这么干的。

从具体细分市场而言，数据中心中OpenFlow处理复杂流量模型、集中管控有优势，而且随着多租户数据中心业务的广泛开展，OpenFlow所支持的网络虚拟化多租户架构、甚至可以将Controller和虚拟机管理系统进行水平交互从而实现网络和计算存储的联合调度，其带来的好处对Datacenter运营商是有一定的吸引力的。而边缘路由器的应用则是补齐网络虚拟化这个大的拼图的一部分，并且边缘路由器，尤其是无线网络的边缘路由器，需求输入仍然较多，控制转发分离架构对于加快产品创新周期、较少市场响应周期有一定的积极意义，但是其主要功能超出目前OpenFlow的范畴，需要进一步的研究。