ONOS是一个采用OSGI技术来管理子项目的SDN控制器开源项目，在最初设计时有这么几个目标是明确的：
模块化的实现：ONOS项目由一组子项目组成，每个项目都有自己的源代码树，可以独立构建。为此，ONOS的源码采用分层的方式来组织以方便利用Maven的级联POM文件组织。每个子项目都有自己的pom.xml文件和目录，子pom.xml文件会继承父Pom文件的共享依赖项和配置，使它们能够独立于不相关的子项目构建。Root目录包含用于建立完整的项目及其所有模块的顶层POM文件。
特性可配置：ONOS使用Karaf作为其OSGI框架，除了在运行时的动态模块加载和启动时的依赖解析，Karaf还支持以下几个特性。
协议无关，ONOS 被划分为以下几个部分：
上面的每一层都是分层体系结构，其中面向网络的模块通过一个南向（提供者）API与Core进行交互，Core与应用程序通过北向（消费者）API进行交互。南向API定义了协议中立的手段将网络状态信息传递给核心，Core通过面向网络的模块与网络设备交互。北向API为应用程序提供了描述网络组件和属性的抽象，以便它们可以根据策略定义其所需的动作。
服务是一个功能单元，它由不同层的多个组件作为软件堆栈创建垂直切片。我们把组成服务的组件的集合称为子系统。
ONOS定义了不同的子系统：
下图阐述了现在ONOS所包含的各个子系统：
每个子系统的组件驻留在其中的三个主要层次，可以由一个或多个java所实现的接口标识。
下图概述了子系统组件之间的关系。图中的顶部和底部虚线表示分别由北向和南向API创建的层间边界。
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的信息，并将其提供给应用程序和其他服务。它暴露了几个接口：
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中找到的信息来构建的。
