ONOS研究材料

1、整理1、ONOS预热篇之ONOS简介（一）ONOS问世后引起广泛关注，关于ONOS与ODL的纷争不绝于耳，最近小编拜读了一下ONOS白皮书，并做了一点粗浅总结，下面就跟大家分享一下。1 ONOS诞生背景1.1 ONOS诞生的利益分析随着移动设备的不断普及，OTT服务和内容分发的兴起导致服务提供商网络迫切的需要一次网络变革。为了应对日益增长的带宽需求，服务提供商希望网络可以更加敏捷高效，且能从创新型服务和新型业务模式中分一杯羹得到更好的发展，至此SDN的呼声越来越高。而SDN中控制器占重要部分，是兵家必争之地，陆陆续续已经出现了很多SDN控制器，如OpenDaylight、OpenContrai

2、l、Ryu、Floodlight、NOX、SPOX等等，其中最受瞩目的莫过于OpenDaylight了。OpenDaylight是由设备商主导的一个开源控制器，虽然打着开放的旗号，但是OpenDaylight一直排斥基于开放的协议方案，而是想采用折中的方案，即以开放专用接口的方式保留传统设备，采取以退为进的方式维护自己的利益。不可否认地，设备商拥有丰富的设备研发经验， OpenDaylight也确实是一款优秀的控制器，但是在这样的压力下，运营商不得不采取应对措施。于是，运营商推出了开放网络操作系统ONOS。1.2 ONOS又凭什么与OpenDaylight叫板呢？过去几年来已经有几款关于软件定

3、义网络的控制器，然而，我们很清楚地了解大部分控制器缺乏可扩展性、可靠性，除此之外，他们的性能不够良好且抽象层过于简单粗糙，并不能用于商业化产品。这些控制器直接向功能组件发送OpenFlow消息，而这些功能组件直接为网络设备创建OpenFlow消息，这样看来，这些控制器更像是设备驱动。它们不具备一个完整的SDN控制器平台所需的性能特征。真正需要的是一个一体化的网络操作系统，ONOS就是为了满足这些需求而创建。一个操作系统应该具备下述功能：§ 用户资源管理。确保所有用户有同样的权利，没有资源匮乏也没有资源泛滥、公平、合理的分配资源。§ 用户隔离。由于每个用户都希望全权分配资源，

4、所以将用户相互隔离，在多个应用和多个设备之间多路传输，并且通过资源虚拟化技术让用户享用各自的虚拟化OS可操作应用。§ 抽象层管理。提供一个抽象层方便用户使用操作系统所管理的服务和资源，无需了解网络的复杂性；且在不改变应用的前提下，可以灵活拓展操作系统所管理的设备。§ 提供用户安全保障机制。§ 提供敏捷高效性服务。用户无需重建相同的服务，提高使用效率。ONOS具备一个操作系统所具备的所有功能，不仅仅是控制器的功能。除此之外，ONOS还提供技术社区专栏，给更多的研究学者提供更广阔的交流、共享平台。2 ONOS社区概览ONOS的发布是一场业内盛宴，集聚了知名的服务提供商

5、（如AT&T、NTT通信）、高标准的网络供应商（如Ciena、Ericsson、Fujitsu、Huawei、Intel、NEC）、网络运营商（如Internet2、CNIT、CREATE-NET），以及其他合作伙伴（如SRI、Infoblox），并且获得ONF的鼎力支持。2.1 ONOS社区的目标打造一个社区，共同完成SDN的愿景与使命：§ 生产高质量的网络操作系统软件；§ 创建高效的开源流程，吸引更多同道中人；§ 通过不断努力以及贡献促进社会科技、生活的发展。2.2 ONOS社区的自我要求§ 顾客，服务顾客；§ 精英，采用精英管理体

6、制；§ 创新，坚持创新；§ 质量，始终如一地追求高质量；§ 尊重，永远尊重别人；§ 透明化，透明化操作及管理。3 ONOS简介服务提供商希望他们的网络敏捷、高效，满足日益增长的带宽需求，以创新服务和新型业务模式获取收入。软件定义网络SDN是服务提供商网络转型的关键，而ONOS是一个为服务提供商量身打造的新型运营商级别的SDN网络操作系统，由ON.Lab和ONOS社区内领先的服务提供商、供应商和开发者共同开发。ONOS是首款开源的SDN网络操作系统，主要面向服务提供商和企业骨干网。ONOS的设计宗旨是满足网络需求实现可靠性强、性能好、灵活度高。此外，ONO

7、S的北向接口抽象层和API支持简单的应用开发，而通过南向接口抽象层和接口则可以管控OpenFlow或者传统设备。总体来说，ONOS将会实现以下功能：§ SDN控制层面实现电信级特征（可靠性强，性能好，灵活度高）；§ 提供网络敏捷性强有力保证；§ 帮助服务提供商从现有网络迁移到白牌设备；§ 减少服务提供商的资本开支和运营开支。ONOS架构概述：ONOS具有下述核心功能：§ 分布式核心平台，提供高可扩展性、高可靠性以及高稳性能，实现运营商级SDN控制器平台特征。ONOS像集群一样运行，使SDN控制平台和服务提供商网络具有网页式敏捷度。§

8、北向接口抽象层/APIs，图像化界面和应用提供更加友好的控制、管理和配置服务，抽象层也是实现网页式敏捷度的重要因素。§ 南向接口抽象层/APIs，可插拔式南向接口协议可以控制OpenFlow设备和传统设备。南向接口抽象层隔离ONOS核心平台和底层设备，屏蔽底层设备和协议的差异性。且南向接口是从传统设备向OpenFlow白牌设备迁移的关键。§ 软件模块化，让ONOS像软件操作系统一样，便于社区开发者和服务提供商开发、调试、维护和升级。   SDNLAB语：SDN时代的到来为服务提供商提供了转型机遇，为了能够从创新型服务和新型业务模式中分一杯羹，服

9、务提供商一直在探索转型的跳板。ONOS就是一款为服务提供商量身打造的产品，助力服务提供商转型。随着ONOS的参战，业内竞争愈加激烈，SDN的发展前景也越来越明朗化。期待12月5号，ONOS的首发！2、ONOS预热篇之架构简析（二）ONOS是首款专门面向服务提供商和企业骨干网的开源SDN网络操作系统，是由一家名为开放网络实验室（ON.Lab）的非盈利性组织打造的一款商用控制器，并将于美国时间2014年12月5日全球首发。ONOS旨在为服务提供商和企业骨干网提供高可用性（HA）、可横向扩展及高性能的网络需求。由于该项目得到了业界各知名大佬包括服务提供商AT&T、NTT，网络供应商Ciena

10、、Ericsson、Fujitsu、Huawei、Intel、NEC，网络运营商Internet2、CNIT、CREATE-NET的资助和开发，并获得了ONF的鼎力支持，使得ONOS的消息一公布就被炒得炙手可热，可谓赚足了眼球。目前市面上已经有很多开源SDN控制器，包括NOX、Beacon、SNAC和POX，这些控制器的问世向我们展示了SDN的魅力与潜力。但是我们必须清楚这些控制器并不能用于商业化的产品，因为它们缺乏可扩展性、可靠性以及良好的性能等商业所需的关键特性。据称这也将是一款能与OpenDaylight抗衡的一款商业级SDN网络操作系统。那么，ONOS到底怎样实现商业化性能的，它的架构

11、到底出色在哪里？下面小编从ON.Lab官方发布的白皮书摘取了相关资料来简析一下ONOS的架构。1. ONOS架构ONOS架构设计伊始就将服务提供商放在首位。可靠性强、灵活度高以及良好的性能都是最基本的要素，同时它还具有强大的北向接口和南向接口。ONOS具有的核心功能主要包含：北向接口抽象层/APIs、分布式核心、南向接口抽象层/APIs、软件模块化，具体将做详细分析。下图给出了ONOS的设计架构图:图 1. ONOS的设计架构图1.1 北向抽象层ONOS有两个强大的北向抽象层：Intent架构和全局网络视图。Intent架构屏蔽服务运行的复杂性，应用向网络请求服务而不需要了解服务运行的具体细节

12、。应用更多的集中于能做什么，而不是怎么做。全局网络视图为应用提供了网络视图，包括主机、交换机以及和网络相关的状态参数，如利用率。应用可以通过APIs对网络视图进行编程，一个API可以为应用提供网络视图。确切的说，北向接口抽象层和APIs将应用与网络细节隔离，而且也可以隔离应用和网络事件（如连接中断）。相反的，将网络操作系统与应用隔离，网络操作系统可以管理来自多个、竞争应用的请求。从业务角度看，提高了应用开发速度，并允许在应用不停机的状态下进行网络更改。1.2 分布式核心（DISTRIBUTED CORE）分布式核心平台提供组件间的通信、状态管理，领导人选举服务。因此，多个组件表现为一个逻辑组件

13、。对设备而言，总是存在一个主要组件，一旦这个主要组件出现故障，则连接另一个组件而无需重新创建新组件和重新同步流表。对应用而言，网络图形抽象层屏蔽了网络的差异性。另外，应用可以获悉组件和数据平台的故障代码。这些都大大简化了应用开发和故障处理过程。从业务角度看，ONOS创建了一个可靠性极高的环境，有效地避免应用遭遇网络连接中断的情况。而且，当网络扩展时网络服务提供商可以方便地扩容数据平台，且不会导致网络中断。通过相同的机制，网络运营商也可以实现零宕机离线更新软件。总而言之，分布式核心平台是ONOS架构特征的关键，将SDN控制器特征提升到电信运营商级别。图 2. ONOS分布式核心架构图1.3 南向

14、接口抽象层南向抽象层由网络单元构成，例如交换机、主机或是链路。ONOS的南向抽象层将每个网络单元表示为通用格式的对象。通过这个抽象层，分布式核心平台可以维护网络单元的状态，并且不需要知道底层设备的具体细节。这个网络单元抽象层允许添加新设备和协议，以可插拔的形式支持扩展，插件从通用网络单元描述或操作映射或转化为具体的形式，反之亦然。所以，南向接口确保了ONOS可以管控多个使用不同的协议的不同设备。南向抽象层的主要优势包括：§ 可以用不同的协议管理不同的设备，且不会对分布式核心平台造成影响。§ 扩展性强，可以在系统中添加新的设备和协议。§ 可以轻松地从传统设备迁移到支

15、持OpenFlow的白牌设备。1.4 软件模块化软件模块化是ONOS一大结构特征，方便软件的添加、改变和维护。ONOS的主体架构是围绕分布式核心平台的三层架构，核心平台内部的子结构也能体现模块化特征，核心平台的存在价值就是约束任何一个子系统的规模并保证模块的可拓展性。此外，连接不同模块的接口是至关重要的，允许模块不依赖其他模块独立更新。这样就可以不断更新算法和数据结构，并且不会影响整体系统或是应用，这一特点是确保软件稳定更新的关键。ONOS建立树形结构不仅仅为了遵循而是要加强这些结构原则。合理控制模块大小并且模块之间保持适当依赖形成一个非循环的结构图，模块之间通过API模块之间关联，正如下图所

16、示：图 3. ONOS模块结构图软件模块化的优势归纳为一下几点：§ 保证结构的完整性和连贯性；§ 简化测试结构，允许更多的集成测试；§ 减小系统某部分改变的影响，从而降低维护难度；§ 组件具有可拓展和可定制的特性；§ 规避循环依赖的情况。2. 总结本文简析了ONOS的设计架构，因为截稿前产品还未发布，只是根据官方发布的白皮书简要阐述它们的设计意图、理念以及架构各层面主要特点。想要具体了解ONOS还待12月5日正式发布及小编后续的文章。3、ONOS预热篇之开放分布式SDN操作系统（三）关于构建ONOS（开放式网络操作系统）的项目专题，是通过性能激

17、发创建的实验性分布式SDN控制平台，满足大型运营商网络的可扩展性、可用性需求。提出了2个版本的ONOS原型，第一个原型版本实现的核心功能是实现一个分布式的但在逻辑上集中的全局网络视图、可扩展性和容错。另一个原型版本侧重于提高性能，基于这两个原型的实践，已形成论文发表ONOS: Towards an Open, Distributed SDN OS，确定需要ONOS来支持使用案例，如核心网络流量工程和调度，变成一个在可用的开源SDN社区构建分布式网络操作系统平台。一、 介绍近年，学术界和产业界对SDN产生了极大的兴趣。一个开放的、厂商中立的、控制数据平面分离的接口如OpenFlow，允许网络硬件

18、和软件独立发展，并促进了免费的开源的网络操作系统的发展，来更换传统的、价格昂贵的、专有的硬件和商用硬件。通过管理网络资源和提供高层次的抽象和APIs，NOS提供一个开放的平台，它简化了创新有益网络应用的创建并且服务于多种硬件网络。为了支持大型网络，NOS必须满足可扩展性大、性能高、可用性强的需求。根据网络运营商的讨论，并考虑到服务提供商网络中的流量工程使用，我已确定几个极具挑战性的需求，如图1：图1：ONOS需求§ 高吞吐量，达到1M requests/s；§ 低延迟，事件进程10-100ms；§ 全局网络状态大小，数据量最高达到1TB；§ 高可用性，9

19、9.99%的服务可用性。为了解决上述问题，已在实验系统上运行开放网络操作系统（Open Network Operating System，ONOS）。ONOS采用一个分布式架构，可达到高可用性和高扩展性，为应用程序提供一个全局的网络视图，即使物理上分布在多服务器，逻辑上也可集中管控。ONOS作为一个开源项目，主要通过下面两个重要原型的开发逐渐发展演变：（1）原型1在分布式平台上为扩展性和容错能力致力于全局网络视图；（2）原型2致力于提高性能，尤其是为事件延迟添加了一个事件通知框架，改变数据存储和数据模型并添加缓存层。二、 原型1：网络视图、扩展和容错ONOS最初的挑战是创建一个有用的抽象层、全

20、局网络视图、以及在一个系统上跨多个服务器运行在控制层面的扩展和容错能力。使用开源构件建立的第一个原型是为了快速验证以及更深入探索设计的可能性。根据现有的开源SDN控制器Floodlight开发出第一个原型，使用了Floodlight的部分模块，包括交换机管理、I/O回环、链路发现、模块管理和REST APIs。下图显示了原型1的系统架构：图2：原型1架构2.1 全局网络视图ONOS含有全局网络视图功能，在集群中通过ONOS服务器管理和共享网络状态，并提供一个对应底层网络结构的网络视图模型。在每个ONOS实例中发现的网络拓扑和状态，如交换机端口、链路和主机信息构成全局网络视图，并从全局网络视图中

21、读取应用程序确定转发策略，然后将转发策略依次写到网络视图中，当视图信息发生变化时，将变化消息发送到相应的OpenFlow控制器并下发到在指定的交换机上。初始的网络视图数据模型，采用Titan图形数据库实现、使用Cassandra键值存储实现分布式和可持续性，通过Blue-prints图形API暴露网络状态给应用程序。由于Cassandra具有一致性存储的特性，所以保障了网络试图的最终一致性。2.2 可扩展性ONOS的一个关键功能是其可扩展性和容错能力的分布式架构，ONOS运行在多个服务器上，每个作为专属的master OpenFlow控制器，管理网络子集中的交换机。一个ONOS将独立完成对网络

22、及交换机的控制并负责全局网络视图之间的状态变化；当数据平面容量增长或者在控制平面需求增加时，附加的ONOS应用实例可以被添加到ONOS集群中分发控制平面的工作负载，体现了良好的可扩展性。2.3 容错能力在ONOS分布式体系结构中，当一个组件或ONOS实例失败时，有其他剩他实例的情况下，允许重新分配，保障系统仍能继续工作。ONOS的架构允许在运行时组件存在于一个实例，但是提供多个冗余的实例，接管之前的失败实例来控制组件。在运行时通过在所有实例中选择一个最优实例来代替初始实例。一个交换机可以连接多个ONOS实例，但是对于每个交换机来说，只有一个主（master）实例控制。这个master实例独自负

23、责发现交换机信息和控制交换机，当一个ONOS主实例失败时，剩余的实例选择一个新的master来控制交换机。与每个交换机一致性匹配度最高的ONOS实例被选择运行最为master，以确保在所有交换机中，被选择的这个ONOS实例能够负责每台交换机。用Zookeeper管理交换机和控制器之间的关系，包括监测和反馈ONOS实例是否失败；同时，ONOS实例一定要与Zookeeper保持连接为了成为交换机的master控制器。如果一个ONOS实例与Zookeeper失去连接，另一个ONOS实例将负责控制此交换机。Zookeeper使用一个匹配的协议维持与ONOS很大的一致性，且只要大多数服务器可用，Zook

24、eeper就有很强的容错能力。2.4 评估第一个ONOS原型开发历经4个月，在2013年4月在ONS（Open Networking Summit）大会上演示了ONOS原型1，这个演示显示ONOS控制几百个虚拟交换机、使用网络视图下发端到端的流、动态添加交换机和ONOS实例到集群中、针对ONOS实例停机的故障转移以及针对链路响应失败重新添加路由等。总体来说，虽然已经实现了系统的基本功能，但是一些设计选择导致性能和可用性并不好，主要表现是一下几个方面：§ 一致性和完整性。Titan在Cassandra上最终要保持数据存储的一致性以及图形架构的完整性，比如一条链路必须连接两个节点；

25、67; 低性能和可见性。原型1延迟比预期差很多，主要原因在于使用开源软件，虽然很快可以完成开发，但是这些开源软件之间的协调，并不容易。而且ONOS的开发者并不是特别熟悉这些开源代码，导致性能并不高；§ 数据模型问题。使用Titan存储导致所有数据如Port,flow entries等都需要以Vertices存储，需要构建一个索引来查询数据，如交换机数据。当大量节点加入网络时，并发的数据量增加导致索引构建就会成为瓶颈；§ 过多的数据存储操作。Titan和Cassandra间的数据转换会产生过多数据存储操作导致延迟；§ 轮询问题。通过周期同步数据，没有实现订阅分发，增

26、加CPU的使用率。通过模型1的测试及分析，需要设计更高效的数据模型，减少多余的数据操作，实现订阅分发机制以及简化API等。三、 原型2：性能提高原型2主要集中关注于提高ONOS的性能，但是这个导致改变了网络视图架构并添加了事件通知架构，如下图所示：图3：原型2架构远程数据操作是原型1最大的性能瓶颈之一，所以在原型2中主要通过尽可能快的远程操作、减少ONOS远程操作量这2种方法解决这个问题。主要涉及的优化主要有：1.RAM云数据存储。使用内存来代替普通硬盘来存储，从而大大提高存储速度；2.优化数据模型。新设计了一个data model，更新相对独立，大大减少了数据的读写操作，优化了性能；3.拓扑

27、缓存。原型1读取拓扑非常耗时，ONOS将拓扑信息存在高速缓存中，从而提高了读取拓扑的速度。除此之外，通过构建索引更快速地查找数据。构建索引可以在任何时刻由全部的数据生成，但是一般情况下，只有新接入ONOS节点时，才会读取全部数据，这不会消耗太多时间；4.事件通知。上文已提到由于周期获取数据而引起的性能问题，所以引入事件通知机制。原型2创建实例内部的发布-订阅的事件机制，将这个通信系统部署在Hazelcast上；5.网络视图API。ONOS用自己设计的API取代生成的Blueprints graph API。图4展示了网络视图的内容，ONOS的API主要包涵下面的三个部分：§ 对底层设

28、施拓扑的抽象描述的接口；§ 处理网络或系统Events（事件）的接口；§ 提供安装流表等信息的接口。图4：使用流表创建数据包路径的连通性请求网络视图3.1 性能评估原型2的性能主要在以下三个方面进行测试和评价：§ 基础网络状态改变；§ 对网络事件的反应；§ 路径部署；3.1.1 基础网络状态改变当网络中状态发生改变，将进行数据更新操作，会阻塞ONOS的操作，将影响整个ONOS的性能。测试案例中使用三个节点的ONOS集群，连接81个OpenFlow交换机，构成一个典型的WAN拓扑，且每个交换机上都有四个活跃的端口。ONOS采用了对比的方式，表1展

29、示添加一个交换机后需要的latency，结果可以看出，使用通用的API速度最慢；使用自定义的API，速度提高很多。因为新的Data model仅需要一步就可以完成添加交换机操作，时间上从22.2ms降到1.19ms，延迟减少了很多。在序列化方面由原来的Kryo 尝试使用Google Protocol Buffers，这使延迟时间下降了0.244ms。除此之外，在RAM云集群中还尝试使用Infiniband硬件并优化网络的I/O，性能数据得到了提高。表1：添加一个交换机的延迟性能测试3.1.2 对网络事件的反应对网络事件的反应测试主要是针对ONOS对网络事件的反应速度、端到端的延迟等性能，如网络

30、中某一条链路断掉后，ONOS对流量重选路由的过程需要多长时间，这个性能直接关系到SLA（Service-Level Agreement）的性能。实验测试使用了6个节点的ONOS集群，数据层面使用Mininet模拟206个交换机和416条链路。将16000条flows添加到网络中，然后关掉交换机的其中一个端口，结果分析显示1000多条flows重新选择路由，其中每一条流有6跳，当某一端口关掉之后，重新选择路由，每一条流将变成7跳。表2显示重选路由进度进行到一半和99%的数据，从网络时间上捕捉到下发第一条flow_mod及全部flow_mod下发的延迟时间。表2：重选1000条流的路由延迟时间3.

31、1.3 路径部署第三个性能指标测试ONOS系统的吞吐量，测试使用了与对网络事件的反应测试相同的拓扑，但是预先下发15000条静态流表，添加1000条6跳的flows。表3测试结果显示的是路径部署的延迟时间，吞吐量与延迟成反比，在所有流进程进行到一半时吞吐量为18832paths/sec。表3：路径部署延迟时间3.2 评估在原型2中，ONOS对说网络事件的延迟达到了预期的要求，但是吞吐量上还没有达到1M path/sec的标准。不过开发者们将这个原因归咎于仅使用了一个ONOS节点来计算路劲。四、 实例2014年3月，论文作者们将ONOS原型2部署在Internet2上运行展示，在大会上展示了（1

32、）ONOS的网络视图；（2）在真实WAN上操作；（3）使用虚拟化硬件和软件交换机；（4）加速ONOS和链路故障转移。图5阐明了ONOS的系统配置：地理上分布5个硬件交换机的主干网络，且每个交换机连接一个模拟的软件交换机。并一个在物理架构上使用OVX（OpenVirteX）创建一个含有205个交换机和414条链路的虚拟网络，并且在印度大学NOC实验室有一个8节点的ONOS集群控制此虚拟网络。图5：Internet2拓扑和配置Demo图6显示ONOS发现的拓扑，与图5对比，Los Angeles和Chicago 、 Chicago和Washington D.C之间显示的链路是由OVX虚拟，如下图显

33、示：图6：ONOS GUI显示发现的交换机和链路拓扑五、 总结：开放分布式SDN操作系统建立了两个版本ONOS原型，希望将分布式SDN控制平台发展成为一个更完善的网络操作系统满足大型运营商网络性能和可靠性需求。现在意欲开发多个原型案例帮助推进SDN的发展，其中包括系统APIs、抽象、资源隔离以及调度等。另外，将继续致力于满足性能需求以及开发有用的系统开源版本。后语：小编在翻译总结的过程中，学习到了很多关于全局网络视图以及分布式管理的知识。ONOS应该是不错的控制器产品，甚至于说是不错的SDN 操作系统。ONOS应用了Titan和Cassandra技术保障了数据的完整性，添加了事件通知框架减少了

34、事件的延迟，使用Zookeeper检测和反馈系统状态，提高了容错能力，采用的分布式框架使扩展能力得到延伸，应用最新的OVX虚拟化网络，以及在性能调优上做了更大的改变和进步，期待ONOS开源版本的发布使用！4、ONOS预热篇之ONOS与OpenDaylight比较（四）目前以设备提供商为代表的OpenDaylight阵营目前发展势头正劲，而由斯坦福大学和加州大学伯克利分校SDN先驱创立的非营利性组织ON.Lab也紧锣密鼓地推出了自己的开源SDN操作系统ONOS。此次打造的商业级的以用户为导向的ONOS开放网络操作系统是以服务提供商为首，并且得到了开放网络基金会ONF的鼎力支持，意欲与OpenDa

35、ylight一决高下。具体的性能究竟孰好孰坏还需要等待发布之后的评测，下面小编就从不同的方面比较一下这两个业界最知名的网络操作系统。1. 驱动方式不同ONOS白皮书中写道，一个操作系统应该具备下述功能：§ 为用户管理有限的资源。§ 隔离和保护NOS用户。需要操作系统能复用多个应用和多个设备。§ 提供一个可用的抽象层让用户灵活的使用操作系统所管理的服务和资源，并且无需了解网络的复杂性。§ 为外部操作系统提供安全保障。§ 提供敏捷高效的服务，用户不需要创建、重建相同的服务。这些都是网络应用所需要的。通常控制器所控制的范围十分局限，通常设置为控制一个

36、设备。ONOS具备一个操作系统所具备的所有功能，不仅仅是控制器的功能，例如可以提供高效敏捷的抽象层，能够将不同的控制器使用者隔离开来，能够提供有价值的服务等等。ONOS是根据服务提供商的特点和需求进行软件架构设计的。因此ONOS是需求驱动下的产物。相比而言，目前围绕SDN炒作更多的是来自设备供应商。OpenDaylight是由思科和IBM 联合其合作伙伴，以及竞争对手建立的组织。其初创成员包括：微软、Big Switch（已退出）、博科、思科、思杰、戴尔、爱立信、富士通、IBM、英特尔、瞻博网络、微软、NEC、惠普、红帽和VMware等。我们可以看到这些成员都是设备供应商，和ONF不同的是Op

37、enDaylight是由大厂商控制的并且削弱了用户的声音。并且它还可能会出于利益问题将部分功能同设备锁定，这并不是SDN的初衷。我们所期望的便是看到所有参与其中的人能共同推动SDN的进步。2.面向对象不同ONOS和OpenDaylight代表的阵营不同，面向对象也不同。ONOS的设计理念是能在任何硬件（包括白牌机）上灵活的创建服务并且大规模部署，因其可靠性强，性能好，灵活度高的特点适用于面向服务提供商和企业骨干网。它不仅可以满足运营商提供敏捷和灵活的需求，并且有可能使其摆脱设备供应商的束缚，因此很多运营商愿意接受ONOS。而最近发布的2.0版本的OpenDaylight以及来自其成员企业的支持给其带来了新的发展势头，但是因其成员关系，其在很大层面上受设备商的制约。因此OpenDaylight是设备商在一定程度上为了维护自己阵营的利益的产物，其主要面向对象也是设备商。3.架构不同ONOS架构设计伊始就将服务提供商放在首位。下图是ONOS架构图：图1：ONOS架构我们看到ONOS架构具体由应用层、北向核心接口层、分布是核心层、南向核心接口层、适配层、设备层六部分构成，其中南向核心接口层和适配层可以合起来