ONOS 是一个采用 OSGI 技术来管理子项目的 SDN 控制器开源项目，在最初设计时有这么几个目标是明确的：
1. 代码模块化：支持把新的功能作为新的独立单元引入
2. 特性可配置：无论是在启动还是运行时，支持动态加载和卸载特性
3. 协议无关：应用不需要和具体的协议库和实现绑定
模块化的实现： ONOS 项目由一组子项目组成，每个项目都有自己的源代码树，可以独立构建。为此， ONOS 的源码采用分层的方式来组织以方便利用 Maven 的级联 POM 文件组织。每个子项目都有自己的 pom.xml 文件和目录，子 pom.xml 文件会继承父 Pom 文件的共享依赖项和配置，使它们能够独立于不相关的子项目构建。 Root 目录包含用于建立完整的项目及其所有模块的顶层 POM 文件。
特性可配置： ONOS 使用 Karaf 作为其 OSGI 框架，除了在运行时的动态模块加载和启动时的依赖解析， Karaf 还支持以下几个特性。
支持使用标准的 JAX-RS API 来开发安全的 API 接口
支持将特性定义为一组 Bundle 来进行集中的自定义设置
对代码包有严格的语义版本声明，包括第三方依赖
有易扩展的命令行框架，支持本地和远端的 SSH 控制台登陆
支持不同日志级别的记录
协议无关， ONOS 被划分为以下几个部分：
和网络交互的协议感知模块
协议无关的系统 Core ，跟踪和服务网络状态信息
基于 Core 提供的系统信息来进行消费和操作的应用
上面的每一层都是分层体系结构，其中面向网络的模块通过一个南向 ( 提供者 )API 与 Core 进行交互， Core 与应用程序通过北向 ( 消费者 )API 进行交互。南向 API 定义了协议中立的手段将网络状态信息传递给核心， Core 通过面向网络的模块与网络设备交互。北向 API 为应用程序提供了描述网络组件和属性的抽象，以便它们可以根据策略定义其所需的动作。
服务是一个功能单元，它由不同层的多个组件作为软件堆栈创建垂直切片。我们把组成服务的组件的集合称为子系统。
ONOS 定义了不同的子系统：
设备子系统 - 管理基础设施设备的库存。
链路子系统 - 管理基础设施链接的库存。
主机子系统 - 管理终端站主机及其在网络上的位置的库存。
拓扑子系统 - 管理网络图视图的时间顺序快照。
path 子系统计算 / 发现基础设施设备之间或端站的主机采用最新的拓扑图快照之间的路径。
FlowRule 子系统 - 管理安装在基础设备的 match/action 流表项和统计流量。
Packet 子系统 - 允许应用程序监听从网络设备接收到的数据包，并通过一个或多个网络设备向网络发送数据包。
Provider
该堆栈的最底层是 Provider 组件， Provider 接口通过协议特定的库和底层设备打交道，并通过 Provider
Service 接口与 Core 交互。
协议感知 Providers 负责使用各种控制和配置协议与网络环境交互，并向 Core 提供服务特定的感知数据。 Provider 也可以从其他子系统收集数据，将它们转换成特定于服务的数据。
Provider 可能还需要从 Core 接受控制命令应用并通过适当的网络协议具体手段应用到网络中。这些都是通过 Provider 接口将这些内容送入 Provider 组件。
Provider ID
一个 Provider 与特定的 Providerid 相关。 providerid 的主要目的是提供一个 Provider 族的外部身份，这可以使设备和其他实体模型保持与负责他们的存在 Provider 相关联，甚至在 Provider 加载 / 卸载操作之后。
Providerid 携带一个 URI 方案名称允许松散的配对与从另一个供应商的家庭提供设备，而这没有访问提供商本身是可能的。
Multiple Providers
子系统可以与多个 Provider 关联。在这种情况下， Provider 被指定为主要的或附属的。主 Provider 拥有与服务相关联的实体，辅助提供者将其信息作为覆盖提供信息。如果任何覆盖导致与底层信息冲突，则此方法给予主 Provider 优先权。设备子系统是支持多个提供者的此类服务之一。
Manager
Manager 是驻留在核心中的组件，其接收来自 Provider 的信息，并将其提供给应用程序和其他服务。它暴露了几个接口：
Northbound Service interface 应用程序或其他核心组件可以通过该接口了解特定方面的网络状态。
AdminService interface 以管理员命令应用到网络或系统的状态。
Southbound ProviderRegistry interface
通过该接口 Provider 可以注册到 Manager 中，通过它可以和 Manager 进行交互。
Southbound ProviderService interface 提供给已经注册的 Provider
Manager 服务接口的消费者可以同步的查询 Service 的信息，也可以异步的作为一个事件侦听器 ( 例如，通过使用 listenerservice 接口注册要监听的事件并实现相关的 EventListener
interface) 。
Store
Store 的具体实现和 Core 里面的 Manager 有很强的相关性， Store 需要索引，持久化以及同步 Manager 收到的信息，这包括分布式 ONOS 多实例间的一致性和鲁棒性的保障，
Application
应用通过 AdminService 和 Service 接口来消费和操作 Manager 聚合的信息，应用程序具有广泛的功能，这里面就包括在 Web 浏览器中显示网络拓扑，为网络流量设置路径
Application ID
每个应用都有一个唯一的 Application ID ，这个标识用于追踪应用相关的上下文 ( 任务和目标
比如 Intent 和 FlowRule) ，为了获得一个有效的 ID ，应用需要注册到 CoreService ，注册他们的名字来进行反向域名解析，比如： org.onlab.onos.fwd
Events and Descriptions
两个在 ONOS 中分布的基本信息单元是事件和描述。与服务一样，事件和描述与特定的网络元素和概念相关联。两者都是一旦创建就不会改变的。
Descriptions
Descriptions 用于在南向的 API 上传递关于元素的信息。例如，一个 HostDescription 包含一个主机的 MAC 和 IP 地址，在网络中的位置信息 (VLAN
ID 和设备 / 端口的连接点 ) 。 Descriptions 通常是由一个或多个模型对象组成。
Events
Manager 使用 Event 通知其 Listener 关于网络中的变化，并通过 Store 通知相关的在分布式设置中的 Peer 。一个事件由一个事件类型和一个由对象模型构成的主题组成。例如，一个 device
event 可通知 devicelisteners ， Device( 主题 ) 已经被发现 (device_added) ，失去了 (device_removed) ，或某一方面改变了 (device_updated) 。
Event dispatch
事件是由 Store 基于 Manager 的输入产生的。一旦产生，事件就会通过 storedelegate 接口被分发到感兴趣的听众，最终调用 event
deliveryservice 。从本质上讲， Store Delegate 把事件从 Store 中取出， event
deliveryservice 确保事件仅为感兴趣的听众接收。由于它们之间相互作用的方式，这两个组件驻留在 Manager 中并由那里的 Manager 提供 storedelegate 来做具体实现。
Event Listeners
Event Listener 是实现 EventListener 接口的任何组件。
EventListener 的子接口被按照监听事件的类型进一步的分类。典型的 Event
listener 实现模式是将事件侦听器作为 Manager 或应用程序的内部类，从中从接收到的事件调用相应的服务。这限制了事件处理逻辑不需要对子系统外部进行暴露。
Network representations
模型对象是 ONOS
协议无关方式来表示各种网络元素和属性。事件将这些表示作为它们的主体。这些表示是由 Core 从 Description 中找到的信息来构建的。

Vecloud是一家面向企业提供云交换网络服务为核心业务的技术创新企业，在全球的数据中心节点30个，POP节点超过200个，服务的大客户超过300个，涉及金融、互联网、游戏、AI、教育、制造业、跨国企业等行业领域。http://www.vecloud.com/products/cloudconnect.html