1、OpenFlow控制面的挑战
2、OpenFlow转发面的挑战
3、芯片厂商的犹豫
一、OpenFlow控制面的挑战
OpenFlow在控制面存在以下不足：
1、master和slavecontroller的选举机制不够成熟，没有标准来定义
2、controller的集中式控制，理论上肯定有扩展性问题，可是采取分布式控制又与SDN的原则有冲突，怎么把握这个平衡？
3、流表配置的速度比较慢，特别是网络大的时候，有严重的性能问题
4、现有的OpenFlow接口，很有很多配置无法完成，需要很多私有扩展，这会导致不兼容性
5、安全性还不能得到充分保证
6、传统的所有控制面协议都在每一台设备里面，现在集中到了controller上，这是否合理？是不是有些东西还应该保留在交换机上？Google进行了OpenFlow实战之后，总结提出哪些东西放在交换机？哪些交换机放在controller上，这是一个问题
控制面的挑战更多在于网络健壮性，稳定性，可扩展性，安全性，也就是说实验网络或者小型网络商用没问题，但是在大中型网络中，控制面的问题就会变得突出，就像在实验环境中，大多数问题出在功能上，而到了实际中，控制管理面的问题就暴露而出。
OpenFlow技术要想成熟稳定，必须经过大量的实践检验，ONF需要尽最大可能去避免OpenFlow走入一个标准不成熟——缺少商业案例——无从反馈——标准仍然不成熟的恶性循环。
二、OpenFlow转发面的挑战
OpenFlow控制面的问题确实存在，但是是可以改进的，毕竟是软件的工作，但是转发面的挑战就不同了，需要依赖于交换芯片，商业交换芯片研发周期长，技术门槛高，OpenFlow对转发面的要求与商业交换芯片的架构相去甚远，所以转发面面临的挑战主要在以下方面：
1、按照OpenFlow标准,一张流表可以使用任意的字段组合(比如MacDa,
MacSa, EtherType, Vlan, Cos, CFI, Protocol, Ipda, Ipsa, L4 Dest Port,
L4 Source Port, Dscp等)去做查表,在当前的商业芯片设计中,这意味着必须使用TCAM表来做,因为只有TCAM才支持掩掉任何想掩掉的查找字段。但是TCAM是一种昂贵的资源,具体表现在占用芯片面积大(一条TCAM表项相当于五六条DRAM"表项)和功耗大,而占用芯片面积大直接导致芯片成本高以及整机电路板设计成本高,功耗大导致整机散热成本和能耗成本上升。
2、OpenFlow提出了多级流表的概念,而且没有限制有多少级,这对芯片设计也很难受，传统的芯片肯定是没有多级流表的概念的，如果要设计多级流表，需要对架构进行大改，特别是OpenFlow要求每级流表出自己的编辑动作，编辑动作的结果作为下一级流表的输入去参与下一级流表的查找，这完全颠覆了传统芯片的设计，
3、在传统芯片设计中,所有的行为都是协议相关的。特定的协议有自己特定的处理模式和处理过程,某个协议处理过程中要编辑什么字段,做什么动作都是确定的,比如路由处理过程中,会去替换一层头,会去减TTL.可能会去修改DSCP,但是不会去改IP地址(如果改了IP地址,那是NAT的行为,不是普通路由的行为)。再比如普通二层转发,可能会去修改vlantag,但是绝对不会去修改IP地址,也不会去修改Mac地址。而OpenFlow的要求则不一样,按照OpenFlow的报文处理流程,都是协议无关的,也就是说,报文在OpenFlow交换机中被转发的时候,没有路由、Bridge或者MPLS的概念,没有Nat的概念,没有Trill的概念,没有PBB的概念,它有的只是一个很中性的、很通用的Match-Action的概念,即匹配到什么字段,去执行什么动作。传统的交换芯片里面,除了ACL,是不会有这种协议无关的处理的, ACL显然看起来是比较中性的、但是它的动作心般也都是固定的几种,比如重定向，限速等，远比OpenFlow要求的动作少得多，OpenFlow要求可以任意修改报文的每个字段，将报文送到任意目的地。
4、OpenFlow定义的行为只是传统芯片的一个子集，OpenFlow只定义了跟流相关的处理，比如如何来识别，识别之后如何编辑和发送或者丢弃，但是没有定义任何跟状态和时间相关的东西，而传统芯片处理则比OpenFlow要复杂得多。
5、OpenFlow在转发面最大的问题是：现在商业的ASIC芯片，对OpenFlow的支持都很有限，包括一些技术理论上可以做到的动作，毕竟初始时候没有料想到SDN的出现，现有的芯片在流表规格支持上也都是几KB级别的，远远不能满足大规模部署的要求。
6、SDN并不仅仅用来控制交换机，它的范围很广，从交换机，到路由器，防火墙，无线设备，传输设备等，但是OpenFlow开始定义的转发行为主要适用于交换机和路由器，如果要做到在不同设备之间通用，差得还很远。
三、芯片厂商的犹豫
既然OpenFlow这么火，市场上又没有专门支持OpenFlow芯片的，为什么厂商不赶紧做出来，难道不会抢占市场吗？其实厂商有自己的顾虑，理解厂商为何会迟迟不去开发OpenFlow芯片：
总而言之，想看到OpenFlow专用芯片的不是用户，不是设备商，也不是芯片厂商，而是极力鼓吹OpenFlow的ONF组织。
1、NPU和FPGA方案
2、TTP/NDM方案
3、ONF心目中的理想方案
4、芯片厂商的折中方案
一、NPU和FPGA方案
OpenFlow强调转发面的可编程，所以人们想到的就是使用FPGA现场可编程门阵列或者NPU网络处理器来做，与ASCI芯片不同，它们都是可编程的物理器件，但是在成本还是容量上都不如专业的ASCI交换芯片，在OpenFlow领域，这两者只能用作补充，以及用来验证技术可行性。
据说NEC的OpenFlow交换机，采用了ASIC芯片加FPGA协助处理的方式，号称支持绝大部分OpenFlow的功能，但是价格不菲，无法大面积推广。
华为公司在2013年8月推出了一款新的号称敏捷的交换机S12700，这款交换机最大的亮点就是使用了华为自研的ENP的NPU芯片。这个ENP在交换容量上跟现在的ASCI还用较大差距，功耗接近，价格成本价接近商业芯片的市场价格。
使用NPU或者FPGA来做OpenFlow，除了成本与功耗问题，还用一个实在的问题，芯片可编程并不代表交换机可以编程。怎么理解？ASIC一旦做出来，就无法再更改了，而NPU做出之后，如果设备商觉得还需要支持新功能或者修改一些bug，可以根据情况再出一版，这是与ASIC的区别。
但是对于交换机用户而言，用ASIC还是用NPU做都是一样的，用户都是只能在设备商提供的接口上编程，并不会因为芯片，就可以随意更改转发行为，因为系统用户没有办法去改NPU。
一个OpenFlow交换机要想真正拥有灵活可编程能力，必须要所用的ASIC芯片或者NPU芯片的架构是灵活的，不需要设备商提供芯片进行升级就能够通过软件来进行重新编程。
二、TTP/NDM方案
ONF很清楚OpenFlow在转发面的缺陷会成为其发展的重大障碍，所以成立了一个FAWG forwarding abstraction work group转发抽象工作组来进行转发面的抽象化工作。目的是希望能够帮助提炼一些OpenFlow芯片所需要的共性的东西，帮助厂商找到一个可行的方案，或者找一个临时过渡方案来加速SDN的发展。
在2012年提出TTP方案，table typing patterns，是利用现有芯片的处理逻辑和表项来组合出OpenFlow想达到的部分功能。在2013年，改名为NDM negotiabable data-plane model，即可协商的数据转发面模型。NDM定义了一个框架，基于这个框架，允许厂商基于实际的应用需求和现有的芯片架构来定义不同的转发模型。每种模型涉及多张表，匹配不同的字段，基于查找结果执行不同的动作，由于是基于现有的芯片，所以匹配字段还是执行动作都是有限制的。
在NDM中，controller必须知道交换机的能力，支持哪些NDM模型，就需要controller和交换机之间能够进行协商，而为了让整个过程自动化，还必须使用一种标准的描述语言来对具体的模型的能力进行描述。FAWG工作组就扩展OF-Config协议来支持controller和交换机之间的协商。
按照OpenFlow的标准，每个flow表都需要能匹配任意的key组合，且能够执行任意的action，但在传统芯片中，只有ACL表，勉强满足要求，无法支持多级流表。在NDM方案中，尽量保持南向接口不变，但在内部实现的时候，不是都用ACL表，而是用了其他表项，比如路由表，Mac表，vlan表，port表，MPLS表等。设备商也正好认为NDM可行，原因在于，尽管OpenFlow的灵活要求NDM达不到，但是大多数实际应用不需要那么灵活，比如大多数二层转发应该还是基于Mac+vlan，三层大多数还是基于vrf+ipda/mask。
NDM与传统交换机的区别：NDM方案虽然用了传统表项，但是架构确是SDN架构，控制面与转发面分离，而且控制面和转发面的接口仍然是OpenFlow接口，也就是说，从外部表现看，这是一台OpenFlow交换机而已，并且还只是应用比较传统的情况下，对灵活性要求不高。
下图是某公司给出的NDM方案流程图：
NDM转发面的方案已经确定，正在开发控制面的协议，包括OF-Config和OpenFlow，用来控制NDM流表的下发和能力协商，甚至可能成为OpenFlow 2.0，但是也有人对这个方案不感兴趣，他们需要一个彻底的OpenFlow方案。
三、ONF心目中的理想方案
ONF心目中的理想转发面方案是能够支持所有OpenFlow标准的商业ASIC芯片；这里有两个条件,第一是要能支持所有OpenFlow标准,第二必须是ASIC芯片。
Nick McKeown教授早在2013年的ONS大会上提出，灵活可编程的，能够满足OpenFlow要求的ASIC芯片完全是可行的，而且只需要比现有ASIC多一点点的代价就可以实现，提出新的交换芯片设计思路，他们认为这是最符合OpenFlow思想的芯片设计，而且是完全可行的。
在理解他的思路之前，先了解传统芯片的设计思路，在传统交换芯片中，有明确的协议的概念，比如一个芯片支持很多功能，包括Mac转发，路由转发，MPLS转发，ACL过滤和转发，tunnel封装/解封等很多具体的协议功能。每种协议处理在交换芯片中都有自己特定的处理流程。每个协议功能有自己特定的表项，使用特定的查找key和查找算法，执行特定的动作，而且在报文进入芯片的时候，就会根据具体的协议所对应的报文格式把所有报文字段都解析出来，不认识的协议无法解析。换句话说，在传统芯片中，所有的处理和表项都是协议相关的，某个协议用什么表，用什么查找算法，报文长什么样子，都是在设计的时候就确定了。如图所示，每个处理阶段都是在处理特定的协议功能，访问特定的表项：
传统交换芯片的这个架构无法满足OpenFlow的需求，存在以下缺陷：
第一,它只能识别解析芯片设计的时候就已经定义好的报文类型,如果出现新的报文类型它无法解析；
第二,它只能匹配特定的报文字段,比如路由表只能匹配目的IP, Mac表只能匹配Mac+Vlan, ACL表虽然可以匹配比较复杂的字段组合,但是通常也不支持所有组合而且表项很小。
第三，它只能对特定的报文执行特定的动作，比如路由查找的报文，执行的动作只能是TTL减1，换掉二层头，修改DSCP，而无法执行别的动作，比如替换目的IP或者源IP。
而Nick McKeown提出一种新的芯片架构，的设计思路主要体现在四个方面的灵活性上，灵活可编程的报文解析，灵活可编程的报文匹配查找，灵活可编程的报文编辑动作，灵活可编程的memory分配，下图是他的论文中阐述的理想中的芯片流程图：
在这个架构中,跟传统交换芯片最大的不同在于,整个处理流程中没有任何跟具体的协议相关的处理,只有很中性的Match Stage,入方向(Ingress Processing)和出方向各有32个,对应到OpenFlow里面,这就是所谓的多级流表。
报文进到芯片之中,首先是进行解析,传统的芯片通常是用硬编码(hardcode)的方式来把所有已知的报文解析出来,简单明了,但是如果有新的协议报文，就无能为力了。只能重新开放芯片。而在这个模型中,并不使用硬编码,而是查表的方式,从报文L2.L3 L4 (即2层3层4层)的Type位置取到相应的Type (类型),然后用这个Type去查表,表里面的内容是用户可配的,里面的每条表项都存放了一个特定的Type、它所对应的L213/14甚至L7的header length以及需要匹配的字段的偏移和长度。通过这种方式,即使有了新的协议,用户也可以通过编程的方式,往这个解析表里面加一条新的报文类型,足以让芯片把这种报文给解析出来。
这个模型最核心的部分还是后面的多级流表的处理,在每一级流表里面,就像Openflow标准所定义的那样,它不再区分是要做路由查找还是二层Mac查找或者MPLS//PBB/Nat查找,在它看来,它只关心要用报文中的哪些字段组合去做匹配查找,查找完之后出什么样的动作,而且一级流表处理后的部分结果可以作为下一级流表处理的输入参数,所有这一切都是中性的、协议无关的。
传统交换芯片中的ACL表也勉强可以做到对任何字段组合进行匹配查找,那是因为它用的是TCAM,可以支持掩码,所以能掩掉任意不关心的字段。但是我们前面说过TCAM成本很高,无法作为大容量流表的解决方案。他们的这个论文里面提出使用SRAM,使用SRAM就意味着是使用Hash算法, Hash怎样做到对任意的字段组合进行匹配呢?这是他们这个方案的关键点所在,他们提出,在每一级流表的查找结果里面都包含一个信息,这个信息是告诉下一个流表(第一级流表所需要的这个信息通过端口上的配置给出),用什么字段组合来进行Hash查找。这样就可以用大量的SRAM来做,同时为了灵活性,每一级流表都还会在下面放一块TCAM,万一SRAM查不到,可以用TCAM来做默认的查找。另外每一级流表都可以出任意的动作,包括报文编辑和转发,其中报文编辑可以针对每一个字段做独立的处理。
综上所述，在这个新的架构里面，解析什么样的报文都是可编程的，每级流表用什么字段进行查找，查找后执行的什么动作都是可编程的。同时，流表数量以及每张流表的大小也都是灵活可编程的，并不是固定为32个，因因为每个流表所用的查找字段是可变的，所用意味着每个流表的表项宽度也是可变的，总之，一切都是可编程的。
但是这个方案有明显的硬伤，理想化色彩过浓：
第一，成本过高，宣称使用370 M SRAM bits和40M TCAM bits，即便是broadcom公司容量最高的96.G包处理芯片，SRAM/DRAM估计也仅仅是它的1/3，而TCAM估计是1/8；
第二，支持任意字段组合进行hash查找，对芯片来说，代价非常高；
第三，芯片如果真得前后各32级处理流水，处理延时会非常长，对数据中心来说，这是一个很大的不利因素；
第四，无法解决OpenFlow标准固有的缺陷，有些不依赖match-action模式的传统芯片功能支持不了
也正因为如此，这个方案没有得到传统交换芯片厂商的认可。
四、芯片厂商的折中方案
ONF为了推动OpenFlow在转发面的进展，成立了一个CAB chipmaker advisory board，芯片制造商顾问委员会组织，希望这个组织能够一起设计一颗OpenFlow芯片或者至少给出建设性来指导芯片的设计。从趋势上看，倾向于基于现有芯片架构进行适度改动，并不认可纯OpenFlow的方案。
要在兼顾现有所有交换功能的基础上融入OpenFlow的元素,里面的很多想法其实跟Nick他们的论文不谋而合、强调可编程、表项可以灵活配置、支持有限度的多级流表,流表的匹配字段有限度的灵活可配(支持需用字段)、报文编辑和转发动作灵活可配,报文解析也在支持现有协议的基础上允许灵活可配。依靠这样一颗芯片,交换机厂商可以用它来做传统交换机,也可以用它来做OpenFlow交换机,还可以用它来做Hybrid (混合)交换机. OpenFlow的灵活性比Nick他们建议的方式稍有不足,但是其实已经可以满足绝大部分的实际应用需求了,因为在实际的应用中,其实不需要匹配所有字段组合，也不需要对所有字段进行编辑，有的字段是不会去改的，比如IP的协议号。
下图是芯片的SDN处理架构图：
实际上是不需要将传统芯片架构推翻了重来，只需要适当做一些创新，就可以满足绝大多数SDN的要求，SDN重在应用，而不是是否支持所有OpenFlow标准。
