ONOS中主要子系统的组织

0x01 概述

本节介绍ONOS中主要子系统的组织。

• 系统层（System Tiers）
• 服务和子系统（Services and Subsystems）
• 子系统结构（Subsystem Structure）
  • 提供（Provider）
  • 管理（Manager）
  • 存储（Store）
• 事件和描述（Events and Descriptions）
  • 描述（Descriptions）
  • 事件（Events）
  • 网络表示（Network representations）

0x02 系统层

ONOS的架构具有多层功能。我们提供以下图，将在下面的几节中作为讨论摘要：

0x02 服务和子系统

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

ONOS定义了几种主要服务：

• Device subsystem - 管理基础设施设备的清单。
• Link subsystem - 管理基础结构链接的清单。
• Host subsystem - 管理终端主机的清单及其在网络上的位置。
• Topology subsystem - 管理网络图视图的按时间排序的快照。
• PathService - 使用最新的拓扑图快照计算/查找基础设施设备之间或终端站主机之间的路径。
• FlowRule subsystem - 管理基础设施设备上安装的匹配/操作流规则的清单，并提供流量指标。
• Packet subsystem - 允许应用程序侦听从网络设备接收的数据包，并通过一个或多个网络设备将数据包发送到网络上。

下图说明了作为ONOS一部分的各种子系统以及在不久的将来计划的一些子系统：

0x03 子系统结构

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

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

3.1 提供（Provider）

ONOS堆栈的最低层，Providers通过协议特定库与网络连接，通过ProviderService接口与核心连接。

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

某些Provider可能还需要接受来自Core的控制命令，并使用适当的协议特定方法将它们应用于网络。这些都是通过Provider接口将这些内容送入Provider组件。

协议感知Providers负责使用各种控制和配置协议与网络环境交互，并向Core提供服务特定的感知数据。Provider也可以从其他子系统收集数据，将它们转换成特定于服务的数据。

3.1.1 Provider ID

一个Provider与特定的ProviderId相关联。其主要目的ProviderId 是提供一系列Provider的可外部化身份，这允许设备和其他模型实体即使在加载/卸载Provider之后仍保持与负责其存在的Provider的身份相关联。

ProviderId携带一个URI方案名称，允许松散地与另一个provider family中的provider配对，而这没有访问Provider本身是可能的。

3.1.2 Multiple Providers

子系统可以与多个Provider相关联。在这种情况下，Provider被指定为主要或辅助。 主要Provider拥有与其服务相关联的实体，辅助Provider将其信息作为叠加层提供。如果任何叠加导致与底层信息冲突，则此方法给予主要Provider优先权

设备子系统是一种能够支持多个Provider的服务。

3.2 管理（Manager）

管理中心是驻留在核心中的组件，它从Provider处接收信息并将其提供给应用程序和其他服务。它公开了几个接口：

• Northbound Service interface，应用程序或其他核心组件可通过该接口了解特定方面的网络状态
• AdminService interface，将管理员命令应用到网络或系统的状态
• Southbound ProviderRegistry interface，Provider可以通过该接口向Manager注册，以便它可以与之交互
• southbound ProviderService interface，提供已经注册的Provider，可以通过它向Manager发送和接收信息

Manager服务接口的消费者可以同步的查询Service的信息，也可以异步的作为一个事件侦听器（例如，通过使用listenerservice接口注册要监听的事件，并实现相关的EventListener interface）。

3.3 存储（Store）

Store在核心内并与Manager密切相关，Stores的任务是索引，持久化和同步Manager收到的信息。这包括通过直接与其他ONOS实例上的存储通信来确保跨多个ONOS实例的信息的一致性和鲁棒性。在群集协调中可以找到有关分布式设置中存储的进一步讨论 。

3.3.1 Application

应用通过AdminService和Service接口来消费和操作Manager汇总的信息。应用程序具有广泛的功能，从在Web浏览器中显示网络拓扑到为网络流量设置路径。

3.3.2 Application ID

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

并非所有子系统都拥有所有这些组件，并非所有组件都严格遵守这些功能。例如，TopologyProvider纯粹依赖于系统核心与设备和链接的协议无关的表示，并且永远不会直接与基础架构交互，并且CoreService由CoreManager实现，一个只实现服务接口的Service接口Manager。

0x04 事件和描述（Events and Descriptions）

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

4.1 描述（Descriptions）

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

4.2 事件（Events）

Manager使用Event通知其Listener网络中的变化，并通过Stores向通知其对等方分布设置中的Event。一个Event由一个Event类型和一个由对象模型构成的subject组成。例如，一个DeviceEvent可用于通知DeviceListeners，一个设备（subject）被添加（(DEVICE_ADDED)），被移除（DEVICE_REMOVED ）或被更新（DEVICE_REMOVED ）。

4.2.1 Event dispatch

Event由Store根据Manager的输入生成。一旦生成，就会通过StoreDelegate接口将一个Event分派给感兴趣的Listener，最终调用EventDeliveryService。从本质上讲，StoreDelegate将Event从Store中取出，并EventDeliveryService确保事件仅传递给感兴趣的istener。由于它们之间相互作用的方式，这两个组件驻留在Manager中，Manager器在其中向Store提供StoreDelegate的实现类。

4.2.2 Event Listener

Event Listener是实现EventListener接口的任何组件。 EventListener的子接口按照监听Event的类型进一步的分类。典型的Event listener实现模式是将Event listener作为Manager或应用程序的内部类，从中根据接收到的Event调用相应的服务。这限制了Event处理逻辑不需要对子系统外部进行暴露。

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

4.3 网络表示（Network representations）

模型对象是ONOS与各种网络元素和属性无关的协议表示。事件将这些陈述作为其主体。这些表示是根据Core从Description中找到的信息来构建的。

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

参考自System Components
转载请注明出处