看看有趣的ONOS Ⅲ：系统组成

Posted 2023-03-23

参考技术A

说明：翻译自 ONOS wiki 的 System Components ，自学使用

ONOS的架构由功能层组成。如下图所示：

服务 service 是功能的一个单元，由多个组件组成，这些组件通过软件堆栈在层之间创建垂直切片。我们将组成服务的组件集合称为 子系统 subsystem 。在本指南中，我们将术语“service”和“subsystem”互换使用。

ONOS定义了几种主要服务：

下图说明了现有和未来部署计划中ONOS的各种子系统：

子系统的每个组件都位于三个主要层之一中，并且可以由它们实现的一个或多个Java接口来标识。

下图总结了子系统组件的关系。图中的顶部和底部虚线分别表示由北向和南向API创建的层间边界。

Provider是ONOS堆栈的最低层，通过特定于协议的库与网络形成接口，并将 ProviderService 作为与core层的接口。

协议感知Provider负责使用各种控制和配置协议与网络环境进行交互，并将特定于服务的感觉数据提供给核心。提供者还可以从其他子系统收集数据，将其转换为特定于服务的数据。

一些Provider可能还需要接受来自核心的控制命令，并使用适当的协议特定手段将其应用于网络。这些通过 Provider 接口馈入Provider。

Provider与 ProviderId 关联。 ProviderId 可以提供Provider族的可外部化的身份，即使在其被卸载或Provider被卸载之后，设备和其他模型实体也可以与负责其存在的Provider的身份保持关联。

ProviderId 带有URI方案名称，以允许将设备与备用提供商系列的提供商进行松散配对，并且无需访问Provider本身就可以做到这一点。

一个subsystem可能与多个Provider相关联。在这种情况下，Provider被指定为 primary 或 ancillary 。Primary provider拥有与其服务关联的实体，而ancillary provider则将其信息作为overlays提供。如果任何overlay导致与underlay信息冲突，则此方法将优先考虑主要provider信息。

Device Subsystem就是这样一种能够支持多个provider的服务。

Manager是驻留在core的组件，它从provider接收信息并将其提供给应用程序和其他服务。它公开了几个接口：

Manager服务接口的使用者可以通过查询服务同步接收信息，也可以作为事件侦听器异步接收信息（例如，通过使用 ListenerService 的 Service 的一部分接口注册事件并实现用于接收事件的 EventListener 接口）。

同样在core内并且与Manager密切相关，Store还具有索引、持久化和同步Manager收到的信息的任务。这包括通过与其他ONOS实例上的存储直接通信来确保跨多个ONOS实例的信息的一致性和鲁棒性。在 Cluster Coordination（集群协调） 中可以找到更多有关分布式环境中存储的讨论。

Application通过 AdminService 和 Service 接口使用并操作管理器汇总的信息。Application具有很多功能，可以从在Web浏览器中显示网络拓扑到设置网络流量的路径。

每个应用程序都与一个唯一的 ApplicationId 关联。ONOS使用此标识符来跟踪与Application关联的上下文（例如，任务和目标，例如意图和流程规则）。为了获得有效的ID，Application向 CoreService 进行注册并提供其名称，该名称应遵循反向DNS表示法，例如 org.onlab.onos.fwd 。

ONOS中信息分发的两个基本单位是事件和描述。与服务一样，事件和描述与特定的网络元素和概念相关联。一旦创建，两者都是不可变的。

描述用于通过南向API传递有关元素的信息。例如， HostDescription 包含有关主机的MAC和IP地址及其在网络中的位置（VLAN ID和设备/端口连接点）的信息。描述通常由一个或多个模型 object （各种网络组件的ONOS表示）组成。

Manager使用Event来通知其侦听器有关网络中的更改，Store使用Event来通知其对等对象分布式设置中的Event。Event由事件类型和由模型对象构建的主题组成。例如，可以使用 DeviceEvent 通知 DeviceListeners 设备（主题）已检测到（ DEVICE_ADDED ），丢失（ DEVICE_REMOVED ）或设备的某些方面已更改（ DEVICE_UPDATED ）等。

Event是由Store根据Manager的输入生成的。生成事件后，就会通过 StoreDelegate 接口将Event分配给感兴趣的侦听器，该接口最终会调用 EventDeliveryService 。实际上， StoreDelegate 将Event移出商店，并且 EventDeliveryService 确保事件仅到达感兴趣的侦听器。由于它们的交互方式，这两个组件驻留在Manager中，其中Manager的向商店提供 StoreDelegate 的实现类。

Event Listener是实现 EventListener 接口的任何组件。 EventListener 子接口 Event 按其侦听的子类的类型进行分类。典型的实现方式是事件侦听器是管理器或应用程序的内部类，根据接收到的事件从中调用适当的服务。这将子系统外部事件的处理限制在子系统的管理器或应用程序（即应处理它们的逻辑位置）中。

下图详细说明了上图，以显示“Descriptions”，“Events”和此处描述的组件之间的关系。

模型对象是各种网络元素和属性的ONOS协议无关表示。事件将这些表示作为主题主体。这些表示是根据系统核心在“描述”中找到的信息构建的。

有关网络表示的进一步讨论可以在 Representing Networks（表示网络） 中找到。