ONOS 设计目标

ONOS是一个采用OSGI技术来管理子项目的SDN控制器开源项目，在最初设计时有这么几个目标是明确的：

• 代码模块化：支持把新的功能作为新的独立单元引入
• 特性可配置：无论是在启动还是运行时，支持动态加载和卸载特性
• 协议无关：应用不需要和具体的协议库和实现绑定

模块化的实现：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子系统-允许应用程序监听从网络设备接收到的数据包，并通过一个或多个网络设备向网络发送数据包。

下图阐述了现在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的信息，并将其提供给应用程序和其他服务。它暴露了几个接口：

• 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中找到的信息来构建的。