解读SDN核心技术：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、Force十、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的范畴，须要进一步的研究。