看看有趣的ONOS Ⅴ：设备子系统

设备子系统

总览

设备子系统负责发现和跟踪组成网络的设备，使操作员和应用程序够管控。ONOS的大多数核心子系统都依赖于由该子系统和/或其提供程序创建和管理的Device和Port模型对象与网络进行交互。

设备子系统遵循系统组件描述的体系，其特点是：

• 一个DeviceManager能够通过DeviceProviderService接口与多个Providers程序进行对接，并通过DeviceService接口与多个侦听器进行对接
• DeviceProvider，每个都提供自己的网络协议库或与网络接口的方法的支持
• DeviceStore，它跟踪设备模型对象并生成DeviceEvent

本节重点介绍OpenFlowDeviceProvider，ONOS使用它来与OpenFlow网络进行交互。用于读取光网络的网络配置的OpticalConfigProvider将作为[Packet Optical用例]的一部分进行描述。

Model Objects和Provider表示

回想一下，ONOS在核心层将各种网络组件和属性表示为与协议无关的模型对象，在提供者层将其表示为协议特定的对象。以下是跨两层翻译的主要表示形式：

DeviceManager	OpenFlowDeviceProvider
Device	OpenFlowSwitch
DeviceId/ElementId	Dpid
Port	OFPortDesc
MastershipRole	RoleState

OpenFlow子系统

OpenFlow南行由OpenFlowDeviceProvider和OpenFlow驱动程序组件组成。虽然不是ONOS原本意义上的子系统，但我们将这些组件统称为OpenFlow子系统。 OpenFlow子系统使用Loxi生成的Java协议绑定来实现OpenFlow协议的控制器端行为。因此，当前支持的协议版本为1.0和1.3，前者带有Nicira供应商扩展，以添加角色协商功能。

下图总结了此南向组织方式。

注意：“OF”是“OpenFlow”的简写。例如，上面的OFSwitch的实际名称是OpenFlowSwitch。 当出现异常时，将注意到异常。上面没有显示的是（当前）处于各种状态的Switch对象的三个Switch映射的情况， 以及其他子系统的入口点。

蓝色和绿色块对应于子系统结构下图中的提供者组件和提供者。红色和粉红色块以及带有红色轮廓的块代表同一图中标记为“协议”的红色块的组成（子系统结构）。红色和粉红色块突出显示了在通过TCP连接与基础结构通信中直接发挥作用的组件。

OpenFlow控制器

OpenFlow函数通过OpenFlowController（上图中的OFController）进行编排。该组件存储交换机DPID到对OpenFlowSwitch对象的引用的映射，并生成侦听器（提供者）可以订阅的OpenFlow事件。提供者可以订阅以下一个或多个侦听器：

• OpenFlowSwitchListener — 切换事件的侦听器，例如开关连接和断开。示例：OpenFlowDeviceProvider，OpenFlowLinkProvider。

• OpenFlowEventListener — OpenFlow消息的侦听器。示例：OpenFlowRuleProvider。

• PacketListener — 传入流量数据包（PacketIns）的侦听器。例如：OpenFlowPacketProvider，OpenFlowLinkProvider，OpenFlowHostProvider。

OpenFlowController还负责为其学习的每个Switch对象建立和管理通信通道。连接是由Controller建立的，每个连接的交换机的状态都由OpenFlowSwitchAgent跟踪。具体地说，Controller通过创建一个引用TCP连接的Switch对象（上面标记为“ Channel”），将TCP OpenFlow通道（当前在Netty中的OFChannelHandler）与传入连接相关联。

OpenFlow Switch对象

OpenFlow Switch对象是网络设备的OpenFlow子系统的表示形式，具有一组端口，唯一标识符，设备信息以及对另一端连接的实际设备的通道引用。它是多个接口的组合，实现为一系列OFSwitchImpl类。每个这样的实现都代表一种支持OpenFlow的交换机。例如，OFSwitchImplOVS10是支持OpenFlow 1.0的OpenVSwitch的表示。Switch对象的单个实例表示来自网络的单个OpenFlow连接。

Switch对象具有两种类型的接口：

• OpenFlowSwitch面向北向接口、提供者，以及
• OpenFlowSwitchDriver，朝南向接口、pipeconf、Controller

通常，第一个接口允许提供者（以及间接地，ONOS的其余部分）与Switch对象进行交互，第二个接口处理协议的详细信息，而该协议的详细信息需要（或应该）很少或不需要其他人干预。系统。这些包括各种类型的交换机所特有的OpenFlow握手部分，以及某些形式的传入/传出消息完整性检查。

Switch状态

Switch对象与几种类型的状态相关联。每个状态都有一组与之相关的行为，例如交换机期望接收或发送的控制消息的类型。与交换机相关的两个主要状态是其ChannelState和ONOS实例的role。

OFChannelHandler在ChannelState枚举中实现通道状态FSM。每个枚举值代表OpenFlow握手中的各个点。以下流程图表示此FSM。

状态FSM

该FSM的状态转换由握手期间各种OpenFlow消息的接收驱动，这些消息OpenFlow规范中定义。每个OFSwitchImpl类针对特定类型的交换机实现了特定于驱动程序的握手方面的握手，例如通过1.3交换机交换屏障消息。

ONOS实例的角色描述其对Switch对象的读取和写入权限。在多实例设置中，一个ONOS实例将是一个Master，可以完全控制网络交换机，其余的实例是Equals，仅能从网络交换机读取状态信息。这些角色既在（未显示）的OpenFlowSwitchDriver级别上执行RoleManager，又在群集子系统在与协议无关的级别上执行。
ONOS实例的角色描述了其对Switch对象的读取和写入权限。在多实例设置中，一个ONOS实例将是一个Master，可以完全控制网络交换机，其余的实例是Equals，仅能从网络交换机读取状态信息。角色既由RoleManager（未显示）在OpenFlowSwitchDriver级别实施，也由Cluster子系统在协议中立的级别实施。

Roles在Cluster Coordination进一步讨论。