《云数据中心网络与SDN：技术架构与实现》——2.2　转控分离——白盒的曙光

2.2　转控分离——白盒的曙光

早在2003年，IETF就提出了一种名为ForCES的框架，将转发元件与控制元件分离，然后通过标准的接口实现控制，旨在加速转发平面和控制平面的创新。ForCES中，转发元件被称为FE，控制元件被称为CE，CE通过ForCES协议来控制FE的转发。CE和FE间在物理位置上没有必然的联系，可以位于一个机箱里通过背板互联，也可以通过以太网或者IP进行远端的互联。一个FE可以同时连接多个CE以实现主备或者负载均衡，CE和FE间的对应关系由CE-Manager和FE-Manager进行协商。ForCES框架下的工作流程分为Pre-association和Post-association两个阶段。Pre-association阶段中，首先CE-Manager和FE-Manager间会交换CE、FE的列表，然后CE-Manager告诉CE与之关联的FE的信息，FE-Manager告诉FE与之关联的CE的信息。Post-association阶段中，首先在CE和FE间进行认证、握手、能力协商和初始化配置，然后ForCES协议的通道就建立起来了。通道上的信令主要包括FE向CE发送不知道如何处理的数据报文、FE向CE转发入向的控制报文、CE向FE发送转发表、CE向FE发送出向控制报文、CE向FE请求一些统计数据等。ForCES协议只规范Post-association阶段的交互，Pre-association阶段的交互则不在ForCES协议的范围内。

可以看到，ForCES协议和OpenFlow在基本设计思路上是完全一致的。不过ForCES并没有像OpenFlow一样火起来，为什么？一方面，时机不够成熟，当时通信领域如日中天，OTT们还没有与设备厂商们掰手腕的想法，ForCES想法虽好但太过于超前了。另一方面，找错了切入点，ForCES的倡导者大多来自于高校和Intel，然而面向的却是IP设备，厂商在IP这块有绝对的话语权，当然不会放任ForCES胡来。厂商们为什么抵制ForCES？因为ForCES从根上动摇了厂商的利益。

网络设备这一块，从主板、交换芯片这些硬件到操作系统、协议实现这些软件，向来都是各路厂商自成体系，从硬件到软件一并都做了。这个模式有什么问题吗？试想如果WinTel不是两个公司的联盟，而是一家公司的话，PC肯定做不到今天这样普及，如果浏览器、游戏、即时通信等软件都被——操作系统套牢，PC上的应用也不可能像今天一样丰富。

很遗憾，网络设备这一块并没有形成WinTel的格局。软硬件的一体化，意味着用户不仅不清楚各个环节的成本，很多时候还要在买回盒子以后为软件的授权（License）另外付费。对于软件本身，用户也不知道它的实现细节，想要加一些新的功能必须依赖于厂商来做定制化。严密的技术封锁压制了市场竞争，网络设备长期由几个巨头把控，他们在分享着庞大的市场需求的同时，还能够获得高昂的产品利润。这些优势都得益于控制与转发的紧密耦合，也就是说，并不是厂商不接受ForCES转控分离的概念，而是他们不愿意将转控分离进行开放。一旦开放式的分离，就意味着软硬件的进一步分工成为可能，产业链必然面临重构。

不过，任何行业的发展都无法摆脱精细化分工的必然趋势，ForCES搞错了时机与切入点，但是没过几年需求就出现了。2005年前后，Google、Amazon这些OTT巨头的业务开始迅速扩展，对于服务器、存储和网络这些基础设施要进行大规模的建设。这些互联网巨头和电信运营商不同，他们对新技术的态度是更为开放的。首先，他们的技术能力非常强，对厂商不存在什么依赖感，一贯的路数是所有东西都自己来做，如果服务器、存储都能自己来做，网络为什么不行呢？而且，相比于运营商骨干网上的IP设备，数据中心在新建时存量设备的压力也比较小。于是，他们开始着手自己研发数据中心的交换机。

Google摸索出来的思路可以概括为以下三点。

1）从商用芯片公司买芯片，交换机上的软件自己来做。

2）采用CLOS结构进行整体组网，从Scale-Up转向Scale-Out。

3）部分控制逻辑集中化，和计算、存储统一管理编排。

从Google的角度来看，上述思路的最终目的都脱离不开降低成本。

1）和芯片公司谈好合作，根据芯片公司提供的SDK自己来做操作系统和协议栈，不用再为盒子中很多不必要的功能买单。

2）Scale-Out的思路中不再围绕网络中的大盒子进行组网，将一个大盒子分解成多个小盒子，容量不够了就再加一台设备，设备坏掉了就用任何其他设备顶替掉，总体上可以大幅度降低CAPEX。

3）集中式控制可以增强自动化的能力，还可以提供更好的流量调度与可视化，虽然开发集中式控制有一定的前期研发成本，但从长期来看是可以降低OPEX的。

然而，从传统网络设备厂商的角度来看，上述都是对传统网络的巨大冲击，Google的设备上将没有任何厂商的色彩，成了“白盒”，这可绝对不是什么好的兆头。

AWS的思路没有对外公开，但是整体的思路和Google应该是类似的。如果说Google关上门研究“黑科技”，设备厂商们作为“外人”没什么可说的，那么AWS于2012年将10亿美元的大单给了独立的白盒厂家，而没有选择Cisco，这可是公开向市场释放了白盒商用的信号，白盒开始正式走入了人们的视野。可以说2012年就是白盒交换机的“元年”。

相比于Google和AWS，Facebook起步要晚一些，直到2010年才开始自建数据中心，但是FB马上在2011年就有了一个大动作——成立开放计算项目（Open Compute Project，OCP），旨在开源数据中心所有的软硬件设计，想去掉所有传统的服务器和存储厂商，网络厂商自然也“不能幸免”。OCP可谓一鸣惊人，ATT、Verizon、微软、Rackspace、高盛这些体量的用户陆续加入。“白盒”也终于找到了组织，Intel、Broadcom、Mellanox这些商用芯片厂家开始开放芯片的SDK，Cumulus、BigSwitch、Pica8开始推广白盒的软件，Quanta、Accton这些ODM厂商开始跟进白盒的硬件集成与组装。Cisco和Juniper抵挡不过潮流，也在2015年初加入了OCP。随着Google于2016年加入OCP，OCP的影响力已经越来越大。不过AWS目前还没有动静，听闻他们甚至打算开始自己做芯片了，看来技术上的领先优势仍然是比较大的。

既然是分工，那么原来一家通吃的活就要分给不同的人家去做。分工后是什么样子呢？主要拆解成了4个部分，从下向上依次是芯片、机箱、操作系统以及控制与管理软件，如图2-1所示。下面分别从这4个部分对转控分离目前的进展进行具体的介绍。

图2-1　白盒的技术堆栈

2.2.1　芯片级开放

1. OpenNSL与OF-DPA

ASIC主要来讲讲Broadcom。Broadcom在SDN方向上主要供应的是Trident和Tomhawk两款ASIC，为OpenFlow和Overlay专门做了一些设计上的优化，目前大部分的白盒都是基于这两款芯片在做。ASIC的软件接口方面，Broadcom实际上与很多高校和OTT都有合作，允许他们通过Broadcom的SDK来进行开发，只不过要签NDA（NonDisclosure Agreement）。OCP来了之后，Broadcom把SDK进行了二次包装，然后开源出来贡献给了OCP，面向传统的L2/L3协议栈的API叫作OpenNSL，面向OpenFlow的API叫作OF-DPA。图2-2a是交换机本地的应用程序通过调用OpenNSL API来控制芯片的行为，图2-2b是通过JSON-RPC在远端调用OpenNSL API。图2-3是OpenFlow Agent收到远端控制器的OpenFlow消息后，在交换机本地转化成OF-DPA API来控制芯片的行为。

图2-2　交换机本地的应用调用OpenNSL API以及远端通过JSON-RPC调用OpenNSL API

图2-3　OpenFlow到OF-DPA的转换

OF-DPA内部实际上用的还是OpenNSL的库，不过向上提供的API不一样罢了。OpenNSL和OF-DPA提供的接口分别如图2-4和图2-5所示。之所以把OpenNSL和OF-DPA的API列在下面，是想要告诉读者一件事情，就是白盒的能力最后还是受限于芯片提供的API的，并不是控制器让做什么盒子就能做什么。

2. SAI

除了Broadcom以外，ASIC这一领域的选手还有Intel、Melllanox以及Cavium，国内的盛科这几年也逐渐打响了名声。转发的应用为ASIC写Adaptor可不是一件容易的事，有这么多的ASIC厂家，应用如果每移植到一个新的ASIC上去就要重写一次Adaptor，效率就太低了，于是又有人想了一个法子，在各家ASIC的SDK（比如Broadcom的OpenNSL）之上再做一层统一的抽象，ASIC厂商需要根据这层抽象把自家的SDK适配进去，这样转发的应用就可以在不同的ASIC间进行无缝移植了，这就是微软提出的SAI（Switch Abstraction Interface）。

图2-4　Broadcom OpenNSL提供的API

图2-5　Broadcom OF-DPA提供的API

SAI的架构如图2-6所示，其中ASIC SDK被称为Adaptor，一个Adaptor会根据SAI将ASIC中不同的功能适配到不同的Adapter Host中，Adaptor Host可以看作对不同ASIC中特定功能的抽象。Adaptor Host的概念说起来比较抽象，具体一点来说，MAC转发和IP转发是两个不同的Adaptor Host，一个ASIC如果既支持L2又支持L3，那么其SDK就需要把L2功能和L3功能分别适配到MAC Adaptor Host和IP Adaptor Host中，而不同ASIC的L2功能都会适配到MAC Adaptor Host中（熟悉ONOS的读者应该比较容易理解，Adaptor Host和Subsystem是类似的作用）。虽然SAI目前还不是很成熟，但是它对于转控分离的意义十分重大，目前已经有很多ASIC厂商提供了对于SAI的支持。

图2-6　SAI对不同的ASIC SDK进行抽象