OpenFlow所面临的挑战

OpenFlow标准的不成熟，在控制层面也有不少体现，尽管体现的不如转发层面那么明显。根据对OpenFlow标准的分析以及一些实际部署案例的反馈，OpenFlow在控制面还存在如下不足：

• Master（主）和Slave（备）Controller的选举机制还不够成熟，都没有标准来定义。
• Controller的集中式控制，理论上肯定会有可扩展性问题，分布式控制又跟SDN的原则有些冲突，到底应该如何把握好这个平衡？
• 流表配置的速度比较慢，特别是网络比较大的时候，要配置这么多设备的这么多流，速度跟不上，有严重的性能问题。
• 仅凭现有的OpenFlow接口，还有很多配置无法完成，需要很多私有扩展，这会导致不兼容性。
• 安全性还不能得到充分保证，需要进一步的安全机制。
• 原来的所有控制面协议都在每一台设备里面，现在都集中到了Controller上，这是否合理？是不是有些东西还应该保留在交换机上？Google进行了OpenFlow实践之后，在总结报告里面就提到了这个问题，哪些东西该放在交换机上、哪些东西该放在Controller上并不是一个容易回答的问题。

跟转发面的挑战不同，转发面如果有功能性问题，直接会导致OpenFlow设备没法用（因为不能满足功能需求），而控制面的挑战更多在于网络健壮性、稳定性、可扩展性、安全性，也就是说做实验网络或者小型商用网络没问题，但是一旦要用在大中型网络等情况复杂的网络中，控制面的问题就会变得很突出。这就像很多时候在实验室里面验证网络设备的时候，大多数问题都出在功能上面，网络管理系统的故障很容易解决并稳定下来，但是一旦到了商业网络里面，很多控制管理面的问题就暴露出来了。

跟传统的协议一样，OpenFlow技术要想成熟稳定，必须经过大量的实践检验，ONF需要尽最大可能去避免OpenFlow走入一个“标准不成熟→缺少商用案例→无从反馈→标准仍然不成熟”的恶性循环。

如Google总结自己的OpenFlow网络的时候所言，OpenFlow控制面的问题确实存在，但是都是可以改进的，毕竟那都是软件工作。但是转发面的挑战就不同了，那要依赖于交换芯片，商业交换芯片研发周期长，技术门槛高，且全世界做商业交换芯片的厂家也没几家，OpenFlow对转发面的要求跟当前商业交换芯片的架构相去甚远，转发面所面临的挑战不是一般的大。

具体表现在以下几个方面。

• 按照OpenFlow标准，一张流表可以使用任意的字段组合（比如MacDa，MacSa，EtherType，Vlan，Cos，CFI，Protocol，Ipda，Ipsa，L4 Dest Port，L4 Source Port，Dscp等）去做查表，在当前的商业芯片设计中，这意味着必须使用TCAM表来做，因为只有TCAM才支持掩掉任何想掩掉的查找字段。但是TCAM是一种昂贵的资源，具体表现在占用芯片面积大（一条TCAM表项相当于五六条DRAM表项）和功耗大，而占用芯片面积大直接导致芯片成本高以及整机电路板设计成本高，功耗大导致整机散热成本和能耗成本上升。如果按照很多客户的要求，动辄要几十KB甚至上百KB的流表要求，至少需要20Mbit的TCAM，远远超过目前市场上容量最大的交换芯片的TCAM大小。
• OpenFlow提出了多级流表的概念，而且没有限制有多少级。这对芯片设计也很难受。传统的芯片肯定是没有多级流表的概念的，只有多级流水线（Pipeline），如果要设计多级流表，需要对架构进行大改，特别是OpenFlow要求每级流表出自己的编辑动作，编辑动作的结果作为下一级流表的输入去参与下一级流表的查找，这完全颠覆了传统芯片的设计，传统芯片一般都是使用原始报文的信息去做一系列查找，最后一次性编辑。另外，多级流表最大数量不确定的话，芯片也不好设计，芯片设计里面的流水线数量是确定的。而且，流水线越长，报文处理延时就越长，这对数据中心业务不是好现象。
• 在传统芯片设计中，所有的行为都是协议相关的。特定的协议有自己特定的处理模式和处理过程，某个协议处理过程中要编辑什么字段，做什么动作都是确定的，比如路由处理过程中，会去替换二层头，会去减TTL，可能会去修改DSCP，但是不会去改IP地址（如果改了IP地址，那是NAT的行为，不是普通路由的行为）。再比如普通二层转发，可能会去修改vlan tag，但是绝对不会去修改IP地址，也不会去修改Mac地址。而OpenFlow的要求则不一样，按照OpenFlow的报文处理流程，都是协议无关的，也就是说，报文在OpenFlow交换机中被转发的时候，没有路由、Bridge或者MPLS的概念，没有Nat的概念，没有Trill的概念，没有PBB的概念，它有的只是一个很中性的、很通用的Match-Action的概念，即匹配到什么字段，去执行什么动作。传统的交换芯片里面，除了ACL，是不会有这种协议无关的处理的，ACL虽然看起来是比较中性的、但是它的动作一般也都是固定的几种，比如复制到CPU、重定向、做限速、镜像、统计等，远比OpenFlow要求的动作少得多，OpenFlow要求可以任意去修改报文的每一个字段，将报文送到任意目的地。这些都是传统芯片不会去做的或者就算想修改设计去做，也很难做到所有要求的动作。
• OpenFlow定义的行为类型只是传统芯片的一个子集。OpenFlow只定义了跟流相关的处理，比如如何来识别一条流，识别之后如何来编辑和发送或者丢弃它。但是它没有定义任何跟状态和时间相关的东西，而传统芯片的处理则比OpenFlow要复杂得多。举个例子来说，SDN是要应用到运营商传输网络的，传输网络有严格的故障检测和保护倒换的要求，需要在网络里面运行OAM。OAM需要芯片支持，芯片里面需要运行状态机在定时发包以及复杂的收包处理（触发状态机运行）。这些OpenFlow没有定义。再比如1588时钟同步，有时戳操作，OpenFlow也没定义。
• 跟上一条可以归为同一类，传统芯片中，针对每个协议都有很多种判断、检查，比如芯片里面有很多逻辑大概如下：

If (A && B && C…) then 

{

 if (D&&E) then….; 

else if (……) then…..;

}

总结成一句话就是，往往有很多条件判断和分支流程，要使用流表来把这些条件判断都表达出来是不可能的。有些就算勉强用很多级流表来处理一个报文能够完成这些条件判断，代价也是非常大的。

换句话说，协议无关的芯片设计，在取得流处理相关的灵活性的同时，却丧失了特殊协议特殊处理所带来的简单性。其实做过软件系统的人很容易理解这一点，一个模块或者函数想做得通用，是有代价的，想要融合在一起的东西差异性越大，做到通用的代价就越大，达到一定程度，基本上就是不可行。OpenFlow要做的事情就有点类似于这个，有些模块与模块之间，行为处理的差异性是很大的。OpenFlow为什么要设计多级流表？绝对不仅仅是为了Tunnel解封装或者节省表项，应该是已经考虑到了要靠多级流表的处理去代替传统的各种判断检查。但是，说实话，这很难。

• 前面都是从纯粹地芯片设计理念来看OpenFlow转发面的挑战。也许以后会有人发明出一种设计方法来解决这些问题，但是不是现在。OpenFlow在转发面现在面临的最大的问题是，现有的所有商业ASIC芯片，对OpenFlow的支持都很有限，包括一些技术上理论可以做到的动作，因为现有的商业芯片设计的时候没有预料到这种应用。在流表规格上，现有的芯片支持也都很有限，都是几KB级别的，远远不能满足大规模部署的要求，甚至小规模都可能是个问题。而且，芯片厂商去研发新的专门支持OpenFlow的芯片的动力严重不足，因为市场前景不定，风险太大。
• SDN并不仅仅用来控制交换机，它的涵盖范围很广，从交换机，到路由器、防火墙、负载均衡设备、无线设备、传输设备等。但是OpenFlow目前定义的转发面行为主要适用于交换机和路由器（尽管也部分适用于别的设备），如果真的要做到在不同设备之间通用，差得还很远。

OpenFlow转发面的各种尝试和创新

尽管芯片厂商对设计专门的OpenFlow芯片表现出了犹豫，但是这并不代表大家对这个市场无动于衷，毕竟，机会与挑战并存。一方面，各个设备商都想方设法在现有芯片的基础上，八仙过海各显神通，去利用现有机制包装OpenFlow设备。另外一方面，就算是观望中的芯片厂商，也会希望在花费最小代价的情况下，做出一些折中的努力。而至于ONF组织，更是不遗余力地想办法去推动OpenFlow转发面的前进，我们这里总结一下目前已知的各种尝试。

• NPU和FPGA方案

OpenFlow强调转发面的可编程，所以人们最容易想到的就是使用FPGA（现场可编程门阵列）或者NPU（网络处理器）来做。因为跟ASIC芯片不同，这两个都是可编程的物理器件。但是它们无论在成本还是交换容量上都不如专用的ASIC交换芯片。在OpenFlow领域，它们最多只能用作补充，以及用来验证技术可行性。斯坦福大学刚开始研究OpenFlow这个项目的时候，用的就是基于FPGA开发的NetFPGA可编程平台。

据称NEC的OpenFlow交换机，就是用了商业ASIC芯片加FPGA协助处理的方式，所以他们号称可以支持绝大部分OpenFlow的功能，但是价格奇贵无比，无法大面积推广。

华为公司在2013年8月推出了一款新的号称敏捷的交换机S12700，这款交换机最大的亮点就是使用了华为自研的名叫ENP的NPU芯片。根据华为的宣传资料来看，这个ENP在交换容量上跟现在高容量的ASIC还有较大差距，功耗据说可以接近（但是不知道是否有水分），价格上面它的成本价可以接近商业芯片的市场售价，后续还会继续发布基于该芯片的中端交换机。但是笔者始终认为，这个只能是一个补充，不会是主流。

使用NPU或者FPGA来做OpenFlow，除了有成本功耗的弊端之外，还有一个很多人并没有意识到的问题。芯片可编程并不代表交换机可编程。什么意思呢？ASIC一旦做出来之后，就无法再改了，不支持就是不支持了。而NPU做出来之后，如果设备商觉得还需要支持新功能或者要修改一些Bug，可以根据情况再出一版，这是NPU跟ASIC的区别。但是对于交换机用户来说，用ASIC做的交换机还是用NPU做的交换机是一样的，用户都是只能在设备商提供的接口上编程，并不会因为你用的是NPU做的芯片，你就可以去随便修改转发行为，因为系统用户没有办法去改NPU。换句话说，假设一个ASIC芯片设计了一个很灵活的架构而一个NPU芯片设计的架构很差，那么对于交换机用户来说，他能得到的可编程能力，前者要大于后者。用户唯一可以指望的是，设备商也许可以在半年或者一年后，根据情况，给你来升级一下交换机软件和NPU的微码，从而让你的交换机拥有新的能力。

一个OpenFlow交换机要想真正拥有灵活可编程能力，必须要所用的ASIC芯片或者NPU芯片的架构是非常灵活的，不需要设备提供商对芯片进行升级就能够通过软件来进行重新编程。从这个意义上来说，ASIC跟NPU并无差别。

• TTP/NDM方案

我们普通技术人员都看到了OpenFlow标准在转发面的一些缺陷，ONF组织自然更是看得很清楚，而且他们也非常清楚这些缺陷对OpenFlow的发展所可能产生的重大阻碍作用，所以成立了一个FAWG（Forwarding Abstraction Work Group，转发抽象工作组）来进行转发面的抽象化工作，他们的目的并不是要设计一颗芯片，而是希望能帮助提炼出一些OpenFlow芯片所需要的共性的东西来，帮助厂商找到一个可行的方案，或者找一个临时过渡方案来加速SDN的发展。

这个工作组在2012年就提出了一个叫作TTP的方案，TTP是Table Typing Patterns的缩写，中文不知道怎么翻译能比较精确地表达它的本意，但是TTP想要达到的目的是很清楚的，它就是要利用现有芯片的处理逻辑和表项来组合出OpenFlow想要达到的功能，当然不可能是所有功能，只能是部分。在2013年，这个工作组的人也觉得TTP这个名字含义不够清晰，无法望文生义，所以他们又给它改了个名字叫NDM（Negotiabable Data-plane Model），即可协商的数据转发面模型。笔者以为这个名字比TTP好多了，不仅因为我能翻译出来，更主要的是这个名字中的三个单词都能体现这个方案的精髓。NDM其实是定义了一个框架，基于这个框架，允许厂商基于实际的应用需求和现有的芯片架构来定义很多种不同的转发模型，每种模型可以涉及多张表，匹配不同的字段，基于查找结果执行不同的动作，由于是基于现有的芯片，所以无论匹配的字段还是执行的动作都是有限制的，不能随心所欲。

在这种方案中，Controller必须明确地知道交换机的能力，能够支持哪些NDM模型，这就需要Controller和交换机之间能够进行协商。而且为了让整个过程自动化，还必须能够使用一种标准的描述语言来对具体的模型的能力进行描述（比如有多少Flow Table，每个Table能匹配什么字段，能执行什么样的Instruction，能支持多少Flow等）。FAWG工作组决定扩展OF-Config协议来支持Controller和交换机之间的协商。

按照标准OpenFlow，每个Flow表都需要能匹配任意的Key组合，且要能够出任意的Action，但是在传统的芯片里面，只有ACL表勉强能满足要求，无法支持多级流表。而在NDM方案中，他们尽量保持南向接口不变，但是在内部实现的时候，不是全部都用ACL表，而是用了其他表项，比如路由表、Mac表、vlan表、port表、MPLS表等。当然用这些表无法满足OpenFlow灵活的需求（任意的Key组合，任意的Action组合）。设备商们认为NDM方案可行的原因在于，尽管按照OpenFlow的灵活要求，NDM满足不了，但是大多数实际应用不需要那么灵活，大多数应用使用传统表项组合就可以满足了。比如大多数二层转发应该还是基于Mac+Vlan，大多数三层转发应该还是基于Vrf+Ipda/mask。

有人会问，那么这种NDM方案跟做一个传统交换机有什么区别？区别就在于NDM方案虽然用了传统表项，但是它的架构是SDN架构（控制面和转发面分离），而且控制面和转发面的接口仍然是OpenFlow接口。换句话说，从外部表现来看，这就是一台OpenFlow交换机（在应用是比较传统的情况下，如果有些非常规的查找Key组合，那就满足不了）。

下图是最早的时候某公司给出的NDM方案（那个时候还叫TTP）流程图，我们看到这个流程其实是标准的传统交换芯片的处理流程（里面的QoS就是ACL表），所谓的多级流表就是用图中的这些表来组合起来的。

 

相对于其他各种临时方案，笔者更倾向于这种NDM方案，因为它不需要等待新的芯片研发，可以快速做出产品，成本跟普通交换机等同，而且关键是能满足现在很多应用的需求（这也是TTP被提出的主要目的）。从现在的SDN部署情况来看，更多的部署是为了利用SDN架构的管理方便性、简单性、控制和转发分离，而不是利用OpenFlow的灵活性（当然也有，但是目前比较少）。笔者就碰到过不少这样的案例，后面“SDN应用案例分析”一章我们会就其中的典型案例做一下分析。

现在据说NDM转发面的方案已经确定，目前正在开发控制面的协议，包括OF-Config和OpenFlow，用来控制NDM流表的下发和能力协商。甚至这种方案有可能成为OpenFlow 2.0。但是也有人对这种方案不感兴趣，他们想要的就是一个彻底的OpenFlow方案。

• ONF心目中的理想方案

ONF心目中的理想转发面方案是什么？简单一句话，就是能够支持所有OpenFlow标准的商业ASIC芯片。这里有两个条件，第一是要能支持所有OpenFlow标准，第二必须是ASIC芯片，不能是NP或者FPGA。但问题在于，根据前面的分析，商业芯片厂商对这个事情并不积极，那谁来推动呢？别担心，有人来推动。NetLogic公司的技术专家跟几个美国高校的研究人员联合写了一个论文叫“PLUG: Flexible Lookup Modules for Rapid Deployment of New Protocols in High-speed Routers”，试图使用SRAM来解决灵活的多级流表的问题。而影响力更大的则是另外Nick McKeown教授等人写的一篇论文，他早在2013年的ONS大会上就提出，灵活可编程的、能够满足OpenFlow要求的ASIC芯片完全是可行的，而且只需要比现有ASIC多一点点的代价就能实现。当时很多人听了以为他信口开河，没想到很快他就联合TI（德州仪器）公司的人写了一个论文，发表在SigComm，该论文的标题是“Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN”。在该论文中，他们提出了一种全新的交换芯片设计思路，他们认为这是最符合OpenFlow思想的芯片设计，而且是完全可行的。

在理解他的思路之前，我们先来看看传统芯片的设计思路。在传统交换芯片中，有明确的协议的概念，比如一个芯片支持很多种功能，包括Mac转发、路由转发、MPLS转发、ACL过滤和转发、Tunnel封装/解封装等很多很多具体的协议功能。每种协议处理在交换芯片中都有自己特定的处理流程，换句话说，芯片中有些模块代码是专门为Mac转发服务的，有些是专门为路由转发服务的，有些是专门为MPLS转发服务的，等等。每个协议功能也都有自己特定的表项，使用特定的查找Key和查找算法，执行特定的动作。而且在报文刚进入芯片的时候，就会根据具体的协议所对应的报文格式把报文的所有字段都解析出来，不认识的协议就无法解析。换句话说，在传统芯片中，所有的处理和表项都是协议相关的，某个协议用哪个表，用什么查找算法，用什么逻辑代码，报文长什么样子，都是在设计的时候就确定了的。如下图所示，每个处理阶段都是在处理特定的协议功能，访问特定的表项。

 

传统交换芯片的这个架构无法完全满足OpenFlow的需求，因为这种架构就OpenFlow的应用而言，存在以下缺陷：

第一，它只能识别解析芯片设计的时候就已经定义好的报文类型，如果出现新的报文类型它无法解析。

第二，它只能匹配特定的报文字段，比如路由表只能匹配目的IP，Mac表只能匹配Mac+Vlan，ACL表虽然可以匹配比较复杂的字段组合，但是通常也不支持所有组合而且表项很小。

第三，它只能对特定的报文执行特定的动作，比如做路由查找的报文，执行的动作只能是把TTL减一，换掉二层头，修改DSCP。而无法执行别的动作，比如替换目的IP或者源IP。

正因为传统芯片的这种固定模式的报文处理方式，使得它并不具有可编程性，不适合OpenFlow的处理。所以Nick Mckeown等人提出了一种新的芯片架构，引入灵活性。

他们的思路主要体现在四个方面的灵活性上，即灵活可编程的报文解析、灵活可编程的报文匹配查找、灵活可编程的报文编辑动作、灵活可编程的Memory分配。下图是该论文中所阐述的理想中的芯片流程图。

在这个新的架构中，我们可以看到跟传统交换芯片最大的不同在于，整个处理流程中没有任何跟具体的协议相关的处理，只有很中性的Match Stage，入方向（Ingress Processing）和出方向各有32个，对应到OpenFlow里面，这就是所谓的多级流表。

报文进到芯片之中，首先是进行解析。传统的芯片通常是用硬编码（hard code）的方式来把所有已知的报文解析出来，简单明了，但是如果有新的协议报文，它就无能为力了，只能再重新开发一颗芯片。而在这个模型中，并不使用硬编码，而是查表的方式，从报文L2/L3/L4（即2层/3层/4层）的Type位置取到相应的Type（类型），然后用这个Type去查表，表里面的内容是用户可配的，里面的每条表项都存放了一个特定的Type、它所对应的L2/L3/L4甚至L7的header length以及需要匹配的字段的偏移和长度。通过这种方式，即使有了新的协议，用户也可以通过编程的方式，往这个解析表里面加一条新的报文类型，足以让芯片把这种报文给解析出来。

这个模型最核心的部分还是后面的多级流表的处理，在每一级流表里面，就像OpenFlow标准所定义的那样，它不再区分是要做路由查找还是二层Mac查找或者MPLS/Trill/Fcoe/PBB/Nat查找，在它看来，它只关心要用报文中的哪些字段组合去做匹配查找，查找完之后出什么样的动作，而且一级流表处理后的部分结果可以作为下一级流表处理的输入参数，所有这一切都是中性的、协议无关的。传统交换芯片中的ACL表也勉强可以做到对任何字段组合进行匹配查找，那是因为它用的是TCAM，可以支持掩码，所以能掩掉任意不关心的字段。但是我们前面说过TCAM成本很高，无法作为大容量流表的解决方案。他们的这个论文里面提出使用SRAM，使用SRAM就意味着是使用Hash算法，Hash怎样做到对任意的字段组合进行匹配呢？这是他们这个方案的关键点所在，他们提出，在每一级流表的查找结果里面都包含一个信息，这个信息是告诉下一个流表（第一级流表所需要的这个信息通过端口上的配置给出），用什么字段组合来进行Hash查找。这样就可以用大量的SRAM来做，同时为了灵活性，每一级流表都还会在下面放一块TCAM，万一SRAM查不到，可以用TCAM来做默认的查找。另外，每一级流表都可以出任意的动作，包括报文编辑和转发，其中报文编辑可以针对每一个字段做独立的处理。

从以上描述可以看出，在这个架构里面，解析什么样的报文是可编程的，每级流表用什么字段来做查找，查找后执行的动作都是可编程的。另外，入方向处理和出方向处理每个最多都可以有32级流表，但并不是说永远固定为32个，如果不需要这么多，也可以将多个流表的Memory合并成一个，这就意味着流表数量以及每张流表的大小也都是灵活可编程的。同时由于每个流表所用的查找字段是可变的，所以这也意味着每个流表的表项宽度也是可变的。总之一句话，一切都是可编程的。

应该说，这个方案有很多闪光点，比如灵活的报文解析，动态指定参与查找的字段以方便使用SRAM来代替TCAM，以及出任意灵活的编辑动作。

但是，这个方案也有明显的硬伤，理想化色彩过浓，我们来分析一下。

第一，这个方案宣称要使用370M SRAM bits和40M TCAM bits，很多人不清楚这是个什么概念，简单地说，目前Broadcom公司容量最高的960GB包处理芯片Trident2，SRAM/DRAM估计仅是它的1/3（只是大概的估计数字，未必准确），而TCAM估计是它的1/8，我们可以想象的到这是一颗什么样的巨无霸芯片。当然，表项规格可以降低，但是这样就离他们宣称的大流表的规格相去甚远。

第二，如果要支持任意字段组合进行Hash查找，对芯片实现来说，代价非常高。不考虑内部逻辑，光想想流表的宽度就很恐怖。当然，也许设计者的本意并不是想同时用所有字段，而是希望能够从所有这些字段中选取一定数量的组合。这涉及另外一个问题，需要一个近乎天文数字的排列组合，对芯片来说是不可能做到的。所以就算要去实现这种架构，也必须是要进行折中。

第三，芯片中如果真的有前后各32级处理流水，处理延时会非常长，对数据中心来说，这是一个很大的不利因素，因为数据中心很多应用场景都需要低延时。

第四，它无法解决OpenFlow标准固有的缺陷，即前面讲的，有些不依赖于Match-Action模式的传统芯片功能它支持不了（比如需要状态机、定时器等机制的功能）。而且就算不考虑这些无法支持的功能，要用这样的芯片去实现一个传统交换机，配置难度也是很大的，需要很复杂的软件管理的工作。

正因为如此，所以这个方案并没有得到传统交换芯片厂商的认可，虽然TI（德州仪器，半导体公司）公司的人也参与了这个论文的撰写，但是TI毕竟不是做交换芯片的厂商。笔者也非常熟悉芯片设计，客观地来看，笔者认为这个方案过于理想化，Nick虽然以前参与过芯片设计，但是做的是Fabric（交换网）芯片，不是包处理芯片，两者的侧重点、复杂度都完全不同。但是，笔者并不否认这个方案里面的一些闪光点，实际上，里面的一些想法并不新鲜，有的芯片厂商，比如盛科网络在之前就已经实现了其中的部分，包括动态memory映射、相对灵活的报文解析、上级流表指定下一级的查找方式、比较灵活的动作组合等，只是灵活度没这个论文那么高而已，采取了折中的方案。

OpenFlow非技术面的阻力

任何一项新技术在发展之初，都会面临技术面和非技术面的双重阻力，OpenFlow也不例外。技术面的问题前面已经讲过了，现在我们再来看看OpenFlow在非技术面碰到的阻力。

非技术面的阻力大都跟利益相关，有一个技术阵营对另外一个技术阵营的利益冲突，也有个体利益对公共利益的冲突，OpenFlow在这两方面都兼而有之，而且对OpenFlow而言，这两种利益冲突本质上是一种。OpenFlow控制器和OpenFlow交换机一旦发展起来，损害的首先是传统设备商的利益，因为这种架构降低了技术竞争的门槛，网络设备行业面临重新洗牌的可能，更主要的是，OpenFlow标准的定义权不在设备商手里，所以设备商，特别是市场份额极高的设备商肯定是会想办法把OpenFlow边缘化。

OpenFlow要求控制和转发分离，且要开放控制面和转发面之间的接口。接口的标准化对传统设备商的影响还不是最大的，影响最大的是接口的开放。因为一旦接口开放，就意味着用户可以不用再为上层软件付钱了（除非要使用功能复杂的商业软件），只要你开放了接口，我就可以自己编程来控制你的硬件，甚至用你的硬件用得不爽，我就再去找能满足我的需求的别的硬件（只要考察其他硬件的转发能力、表项大小、端口形态和提供的编程接口就行了），在未来应用为王的网络时代，这就意味着放弃了很大一部分权利。

读史可以知今，运营商在下一代网络（NGN）引入控制和承载分离的架构，但是我们看到没有一个领先厂家愿意开放媒体网关的控制接口，基本上也看不到任何商用的开放接口组网案例。所以我们可以想象的到，让领先的厂商开放自己转发设备的所有编程接口会有多难，你能想像Cisco向所有用户开放Nexus 7000的控制和转发面之间的编程接口吗？这一切都是阻力，但是不会那么明目张胆，而是会变换一些形式出现，使用干扰战术，不断推出新技术、新概念去吸引眼球。

Hybrid交换机

Hybrid是混合的意思，所谓的混合交换机就是说一个交换机兼有传统二三层功能和OpenFlow功能，传统二三层功能由安装在交换机里面的协议软件控制和管理，而OpenFlow的功能则由远程的Controller进行控制管理。使用Hybrid交换机是为了进行平滑过渡，给用户更多的选择自由，用一个英文短语说是“ship in the night”。

一个报文进到交换机里面，如何决定是走OpenFlow处理流程还是传统处理流程呢？这没有什么标准，但是一般也不外乎这么几种：

• 根据端口进行区分，有的端口做传统处理，有的端口做OpenFlow处理。这是最常见的，处理起来也是很简单的，从应用的角度看也比较合理。
• 根据Vlan进行区分，有的Vlan做传统处理，有的Vlan做OpenFlow处理。这种也有人做，但是不常见，笔者认为这种方案不太合适。
• 报文进来先进行一级流表的处理，根据这一级流表处理的结果决定后面继续下一级流表处理还是转而去做传统二三层处理。应该说这种最灵活，而且它可以是前面两种的超集，但是这种比前面两种复杂，而且对芯片有要求，芯片的处理流程必须先做流处理，再做路由/Mac/Mpls处理，而且前面的处理结果必须能够影响后面的结果。在后面的应用案例一章我们可以看到一个真实应用案例。

现在市场上大多数所谓OpenFlow交换机都是Hybrid的，相当于在原有的交换机基础上加了一个OpenFlow功能，但是限于现有的芯片，大多数Hybrid交换机限制都很多，笔者接触到的客户大都抱怨过。华为的敏捷交换机S12700可以算是一个成熟的Hybrid交换机，它的做法是在有些线卡上不支持OpenFlow，有些线卡上支持OpenFlow。