ONOS与OpenDaylight比较

    目前以设备提供商为代表的OpenDaylight阵营目前发展势头正劲，而由斯坦福大学和加州大学伯克利分校SDN先驱创立的非营利性组织ON.Lab也紧锣密鼓地推出了自己的开源SDN操作系统——ONOS。此次打造的商业级的以用户为导向的ONOS开放网络操作系统是以服务提供商为首的，并且得到了开放网络基金会ONF的鼎力支持，意欲与OpenDaylight一决高下。具体的性能究竟孰好孰坏还需要等待发布之后的评测，下面小编就从不同的方面比较一下这两个业界最知名的网络操作系统。

1. 驱动方式不同                                     

  ONOS白皮书中写道，一个操作系统应该具备下述功能：

l 为用户管理有限的资源。

l 隔离和保护NOS用户。需要操作系统能复用多个应用和多个设备。

l 提供一个可用的抽象层让用户灵活的使用操作系统所管理的服务和资源，并且无需了解网络的复杂性。

l 为外部操作系统提供安全保障。

l 提供敏捷高效的服务，那么用户就不需要创建、重建相同的服务。

    这些都是网络应用所需要的。通常控制器的所控制的范围十分局限，通常设置为控制一个设备。ONOS具备一个操作系统所具备的所有功能，不仅仅是控制器的功能，例如可以提供高效敏捷的抽象层，能够将不同的控制器使用者隔离开来，能够提供有价值的服务等等。ONOS是根据服务提供商的特点和需求进行软件架构设计的。因此ONOS是需求驱动下的产物。

    相比而言，目前围绕SDN的炒作更多的是来自设备供应商。OpenDaylight是由思科和IBM 联合其合作伙伴，以及竞争对手建立的组织。其初创成员包括：微软、Big Switch（已退出）、博科、思科、思杰、戴尔、爱立信、富士通、IBM、英特尔、瞻博网络、微软、NEC、惠普、红帽和VMware等。我们可以看到这些成员都是设备供应商，和ONF不同的是OpenDaylight是由大厂商控制的并且削弱了用户的声音。并且它还可能会出于利益问题将部分功能同设备锁定，这并不是SDN的初衷。我们所期望的便是看到所有参与其中的人能共同推动SDN的进步。

2.面向对象不同

    ONOS和OpenDaylight代表的阵营不同，面向对象也不同。ONOS的设计理念是能在任何硬件（包括白牌机）上灵活的创建服务并且大规模部署，因其可靠性强，性能好，灵活度高的特点适用于面向服务提供商和企业骨干网。它不仅可以满足运营商提供敏捷和灵活的需求，并且有可能使其摆脱设备供应商的束缚，因此很多运营商愿意接受ONOS。而最近发布的2.0版本的OpenDaylight以及来自其成员企业的支持给其带来了新的发展势头，但是因其成员关系，其在很大层面上受设备商的制约。因此OpenDaylight是设备商在一定程度上为了维护自己阵营的利益的产物，其主要面向对象也是设备商。

3.架构不同

ONOS架构设计伊始就将服务提供商放在首位。下图是ONOS架构图。

图1：ONOS架构

    我们看到ONOS架构具体由应用层、北向核心接口层、分布是核心层、南向核心接口层、适配层、设备层六部分构成，其中南向核心接口层和适配层可以合起来称作南向抽象层，它是连接ONOS核心层与设备层的重要桥梁。

    ONOS的北向接口抽象层将应用与网络细节隔离，同时网络操作系统又与应用隔离，从业务角度看，提高了应用开发速度。ONOS可以作为服务部署在集群和服务器上，在每个服务器上运行相同的ONOS软件，因此ONOS服务器故障时可以快速地进行故障切换，这就是分布式核心平台所具有的特色性能。分布式核心平台是ONOS架构特征的关键，它为用户创建了一个可靠性极高的环境，将SDN控制器特征提升到运营商级别，这一点是ONOS的最大亮点。南向抽象层由网络单元构成，它将每个网络单元表示为通用格式的对象。通过这个抽象层，分布式核心平台可以维护网络单元的状态，而不需要知道底层设备的具体细节。南向接口确保了ONOS可以管控多个使用不同的协议的不同设备。

图2：OpenDaylight氦版本架构

    从上图我们可以看到OpenDaylight最新氦版本架构主要由应用服务层、控制平面层、南向接口层和数据平面层四层构成。大体架构与ONOS并无不同。主要不同还是体现在内部架构的设计上。

OpenDaylight为应用（App）提供开放的北向API。支持OSGi 框架和双向的REST 接口。OSGi

框架提供给与控制器运行在同一地址空间的应用，而REST API 则提供给运行在不同地址空间的应用。所有的逻辑和算法都运行在应用中。

    控制平面主要包含了基本网络服务和一些附加的网络服务，这些附加服务都可以通过插件的形式安装加载，这增加了OpenDaylight的灵活性。当然了其稳定性也是显而易见的，但并没有采取的像ONOS那样的分布式策略。相比而言ONOS的可靠性应该要更高一些。

    南向通过plugin的方式来支持多种协议，包括OpenFlow1.0、1.3，BGP-LS 等。这些模块被动态挂载到服务抽象层（SAL），SAL 为上层提供服务，将来自上层的调用封装为适合底层网络设备的协议格式。但是其中的一个名为OpFlex的南向协议则遭到较多的质疑，有人认为OpFlex并不是正确的抽象化，它暴露了设备的细节给应用程序，这意味着它引入较少的抽象和更多的复杂性。从OpenDaylight在南向接口上做的工作可以看出在某些情况下南向接口并没有把底层设备完全抽象出来再给控制平面去处理，这可能也是OpenDaylight代表设备商一边利益的表现。

4.总结

    本文将ONOS和OpenDaylight从驱动方式、面向对象和架构三个方面进行简要的比较。我们可以看出OpenDaylight是由设备商主导的一个开源控制器，虽然打着开放的旗号，但是OpenDaylight一直排斥基于开放的协议方案，而是想采用折中的方案，即以开放专用接口的方式保留传统设备，采取以退为进的方式维护自己的利益。另一方面服务提供商希望他们的网络敏捷、高效，满足日益增长的带宽需求，以创新服务和新型业务模式获取收入。软件定义网络SDN是服务提供商网络转型的关键，ONOS正是这样一个为服务提供商量身打造的新型运营商级别的SDN网络操作系统。

本文来源于SDNLAB，可点击此阅读原文。如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。（1） 微博（http://weibo.com/sdnlab/）

（2） 微信(账号：SDNLAB)

（3） QQ群

SDN研究群（214146842）

        OpenDaylight研究群（194240432）