软硬件分离趋势及开放网络发展

1. 前言

一直以来，网络设备给人的感觉就一个或大或小的铁盒子，其貌不扬，让人猜不透里面到底是啥。而这种情况将有所改观，在OCP等开放组织、众多芯片商、ODM商、互联网用户的推动下，业界已经在逐步走向开放，在此基础上网络设备硬件设计也正朝着模块化、开放标准化的方向革新，软硬件分离也成为一种趋势。

事实上，围绕数据中心网络开放相关技术，最近也是动态动作频频：先有Dell联合Cumulus联合发布消息，支持软硬件分离的采购模式，用户可以只购买Dell裸硬件，然后通过ONIE安装Cumulus的网络OS；后有Facebook爆出即将开源其自研交换机硬件（Wedge）及软件源码（FBOSS）的消息，俨然一副要爆发的样子。

本文将综合分析一下最近一段时间内，在开放组织（OCP）以及数据中心网络行业领域方面的一些技术动态，并据此探讨一下数据中心开放网络可能的一些发展趋势。

2. OCP技术动态

OCP在13年中左右成立了Networking工作组，致力于构建开放标准化的数据中心网络相关技术。当前阶段还是主要聚焦在TOR上：首先是联合芯片及硬件厂商制定TOR硬件标准，并推出开放网络安装环境（ONIE），试图解除交换机软硬件绑定的黑盒状态，形成硬件标准化、软硬件分离的新模式；其次是试图构建一个开放标准的交换机ASIC抽象API编程接口，屏蔽硬件芯片及平台差异，并最终促成开源网络OS的诞生。

开放网络安装环境（ONIE）

网络设备软硬件绑定的黑盒状态是首先被OCP想到要解决的事情，因而ONIE（Open Network Install Environment）作为解耦软硬件的中间层，被迅速提出并付诸实现（由Cumulus主导）。如果与Server领域简单类比一下的话，ONIE相当于“BIOS + Loader (Grub)”，在设备首次部署时运行，用于安装部署完整OS。

• 设备厂商（硬件）出厂并不附带完整OS，而是仅安装了ONIE，用户可以在实际部署时自由选择安装所需的网络OS。当然这个网络OS是用户独立购买的商业OS，也可以是自行研发或基于开源系统集成的私有OS。

• OS安装完成后，设备启动后直接载入OS运行，ONIE不再运行。当然在需要时，仍然可以激活ONIE用于OS的升级、重装等安装部署操作。

ONIE当前相对来说已经比较成型了，包括Quanta、Celestica在内的多家ODM厂商都声称可以提供对ONIE的支持。该组件也被Cumulus所主推，搭配其Cumulus OS可以安装部署在Quanta、Dell等厂家的交换机硬件上。ONIE源码地址：https://github.com/opencomputeproject/onie。

OCP硬件标准

TOR硬件标准的制定工作，当前还处于接收草案阶段，有四家公司提交了TOR硬件标准草案，分别是：Broadcom、Intel、Mellanox、Accton。基于北美市场的现状，这些硬件标准提案全部是基于“10G SFP+、40G QSFP”端口模式的万兆TOR平台。

• Broadcom

BRCM提交的方案，交换部分基于Trident2芯片，CPU主板、端口子板均为模块化设计。即配备自家的MIPS处理器主板、也有基于X86的处理器主板，面板端口形态支持48x10GE+6x40GE、48x10GE+12x40GE多种模式。

• Intel

Intel提的方案比较厚道，该方案并未限定交换芯片，方案重点放在如何定义交换芯片子板、CPU子板以及电源等各组件之间的物理电气连接的方式，其组件化的思路是一致的，分为交换子板、CPU子板、电源组件、风扇组件等几大块。

• Mellanox

Mellanox的方案与Broadcom的方案基本类似，只不过将交换芯片换成了Mellanox的SwitchX-2芯片，CPU子板则采用了Intel的IVB处理器，提供更为强劲的控制面处理能力。

• Accton

Accton作为一家ODM供应商，就是将自家一款产品的硬件设计贡献出来而已，交换子板基于Trident2，CPU子板使用的是Freescale PowerPC处理器，俨然一个传统标准ODM产品的味道。

综上所述，从各家提供的标准设计草案看，都仅仅是将自家已有的产品设计贡献开源出来而已，虽然都大体上遵循了模块化组件化的思路，但是各组件之间的连接方式却是有很大差异，并未形成统一的标准构造。另一方面，从整体而已，硬件彻底标准化也未有必要，看起来只需将几大组件模块化，包括CPU控制子板、交换子板、电源风扇等，然后将它们之间的电气接口标准化定义即可满足行业需求。

开放API标准（Open Ethernet Switch Interface）

除了硬件标准化外，OCP另外一个尝试就是制定ASIC芯片的标准化API抽象编程接口：在厂家SDK与上层网络OS之间提供一个中间API界面，使得硬件编程界面抽象标准化。

此前Broadcom也提了一个方案，整体上仅仅是将其自家SDK API换了个名字，并且一一对应，一点诚意都没有，似乎没有得到大家认可。看起来，目前仅Mellanox提出一个API定义草案在讨论中，而且API定义还没有完全给出，仅定义了几个范例，更别说整个API组件的整体设计实现。

OCP技术动态小结

可以看出，就OCP本身在Networking上的进展来讲，到目前位置仅输出了一个解耦硬件与软件的中间层组件ONIE，硬件的标准化、ASIC抽象API界面等都还没有成型，也还没有一个大家都重度参与或者初步成型的开源软件系统出来。但是很明显的是，软硬件分离、网络开放标准化的趋势已经得到大家的一致认可。可能也正由于这种情况，Facebook决定开源其自研TOR的软硬件设计及关键代码，来加速OCP开放社区的发展。

3. 行业技术动态

相比于OCP开放社区本身的进展状态，大家私底下的动作要迅速和激进得多。

Cumulus、Dell、VMware

在年初的时候，Cumulus、Dell联合发布声明，将可以单独购买Dell的硬件，搭配Cumulus的Network OS系统软件，共同致力于推动网络设备走向Bear-Metal模式。首批支持该购买模式的设备型号是面向数据中心网络的TOR交换机：S6000、S4810。Cumulus其实之前介绍过，其OS基于Linux构建，修订Linux内核来支持网络交换功能，并通过增加SwitchD适配组件来衔接Linux内核软转发与ASIC芯片硬转发。而其管理控制面完全与Server的界面相同，号称能够全部复用Server领域大量的管理监控部署工具。另外一方面Cumulus、Dell都是VMware的合作伙伴，三者相互关系比较紧密，可以通过VMware’s NSX、Cumulus Network OS、Dell’s TOR硬件，提供一整套Underlay网络解决方案，通过Cumulus的系统架构图可以看出，支持VMware NSX是被其当作重要卖点突出的：

来看下Dell这两款硬件的情况：S6000是一款提供32x40G QSPF+端口盒式交换机，而S4810的面板端口形态48x10G SFP、4x40G QSFP，二者是典型的数据中心网络所需的端口规格。

单从Dell的角度来看，其作为传统网络设备的OEM厂商，其本身也有Force 10这样的私有网络OS，而仍然选择与Cumulus、VMware合作，支持网络设备这种软硬件分离的Bare-Metal模式，至少释放了一种信号：部分OEM厂商已经认为未来这种Bare-Metal已经成为一种趋势，或者说在网络开放及SDN热潮下有可能导致这种Bare-Metal模式成为主流。

Bigswitch

BigSwitch也没闲着，主导推出了另一个开源项目ONL（Open Network Linux），2014年1月17日正式启动，项目源码地址：http://github.com/opennetworklinux/ONL。但是该项目的目标有点偏，仅仅Focus在构建一个统一的嵌入式Linux系统，以便提供对多家ODM硬件平台的支撑，而网络协议功能部分并不在其考虑之列。如下图：

其实分析一下Bigswitch的产品，可以了解其意图。Bigswitch有一个SDN Fabric的东东，其中交换机上运行的OS称之为Switch Light OS，而开源的ONL就是该系统的一部分，如下图：

可以看出，Bigswitch目前考虑到的是，各家ODM硬件设计千差万别，各种驱动的适配还是挺花时间的，比如温度传感器、风扇、电源、CPLD控制器、各种I2C器件等，由于缺乏标准，都需要专门开发相应的驱动适配。而Bigswitch当前开源的ONL仅仅就是考虑这部分内容，针对各种外围器件的驱动适配构建了标准框架，方便各家ODM进行适配开发，但是并没有涉及到最关键的ASIC芯片的适配及其编程接口的标准化工作。很明显，Bigswitch就是希望通过开源的ONL，让各家ODM自己帮他完成底层硬件的适配工作，而他自己的什么BSN ASIC Driver+BSN Openflow Agent等组件，就可以无缝加载了。

目前除了Bigswitch及一些ODM厂商之外，其他人在ONL上的参与度都较低，目前发展前景还不太明朗。

Facebook

可能是有感于OCP的进展太慢，Facebook近期发布声明，将贡献其自研TOR的硬件设计及软件代码。从其公开的资料看，其自研TOR硬件内部代号为“Wedge”，而其软件系统则命名为“FBOSS”。在此之前，了解到的情况仅仅是Facebook有投入资源进行自研网络设备的设计研发，现在看来，其投入的资源还是挺大的，软硬件均自行设计研发（硬件生产应该是ODM代工）。

Facebook将开源其自研网络设备软硬件设计及代码的消息一经公布，立即引起业界大量关注，但Facebook并没有明确给出开源的具体时间表，以及其软件FBOSS具体开源程度，是全部系统代码开源，还是仅开源一部分关键代码？这些都还没有透露。当前只能通过Facebook公开的简短介绍性材料，来胡乱分析一下Facebook自研网络设备的设计研发思路，分享给大家先睹为快！

• 硬件（Wedge）

硬件设计总体上是模块化标准化的思路，整个硬件设备被分成几大块组件：BOX机箱、电源模块、风扇模块、交换芯片子板、CPU控制板。如下图：

其中机箱、电源、风扇这些，即使在传统商用网络设备上都已经是模块的组件，并且可热拔插，这部分没有啥新东西。关键点就在CPU子板和交换芯片子板两个组件的设计。

CPU子板方面，Facebook直接复用其Microserver的硬件板卡，其与交换芯片子板通过PCIE连接。整体上可以这样子认为：该设备在软件及系统管理上来看就一台标准的Microserver，通过PCIE插了一张附带强大交换引擎功能的板卡。事实上，该CPU子板也是OCP在Server领域定义的一个Microserver标准，Facebook也因此可以大量复用其Server领域的软件及系统运维资源，包括标准化Server Linux发行版、安装部署及自动化管控系统、以及包括温度、电源等基础架构监控信息在内的监控管理系统等等，很棒的一个设计！

交换子板方面，输出16x40G面板端口，从端口交换容量看，猜测可能是Broadcom的Trident+芯片（正好是640Gbps的交换容量）。至于为何是40G的面板端口，分析可能是三个方面考虑：A）首先全40G端口，上下联端口数量可以灵活分配，实现不同的收敛比，适配不同的网络架构环境及业务需求；B）下联服务器的端口，可以采用40G一分四的AOC光纤线缆连接10G服务器，此方案已经非常成熟，成本也较低；C）传闻Facebook已经开始搞40G服务器了，该TOR端口规格的形态可以兼容支持40G服务器接入。

• 软件（FBOSS）

相对于Wedge的硬件设计开源，其软件FBOSS代码的开源更值得我们关注。

从其公开的材料看，FBOSS明显地分成两个部分：一部分是完全复用其Server的软件系统，Linux OS以及一系列的软件库，包括部署、管理、监控，使得其整个基础架构体系的自动化管控自成一体；另外一部分是其网络功能组件，Facebook自行设计研发一个精简API抽象层（Thrift API Layer），作为芯片上SDK与上层网络协议中间界面。

此外，Facebook声称其实现的Hybrid模式的SDN集中控制，从公开材料看，其hybird模式应该是这样：自动化管控部署部分，借助于复用Server的软件资源，实现了整个基础架构运维界面的统一，并构建了集中的管控系统；而对于网络功能，仍然是传统的分布式网络协议把控（可能是BGP协议），主要思路还是自行构建一个ASIC抽象层API，然后在此基础上运行开源的网络协议套件（如Quanta等）。

初步分析可以看出，FBOSS核心主要是在于其复用Server的集中管控系统，以及Facebook自行研发的精简ASIC抽象API层，期待Facebook能够将这两部分核心代码开源。

4. 发展趋势分析

就目前的状况来看，无论是互联网业界（Facebook），还是网络设备OEM厂商（Dell），在网络开放方面都有出现一些新的突破性进展，显得网络开放的趋势愈发明显了。

软硬件分离（Bare-Metal）生态

种种迹象表明，网络设备软硬分离的模式已经来临，至少在数据中心TOR这个领域这个趋势已经非常明显了，人们将这种模式称为Bare-Metal模式。参考服务器领域，则早就是这样的状态了：

在服务器领域，无论是芯片、还是服务器硬件、软件、应用，都是相互分离的，用户在每个细分领域都有众多选择。比如在服务器硬件上，有Dell、HP等多家系统集成商可供选择；而OS方面则更是既有商用系统，也有开源系统，满足不同场景需求。在具体应用软件领域，基于这种开放的生态体系，商业、开源的应用组件则是百花齐放，生态体系繁荣多样。

对比到网络设备领域，有人进行了大胆的预测，将逐步呈现类似的生态体系，笔者表示认同：

当然上图列举的具体玩家仅是举例，有可能随着生态的发展，有些消失，也有些新的强者进入，但是总体生态分层体系架构是大体符合这个模型的。在这个体系模型下，有Quanta、Dell、Celestica这样的厂商提供高度标准化的硬件，软件OS领域则既有Cumulus这样的开放商用系统，也必然会出现完全Free的开源网络OS系统出现。

与X86标准化体系架构的结合

之前我们也探讨过，认为BOX交换机硬件的CPU控制板部分，有从PowerPC/MIPS等嵌入式处理器到X86架构处理器切换的趋势，从Facebook自研交换机的硬件设计来看，似乎这种趋势已得到业界的普遍认可。事实上，以目前的生态体系来看，使用X86的优势是很明显的。我们来看使用PowerPC/MIPS等嵌入式处理器的开发模式，其实是相当繁琐：

首先，你得构建嵌入式的交叉编译开发环境，在HOST上编译嵌入式Target的代码，然后拷贝到Target上运行，也不能本地调试。可以看出，这相对于Local的开发模式，其开发效率本身就是比较低下的。

其次，没有通用的发行版可用，任何软件资源你都得以源码方式移植。做过开发的都知道，很多组件库、工具软件相互之间的依赖性很强，当你觉得需要A而进行移植的时候，发现它依赖于B，而B又依赖于众多其它的库或工具软件，有可能引发雪崩式的连锁反应，最终有可能因为需要进行源码移植的库或工具数量太多，令你望而生畏，最终选择放弃。

最后，上述过程其实就相当于你自己默默的从零开始独立构建了一个私有的Linux发行版，没有任何包管理工具，做到后面，你可能都不知道系统里有哪些库或工具集，它们各是什么版本。当你需要升级或者更改某个库或者工具时，可能又是一次痛苦的连锁反应。

而使用标准的Linux发行版（比如Debian、Centos等）则可以避免上述问题，同时还可以复用大量已有的服务器软件资源，包括自动部署、监控管理等。基于上述因素，在后续适当时候可以考虑引入基于X86处理器的ODM硬件，目前主流的ODM供应商如Quanta、Celestica，也都推出了X86的CPU控制子板。

在此情况下，交换机将演变为下图所示的软硬件体系架构：

与SDN技术的结合

关于SDN，Facebook公开提到一点还是相当有价值的：相对于控制面、转发面的分离，Facebook现阶段更聚焦在管理面、监控面的集中控制，并保持所有基础架构设备的统一集中管控，将服务器、网络设备的管控系统统一。这得益于将网络设备的内部透明开放，并通过与服务器共用标准Linux OS发行版。如下图，通过基础架构管控平台，统一对服务器、网络设备的管控，实现高度自动化灵活的管控系统；而网络集中控制功能则可以基于开源的ODL等系统搭建。当然，这里的基础架构管控平台与SDN控制器，也可以合在一起，作为统一的系统体系构建。

SDN的整体技术体系，追求高度的用户可定制性，可根据实际业务及运营需求，快速响应并部署。如果这时网络设备还是封闭的黑盒，难以快速进行增量化的研发及功能部署，显然是与SDN的整体思路相悖的。可以这么说，一个开放的、用户可灵活定制的网络设备及其开放生态体系，在长期来讲是SDN的必然要求，很难想象整体SDN系统能够构建在一个封闭的网络设备黑盒子基础之上。

5. 参考文献

• OCP wiki: http://www.opencompute.org/wiki/Networking
• ONIE website: http://www.onie.org
• Dell and Cumulus Networks Aim to Take 'BYO Switching' Mainstream: https://www.gartner.com/doc/2660221
• http://www.dell.com/learn/us/en/uscorp1/secure/2014-01-28-dell-open-networking-cumulus
• Cumulus Networks™ Teams With VMware To Accelerate Widespread Adoption Of Network Virtualization：
• http://cumulusnetworks.com/press_releases/detail/20130826-cumulus-networkstm-teams-with-vmware-to-accelerate-widespread-adoption-of-network-virtualization/
• Introducing “Wedge” and “FBOSS,” the next steps toward a disaggregated network:
• https://code.facebook.com/posts/681382905244727/introducing-wedge-and-fboss-the-next-steps-toward-a-disaggregated-network/
• bigswitch-open_network_linux.pdf：http://files.opencompute.org/oc/public.php?service=files&t=640ca4ad80c578684fade8efb33e379c
• onug-baremetal-2014-final.pdf：http://files.opencompute.org/oc/public.php?service=files&t=96c08b68b682f40c5d98e1ce9c98e746