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传输层协议的支持，同时针对流表开销过大的情况设计了多级流表，并增加分组策略功能。  图 1.2 OpenFLow 1.0流表结构
图 1.3 Openflow 1.1 匹配字段结构 
图 1.4 OpenFlow 1.1流水线流表结构 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的范畴，需要进一步的研究。 |
(
19个打分， 平均：
4.79 / 5)
一言以蔽之：a better 网管？或者增强了被管能力的网络设备？
这是一篇分析比较深入的好文，OF有4大致命问题还没有解：
1、原理问题：OPEN FLOW颠覆了现在TCP/IP的自智能架构，带来安全可靠等问题，是否是正确的技术方向？
2、产业链问题：主流vendor有几个是要玩真的自革命？
3、成本问题：高性能大容量的查表器成本是很难解决的鸡蛋问题
4、历史问题：其同类烈士PBB/IPTN都失败了，openflow凭什么成功？Jobs能让iphone/ipad做到了，openflow能吗？
openflow可能从新一代DC虚拟化和cloud开始应用，但能否走向外面的大众世界，就很难说了
openflow要真成了将少了多少人的饭碗，不过openflow也就在数据中心玩玩吧，现阶段这么大规模的交换机路由器都换掉是不可能的事情。
还有文中所说的可以试验网络协议，网络又不是积木赛车，哪个运营商没事玩网络协议做游戏，如果运营商要玩这样的游戏，目前我觉得只有一种可能，对业务收费什么的，可这又不是协议能解决的，硬件里的flowtable再怎么设置设置也没用，也没有办法做到业务检测的dpi
有个问题是control plane的网络由谁来负责？先要接通control path，才能给data path安装flow，从零开始，这个网络怎么跑？
To 4楼，control plane的核心放到了跟交换机相分离的controller上，controller通过某种协议跟交换机通信，然后将体现管理员意志的或者某个算法结果的转发规则下发到交换机上。至于这些规则如何生成，可以是静态配置（像配置ACL一样）或者跑一个什么管理员自己设置的算法。
但是无论如何，最终体现到转发面，就是Key+Action, 其中的Key就是类似ACL key。
to:kernelchina
Control Path可以是out of Band或者是In band两种，Out Of Band意味着你需要独立的控制面网络，就和目前各种通信设备内部总线设计一样，控制面和用户面是分开的，缺点是需要额外的设备和连线，成本相对高昂；In Band，则需要在现有网络中先打通这个控制面，比如配置特定的VLAN，这个VLAN中的网络需要能够正常自举，比如运行STP协议，这就需要交换机设备既支持OpenFlow也支持传统模式，是所谓的Bybrid模式。
我认为还是Out Of Band比较清晰，In-Band模式还需要OpenFlow协议做进一步的标准化
其实out-of-band网也有同样的问题，out-of-band网本身怎么跑起来？如果网络大一点的话，这个OOB网还是得传统的路由设备来搭。
目前网络设计中，无论是L2网络还是L3网络，无论是带内网管还带外网管，都是路由型的DCN
OF是一个不错的idea，但是ideal要变成reality，就一定要考虑和商业应用的真正结合点，要考虑兼容性，而不是一步到位，即使在传统的IP路由领域，OF也是有实际的应用可能的，但先要基于现有的路由架构，不要去做什么革命，因为占统治地位既得利益者绝不会支持你革命的。要去解决用户因无法定制vendor的设备而必须求vendor开发和一些小特性的现实问题，比如根据多种系统状态决定路由的发布。初始先不要依赖vendor提供真正的API，可以通过vendor提供的各种可以获取的信息，display/show/trap/alam/log等等，提取系统关键信息，做成标准的OF接口，也不要立刻提供真正的编程，而是用脚本语言控制设备的状态和命令，类似TCL，可能用XML更好，也不一定要直接运行在vendor设备上，可以运行在remote terminal，例如TCL或者OSS上，现实情况，更多是OSS，这种接口虽然可能因为vendor的原因不够稳定，但如果客户要商用，就会和vendor签订相应的协议，让vendor保证某些状态信息的统一性。所以具体商用初始是要和OSS供应商合作，这样一步一步来，最终把vendor引导向开放统一的API，直接设备运行外置程序。OF的商业化可行性，一定要follow这样的路，才能真正拓展到通用IP路由领域。
有点像SS7的智能网呢。。。简简单单的IP网络，越来越不简单了。
1K升级了？
7楼说的对，网络再大一些怎么办，openflow及其下管的网络再跟别人接还是要在原来的各种协议上做，所以openflow就在数据中心玩玩比较靠谱
这个看着和原来ATM网管比较像，开一条PVC不用网管都很难，网管宕机了要调整PVC也很难…
非常同意文章最后一段：Data center是一个封闭的大系统，比较适合玩Openflow；Edge Router历史包袱太重，不适合Openflow。
理客的看法很有道理，但我理解其指的是完全在现有的圈子里由运营商推动革新的情况，而产业的变革往往来自于圈外或者圈内弱势群体，比如苹果对智能手机产业的革命，微软和Intel对计算机的重定义，无产者革命更彻底嘛。
因此我个人除了OpenFlow技术外，更加关注OpenFlow本身对产业链的分化和激励作用，关注哪个初创公司能够有能力把OpenFlow Controller(NOS)做好。NOS做好了，想做傻瓜硬件交换机/路由器的厂商多了去，比如某些芯片厂商，本来就拿不到思科的单子，没有能力做完整的网络设备，做个傻瓜转发设备还是绰绰有余的，大家拼杀一番，网络设备领域的微软+Intel+DELL/HP就出炉了。在这个过程中，Datacenter应用的示范作用很重要，搞好了，往其它方面扩展运营商就有了信心，否则，OpenFlow也就止步于此。
另外我的看法是OpenFlow不会导致产业减少饭碗，它是通信设备产业从初创的阳春白雪走向成熟期的下里巴人最终宿命的道路之一，堵上了这条，会有另外一条通往同样宿命的捷径。下里巴人的市场蛋糕更大，但挣超额利润可能比较困难了
这是两条路，革命和改良，那条路走通了都可以。因为个别项目实践中发现目前因为vendor没有open，导致operator的一些小需求不能自己解决，必须求助vendor，而实际上，如果vendor能做一些open，有些小需求是可以通过脚本方式解决的，通过这种目前很可能有商业应用的实践，不断推广open的标准和商用软件，把原来封闭的IP路由vendor市场逐渐引导到标准的openflow路上来，这个过程长一些，也容易一些，激烈对抗和反馈也少一些，个人认为比革命的路要好走一些。apple、Wintel的方式，要走早IP路由市场还是很难的
理客说得很对啊，有时候我们对 vender 提供的snmp mib不满意，但是又动不了，很烦…
都flow-based的forwarding了，精确匹配，FIB table不是必须用TCAM。
OpenFlow适合的市场是企业数据中心，比如Google、Facebook这样的。大规模，内部网络，但从网络层面看数据类型比较简单。特别是Google，不是一直自己在开发自己的交换机么。
其实“理客”在二楼说的第一点很重要：OPEN FLOW颠覆了现在TCP/IP的自智能架构，带来安全可靠等问题，是否是正确的技术方向？
在数据中心网络中，模型简单，就是一个高密度无阻塞的网络，拓扑稳定，环境简单，链路可靠性高，用openflow确实可以非常好的降成本。
但是，如果换到了广域网，模型没那么简单，拓扑没那么稳定甚至经常变化，链路可靠性没那么高的时候，用openflow还能很好的工作吗？
另，openflow显然不满足：“网络任意部分故障，不会造成整网崩溃”这一设计原则，其controller是明显的弱点。
最后说一个不是特别合适的联想，当社会设计越来越*的时候，网络设计怎么越来越*了呢？
就像前面有人提到的，openflow的控制器概念就像ATM的网管，任意增减pvc、属性更改必须通过网管机操作。
整个Internet适合这么做么？
那么相对封闭的DC复杂度会降低，但是事无巨细必须通过网管定义的方式，真的比自适应/自智能的网络架构更容易管理/运营？
to楼上：OpenFlow控制的网络还是自组织的，不过是智能上移到Controller，Controller负责探测网络，计算拓扑，并根据拓扑图生成转发表下发给转发设备。基本网络运行是不需要Controller任何配置的。
另外OpenFlow忽悠的好处是增加一个网络操作系统层，将OpenFlow接口进行封装，开发者可以采用脚本语言对网络行为进行编程，就如同Web开发一样简便。
另外，Controller采用通用计算技术构建，可以分布式处理，比如用DHT算法构建，大可避免单点故障
这里现在也网警啊，呵呵
———————————
总体看起来，openflow是要用网络控制器和网络操作系统替代目前的网络设备自组织/自治。
基本上是一个推翻和重建的过程。。。
从人文历史上看，打破一个旧世界，建立一个新世界，需要革—命的动力，呵呵。
至于说控制器上的灵活性、便利性，网络拓扑的部署也不是可以随意更改的，同样需要规则。
那么多的RFC也只是创建规则体系而已。*控制同样需要遵循规则。在规则内调整。
频繁的大幅度变更整网的网络拓甚至扑算法其本身也是不甚合理的。规则本身的调整同样是很慎重的事情。
而所谓的封闭/开放，也从设备层面转到了DC site/运营商层面。交换机/路由器是在“open”下开放了、大同了，不同运营商之间呢？各自的拓扑甚至算法都可能是独立/封闭的。
那么，能不能说，现在运营商都用相同的协议，是运营商级别的open呢，呵呵。
如果仍旧使用现有的RFC，只是将控制平面从网络设备分离，然后集中控管。
看看Open Networking Foundation的发起人吧，德电、Facebook、Google、微软、Verizon、Yahoo!，基本清一色运营商。
所以，openflow到底是技术推动，还是政治/利益推动，值得观察。
open让网络设备供应商进入同质化竞争，让C的自研芯片变得无用武之地，所以巨头们顶多也就是自己内部搞搞open，不会和低成本的供应商open的。差异化竞争带来高额利润，谁和money有仇啊。
在DC的应用中，抛开controller控制面的其它问题不说，多路径的生成和管理就是个难题。而如果不使用多路径，一是带宽照样浪费，二是一旦工作链路故障，恢复时间就会太长了。
to 23楼
这次ONF的发起人都是运营商巨头，把网络设备厂商都变成富士康难说不是他们的愿景，那样他们就可以cosplay现在的苹果了，嘿嘿。
喜欢23楼的评语：
“而如果不使用多路径，一是带宽照样浪费，二是一旦工作链路故障，恢复时间就会太长了。”
好像 sycamorenet.com 有在控制平面的长处，可以达到快速恢复和智能控制的很多功能。这些Traffic Engineering和容错的需求在MPLS里面也是可以通过tunnel做到的。
open flow slow path 都要在controller建
假如几千个服务器上的虚机中了病毒。按地址段乱发数据包，这样控制面在同时可能要建立很多的新的flow.
即使这些flow是简单的3层。那么controller每秒也要创建大量的flow. 这个controller的扩展性能不能支持到？
好文，看完后有茅塞顿开之感
好文，看完后有茅塞顿开之感，对英文材料还是理解不深啊
文虽好，但弯曲最精彩的还是评论！同意2楼，14楼的观点
好文章。
OF的1.2已经出来，没人聊聊？
我觉得，OF现在谈运营商还为时过早。运营商需要很高的reliability & availability，以前相对高要求的OAM等功能，而这两点我觉得目前都不成熟。
高可靠性显然不容易从open source的project得到，所以有些公司，比如作者似乎漏掉的另一家比较重要的初创公司，big switch，致力于建立一些high end controller的开发。像26楼的问题当初我也有疑问，还曾经就此问过big switch里的一些专家。他们当时的观点是这的确是个不scalable的问题，很难有很好的解决方案，但是在特定的环境下，你未必有如此多数量的流每秒建立，并且对初建的流，你总可以设计一个”learning packet”，这样你只在第一个无关紧要的packet有大的latency，以后就没问题了。
另一方面，运营商的设备供应商通常积累了大量在data path以外的经验，比如middleware，ha,management plane,oss integration等等， 这些未必能在commodity switch上很容易实现，如果要实现，势必要reinvent the wheel。
上面几位同学提到了运营商想实现一些小feature，需要依赖于设备商：实际上Juniper的JUN OS已经提供了相关的API，可以基于这些API做二次开发，与文中提到的NOS殊途同归。
无论openflow成功or失败，我常在想如果我大宋在业界能整出这么大的动静来，我们这些大宋的手艺人该有多欣慰啊。
我们更多的不是没有这个IQ，而是在发展中我们所处的阶段，会更多的看中短期可获得利益的可能性，因为做起早的鸟，多会因为找不到食而夭折，看看飞漫软件类似的例子。所以即使被许多国人看上的HW，教主首先要做的也是工程商人
NOS2012上google声称已经在一个DC中部署了openflow。
“采用Python、JAVA Script这样的脚本加上开源算法库、一个不需要了解太多网络协议细节的开发者几天就可以实现一个新的网络拓扑算法开发、部署。”
如果这个技术推广对网络工程师有何影响，重新学习？会点网络的程序员是不是反而更有优势呢？
有喜欢玩玩openflow的，可以下载这个教程，教你一步步安装openflow交换机等，不需要controller也可以测试玩http://vdisk.weibo.com/s/g–Hl
To 36：该文件已被删除或取消分享
SDN的本质是Network Virtualization.
不仅仅是一个高级的网管的设备.
对内, 它是一个可以统筹和管理整个网络资源的controller.
对外, 它就是一个三层设备或者三层交换设备.