转载自：ONOS && ODL

1.概述

目前以设备提供商为代表的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网络操作系统。

注：

ODL和ONOS都已经加入Linux基金会了，合作大于竞争。

重点Mark：

1、ODL是设备提供商主导的SDN控制器开源方案（包括思科、IBM、微软、HP、戴尔等） ODL是设备商在一定程度上为了维护自己阵营的利益产物。

2、ONOS是由斯坦福和UCB两所大学中SDN先驱创立的非营利性组织ON.Lab推出的，不如ODL成熟，主要面向服务运营商。

ONOS 以及 ODL相关推荐

SDN/NFV：现状，挑战和未来
信运营商和通信服务提供商(CSP)一直期待网络功能虚拟化(NFV)和软件定义网络(SDN)能够带来的优势,以帮助他们进入快速部署新服务,实现高度的网络自动化和动态重新配置的领域,从而降低资本支出/运营 ...
可编程网元的前世今生
▉ 可编程网元的过去在过去的很长一段时间里,网元之间通过OSPF(开放式最短路径优先协议).BGP(边界网关协议)等运行在设备控制面的分布式路由协议,进行交互工作. 网元提供SNMP.NETCONF ...
白盒交换机操作系统混战
白盒交换机的出现给了用户选择最佳软硬件平台的权利,它仅仅提供交换机硬件和ONIE(开放网络安装环境),用户可以自行选择最合适的交换机芯片,降低成本实现最大效益.但是白盒交换机没有软件是无法使用的,因此 ...
ONOS项目首赢11000次下载 Oracle发布云路由
ONOS项目首年下载11000次开放网络操作系统(ONOS)组织称越来越多的贡献者一同推进ONOS项目,其开源软件定义网络软件已经被下载超过11000次.参与者有助于为运营姬SDN控制器开发新的特性 ...
Verizon加入ONOS 加速网络传输服务
Verizon公司上周四宣布加入开源SDN开放网络操作系统(ONOS)项目,成为2016年首个加入该项目的服务提供商. Verizon将与其他的服务提供商和解决方案提供商如AT&T.NTT.南 ...
SDN控制器ONOS架构—Vecloud
ONOS是一个采用OSGI技术来管理子项目的SDN控制器开源项目,在最初设计时有这么几个目标是明确的: 1.代码模块化:支持把新的功能作为新的独立单元引入 2.特性可配置:无论是在启动还是运行时,支持 ...
ONOS之开放分布式SDN操作系统
为什么80%的码农都做不了架构师?>>> 关于构建ONOS(开放式网络操作系统)的项目专题,是通过性能激发创建的实验性分布式SDN控制平台,满足大型运营商网络的可扩展性.可用性 ...
ONOS系统架构演进，实现高可用性解决方案
上一篇文章<ONOS高可用性和可扩展性实现初探>讲到了ONOS系统架构在高可用.可扩展方面技术概况,提到了系统在分布式集群中怎样保证数据的一致性.在数据终于一致性方面,ONOS採用了Gos ...
.idl与.odl的区别
From: http://hi.baidu.com/%CD%E6%CA%AF%CD%B7%B5%C4%D0%A1%BA%A2/blog/item/1b9a942fe8cfcf594ec22629.ht ...
linux里gpl_GPL实施，ONOS与Linux Foundation合作以及更多新闻
linux里gpl 在本周的开放源代码新闻摘要中,我们将介绍面向社区的GPL实施,与Linux Foundation合作的ONOS项目,使用Texas Instruments计算器制作音乐的开放源代码 ...

ONOS 以及 ODL

1.概述

2.面向对象不同

3.架构不同

4.总结

ONOS 以及 ODL相关推荐

最新文章

热门文章