【SDN控制器分析之二】ONOS网络状态表述

概述

控制平面所维护的关键信息是网络状态。控制平面必须聚合此信息，并使其对应用程序可用。此外，为了保持可扩展性和组件重用，应用程序应该免受协议细节的影响，即使网络状态信息是通过特定协议的方式获得的。

ONOS协议不可知的拓扑结构是采用两个互补机制：网络发现和配置来实现的。前者利用网络协议让ONOS识别网络元素的位置和/或性能，在功能使能的情况下会主动开展相关的采集工作。后者允许应用程序和操作人员配置预期的拓扑，或者为网络组件提供提示，这些组件在网络中不能被典型的方法发现。

下一节首先说明ONOS如何表述网络的拓扑结构和状态。然后讨论ONOS是如何建立拓扑的。

对网络进行表述

ONOS维护着相互之间可以转换的协议无关的和协议特定的网络元素以及状态表示。前者是Core层来构建，被称为Model Object，后者是适当Provider来构造。例如，DeviceStore（类推到DeviceManager和Devicelisteners）看到的是一个网络设备，而openflowdeviceprovider将设备作为一个openflowswitch。回想到上一节曾经描述过在Provider和Core之间是通过devicedescription来进行传递的。Model Object是ONOS暴露给应用的。

此外，在可能的情况下，富数据类型是用来代替java基本类型以达到防止歧义提升代码可阅读性的效果。例如，IP地址是由IPAddress 类的描述，而不是一个int来描述，MAC地址使用MACAddress类来描述，而不是字节[]或long类型来表述。这些富数据类型会提供一些转换方法在需要的地方把对象转换成JAVA基本类型。
本节的其余部分侧重于模型对象。
ONOS定义了不同的子系统：

Network Topology
模型中的许多对象具有图形属性，ONOS也正是以有向图来代表网络的。

• Device —— 网络基础设施元素，例如交换机、路由器、接入点或中间盒。设备有多个Interface/Port和DeviceID。Device是网络图的内部顶点。
• Port —— 设备上的网络端口。一个端口和DeviceID对形成connectpoint，它代表一个图的边的一个端点。
• Host —— 网络终端站，其有一个IP地址，MAC地址，VLAN ID，和connectpoint。主机是网络图的外部（叶）顶点。
• 链路 —— 连接两个设备之间（connectpoints）的有向链接。链路是网络图的内边。
• edgelink —— 一个特殊的专门连接主机到设备的Link。edgelinks是网络图的外边。
• 路径 —— 一个或多个相邻的链接的列表，包括EdgeLinks。EdgeLinks，如果在路径，只能是外部链接（在List开始和结束的位置）。
• 拓扑 —— 表示网络遍历图的快照。路径计算对这个图可以使用任意一个图的遍历算法，如BFS、Dijkstra、或者Bellman-Ford。

Port：
端口位于OSI模型的第1层，物理层。这层定义了设备的电气和物理规格，如铜或光纤媒体以及电压、线路阻抗、信号配时、和物理布局引脚连接装置如双绞线、同轴电缆或光纤电缆单模或多模的情况。
Interface：
接口位于OSI模型的第2层，即数据链路层。这一层定义的功能和程序之间的传输网络设备数据的方法，如串口，以太网，FDDI和令牌环。此外，该层可能提供检测和纠正物理层可能发生的错误的能力。

Network Control
在应用程序级，网络的指令表示为高级流规则采用 Criteria (Match) and Treatment (Action)对的形式来表述。一个ONOS实例对任何给定的设备会有一个角色允许或拒绝应用申请更改设备的指令。
FlowRule —— 一个高层次的flow rule，给出一个匹配和动作对。如果需要的话，一个动作可以是一个组合动作。这种抽象是不同于OpenFlow中的Flow Rule的概念，例如，表和OF match-action对的数目。
意图 —— 意图是一个高层级的影响网络流量子集的网络配置或连接的动作。它允许应用程序指定他们想要发生什么，而不是指定他们希望事情发生的方式。
rolevalue —— 表示一个ONOS实例相对于设备的角色。
在意图框架那一节中进一步讨论了操纵网络逻辑及其构造的结构。角色是在集群协调一节进行进一步解释。

Network Packets
网络包，如来自与网络的流量，和那些被注入到网络中的流量，类似于OpenFlow PacketIn和packetout。
outboundpacket —— 合成数据包是协议无关的，表示是从控制器发出到网络上的信息。这些信息包括应该从何处发出该包的信息。
inboundpacket —— 分组协议无关的表示从设备发送到控制器的包。这使控制器可以被动的通过PacketIns提供报文给Provider和应用程序按需使用，例如主机跟踪，链路检测功能。

Model Object Dependencies
有些实体依赖于其他实体的存在，如Port那样，如果没有设备，端口就不能存在。类似地，如果没有作为连接端点的Port，则链路和拓扑不能存在。因此我们认为Device是ONOS网络中最先需要的实体。

Network 发现

鉴于某些类型的设备，链接和主机，网络的拓扑结构可以在没有管理员干预的情况下由ONOS去发现。一个设备被配置为自动使用Openflow协议连接到指定的控制器。当建立了这样一个与后者的一个连接之后，ONOS将“看到”的设备，并将其添加到其网络视图。根据用于建立连接的协议，进一步的情况是，如设备能力和端口号，也可以通过在握手的一系列信息传送给控制器。

为了发现链路和主机，ONOS依赖于收集设备上的信息以及网络设备的配置。本节重点介绍这些元素的发现，因为ONOS对于设备的发现的细节和交互会在DeviceSubsystem进行分析。

Link Discovery
链路是在所有端口上所有受控设备发送的探测帧来逐跳发现的。发送设备的设备id被添加到探针中，以标识链路的一端。另一端是在相邻设备接收探针后，将其送回控制器。例如，给定的设备a和b由同一控制器控制并通过直接链路连接在一起，通过以下步骤找到从A到B的链路：

• 控制器构造一个包含设备id的探针。
• 控制器发送下一个探测packetout指令作为有效载荷。
• a接收指令并将探测发送到所有端口。
• B接收A的探针，并将其发送回控制器。
• 控制器接收它从A和B发送的探针，找而到链路的另一个端点。

反方向的侦测也是按照上述相同的事件进行，从B到A。链路一次发现一个方向，因为链路不能被假定为双向的。

Link Subsystem的接口与设备子系统通过一个lldplinkprovider订阅的deviceservice的deviceevents（即通过实现DeviceListener），来获取相关的OpenFlow功能的设备信息。之后，lldplinkprovider会给发现的每一个Device分配一个linkdiscovery对象。

Linkdiscovery实现实际的是通过LLDP还是BDDP来做链路发现机制。探测速率是毫秒级（默认3000ms），linkdiscovery实例发送含有lldps和bddps探测消息以packetout的形式发出。探测消息在相邻的Switch被截获然后以PacketIns的形式发送给其对应的linkdiscovery实例，对应的探测消息的发送者和接收者会被转换成为Link的源和目的端点。

SDN islands and legacy networks

SDN岛是网络中由SDN控制的一部分网络。岛和岛之间可能由一个或多个传统网络。

LLDP探针发出后会在SDN网络和传统网络之间被丢弃。这可能会阻止两个岛屿之间的连接被发现，从而使控制器相信它管理两个不相交的网络。ONOS像Floodlight一样，用BDDP探针发现岛屿之间的路径。因为传统设备不会丢弃BDDP，他们也不会以任何方式去做修改，而是把报文进行透传。因此，遗留网络之间的连接将以单跳的形式出现，而不管路径上有多少遗留设备。

Control domains
在多域的情况之下，多个独立的控制平面控制网络相邻的域，域不同于SDN岛，后者是由同一个逻辑控制平面来控制的，在前者的情形下，一个ONOS控制器可能会收到不是它所创建的探针信息，控制器会把相关链路标识为Edgelink。

Probe message fingerprinting
ONOS为每一逻辑控制平面添加了指纹识别来标识自己的Cluster。自从ONOS 1.4版本之后把指纹信息添加到探测消息的能力已被添加到lldplinkprovider，以辅助识别外部设备和ID别名。具体地说，指纹被编码到探测消息的源MAC地址中。ProbedLinkProvider接口允许Provider的实现来访问已经被指纹化的MAC地址。指纹是来自一个稳定的集群名称自动生成哈希，集群名称是在这个时候自动生成的。当集群的名字不能确定（可能的情况下如果clustermetadata子系统不可用）时只能使用一个固定的MAC地址（DE:AD:BE:EF:BA:11）。

Host Discovery
设备子系统发现网络主机通过检测PacketIns ARP和DHCP消息，描述其位置的网络设备端口对术语称为connectpoints。hostlocationprovider采用和LLDP同样的机制，通过实现devicelistener实现此功能。