再思考SDN

ONF成立两年之际，SDN开始得到业界的广泛认同，尤其是从IT真正走入了CT，而CT的网络类型五花八门，这使得SDN的应用场景急剧增长，大有无所不能之势。

业界目前所推的SDN无非两种，方式一是原生的斯坦福/ONF推崇的OpenFlow完全控制的网络架构，方式二是部分厂商推出的设备可编程的架构，两者的核心区别在于后者设备的本地控制面仍然要运行传统的协议，可编程是附加的能力，当应用崩溃后，原有设备/网络仍然可以继续正常运行。这一架构的优点看起来很明显，避免了控制面本身故障的问题，但是问题也同样明显，首先设备本身的复杂度实际上是增加了，门槛继续加高，不利于新兴的设备厂商的参与;其次既然部分由传统控制面控制，部分由应用程序控制就需要额外的控制仲裁规则，比如基于OpenFlow Hybrid模式下端口的划分、路由器RIB的合成规则或者增加额外的流分类器等等，这使得可编程性受到限制，客户未必能够操纵所有的转发面状态，使得其实际上更适合于特定的应用优化;

而方式二其优点是转发面可以彻底简单化，受控转发，在全局的控制面控制下可以做到完全自动化部署、配置和维护，缺点也有很多：1)目前的硬件不能很好地支持OF1.1+的抽象模型，只能由控制面适配ASIC本身的能力，业务支持受限于特定硬件，所以Nicira选择在vSwitch上支持OpenFlow。2)集中控制面的问题，控制面本身的可靠性可以通过分布式技术解决，主要是控制平面本身的时延、可靠性问题，时延随距离增加线性增加，而可靠性则下降更为迅速，关键设备必须要通过双网双平面的方式保证，这使得控制本身的成本大大增加。我们有理由相信Pure OpenFlow的方式更适合于地理上相对较近的网络，比如企业网、数据中心和运营商接入网络。地理跨度更大的网络往往用基于网管接口的方式更加合适。

我们再考察转发设备芯片，目前速度最快的ASIC到NP、FPGA、多核以及纯软转发的x86均有，其处理单元组织可以分为Pipeline和SMP/NUMA两种形式，pipeline结构分工明确、可以按Pipeline环节的功能设计进行优化，同样的芯片面积可以做到更高的转发速度，问题是需要分解转发逻辑到相应的流水线上，灵活度受限;SMP方式编程简单、灵活，但开销稍高。说到底，灵活和成本是互换的。对于Switch ASIC这样的流水线长度、键值类型和操作都固化特定的芯片而言，控制面很难统一控制不同的设备，比如说我按业务分解到查目的MAC表打上MPLS标签，但是ASIC MAC表只支持打VLAN标签，那么就玩不转了。比较理想的模式是转发面Match和Action最好都是可以由控制面定义的，比如在数据中心中，主要是端口分类表、MAC转发表、L3交换表和L3前缀表，那么我就初始化成4个Flowtable，三个HASH的，一个BST或TCAM的即可(此处为说明简化成4张表)，那么在运营商网络可能需要增加MPLS、IPv6等表，而这些表对Action的支持是均质的，那么控制器软件就不需要分别和多家多种设备做两两互通测试，真正做到产业链的开放。在这种芯片结构下，大的TCAM不是必须的，除非应用要求进行大量通配表查找，比如大量包含通配的流调度。Nick Mckeown ONS 2013上演讲所提的芯片就是此种类型，其声称增加芯片面积、功耗不到15%,如果属实，那么其一旦商用，将对产业产生真正的颠覆作用，所谓SDN将转发设备简化、开放化的愿景主要依赖于此种芯片。

其实可编程和可配置之间的界限是比较模糊的，如果采用NetFlow统计流量，用NetConf、命令行下配置策略实现流量工程到底是叫配置还是编程?我个人认为这一点区别并不重要，关键是转发面正常运行是否依赖于外部实体的实时响应，如果是，则外部实体(控制面)的可靠性就是和设备处于同一标准，可以称之为控制面，否则就是网管。在完全控制和部分可编程之间也不存在绝对的界限，比如可以将传统控制面路由协议全部关闭，外部由应用控制RIB，当然这和pure OpenFlow方案相比多花了一些冤枉钱。