ONOS架构-系统组件

系统组件

系统分层

App/core/providers

业务和子系统

一个业务service是有多个组件构成的功能单元，基于各层软件栈提供一个垂直的分片slice，将构成业务service的组件集合称为子系统。业务和子系统可互换使用。

onos定义的业务有：

.设备子系统-管理设备-交换机-资产

.链路子系统-管理链路资产

.主机子系统-管理主机及在网络中的位置

.拓扑子系统-管理网络视图

.路径path---基于最新的拓扑，在交换机之间，或者主机之间计算和发现路径

.流规则子系统-管理应用到交换机上的流规则（匹配和动作match/action），提供流数据(flow metrics)

.报文收发子系统-允许app监听来自交换机的数据报文，以及通过一个多个交换机向网络发送数据报文

每一个子系统的组件都在某个层级中（app/core/providers），可用实现了的一个或者多个java接口标识。

下图描述了子系统组件的关系，上下两个虚线是由南北向接口定义的层级边界。

Provider

三层中最低一层，向网络通过协议特定的协议栈提供接口，向内核通过ProviderService提供接口。

协议感知的provider通过各种网络控制和配置协议和网络交互，向内核提供业务相关的数据，provider也从其他模块收集数据，转换为（本）业务相关数据。

某些provider从内核接收控制指令，并通过协议特定的方式应用到网络，这些通过provider接口传递给provider。

Provider ID

Provider会关联一个ProviderID，用于在同一类Provier中提供外部标识，并允许在provider卸载后交换机或者其他模型实体依然能保留和provider的关联。

ProviderID携带URI，可允许交换机和Provider进行配对，而无需访问provider对象本身。

Multiple Provider

子系统可个关联多个provider，provider有primary和ancillary两种角色，primary拥有关联到业务的所有实体，ancillary类型的privider则以overlay方式提供信息。此种方式，为主要provider提供了某种优先权，处理underlay的冲突信息

Manager

内核模块，从provider接收信息，提供给应用或者其他业务service。

有如下interface

.北向接口，应用和其他内核模块可获取特定网络状态

.AdminService接口，接受管理命令，应用到网络或者系统中

.南向ProviderRegistry接口，Provider通过接口向Manager注册

.南向ProviderService接口，已注册的Provider向Manager接收/发送信息

Manager 业务接口的consumer可通过同步方式（查询业务）和异步方式（事件监听，实现EventListener接口）

Store

在内核，和Manager中，store用于保存，索引，同步manager收到的信息，通过和其他onos实例中的store直接通信，保证跨多个ONOS实例的一致性和健壮性，

Application

应用经由AdminService接口和业务接口操作Manager聚合的数据，应用的范围很广

ApplicationID

每个应用都分配一个唯一的APPID，用于 ONOS跟踪应用的上下文（诸如intent，flow rules这样的任务对象），应用使用CoreService接口注册，提供反转的DNS，名字，从而获取AppID。

注，并非所有子系统都如上操作，也并非所有组件都严格按照如上实现功能，比如TopologyProvider相对系统内核以协议无关方式呈现设备和链路，从不和设备直接交互，由CoreManager实现的CoreService，仅仅是业务接口。

Events and Descriptions

ONOS内核中关于事件分发的两个基本单元是event和description，两者可以经由业务接口，和特定网络元素和概念关联，一旦创建，两者都是不变的（immutable）

Description用于通过南向接口传递信息，比如HostDescription包含主机的mac，ip地址，在网络中的位置（VLANID，交换机和端口），Description通常有model/objects，以及各种网络组件的onos表达，组成。

Event,

Manager使用event来通知监听者网络状态的改变，Store用来通知分布式对端。Event由类型type和表示模型对象的主题subject组成，比如DeviceEvent可用来通知DeviceListener某个设备device（subject）被检测（DEVICE_ADDED），删除（DEVICE_REMOVED），属性变化（DEVICE_UPDATED）

Event分发

由store产生的event，输入来自Manager。一旦产生，将通过StoreDelegate接口分发给感兴趣的监听者，StoreDelegate最终会调用EventDeliveryService接口，StoreDelegate将event从store中移出，EventDeliveryService保证event会到达监听者，由manager实现StoreDelegate的实现类

Event监听

任何实现了EventListen接口的组件都是事件监听器，事件监听器由其所监听的event的子类的类型确定，事件监听器的典型实现是作为Manager或者应用的inner类，根据收到的event调用合适的业务。这个限制了从外部处理子系统到子系统的Manager，或者子系统到应用的event。、

下图描述了description和event以及相关的组件。