ONOS调研报告

1 SDN简介和组成部分

SDN即软件定义网络（Software Defined Network, SDN ），是emulex网络一种新型网络创新架构，是网络虚拟化的一种实现方式，其核心技术openflow通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制，使网络作为管道变得更加智能。

主要包括五个部分

1.1 SND网络设备

网络设备(硬件网络设备或x86里面的软件网络设备，如vSR/vFW等)+SDN能力(可以是SDN芯片或开启SDN功能)。

1.2 SDN控制器

能处理SDN功能的控制器，可以是软件方式或软件嵌入硬件的方式。常见的有：floodlight、POX、NOX、OpenDaylight、Ryu、NSX等。

1.3 SDN APP

这更像是我们熟悉的网络上层功能，例如QOS、路由功能、Overlay功能等等。相比于传统网络，原本孤立的管理/配置如今被SDN统一化了，一个APP代表了整个SDN管理域内的所有此APP功能。好处就好比，网络出口要防DDOS攻击，调用了一个APP就能自动做黑洞引流操作;又好比，领导要开视频会议，调用一个QOS的APP就能全局做带宽质量保障;又例如，通过SDN负载均衡APP，可以实现根据不同业务/参数进行负载轮询。

1.4 南向控制协议

这里场景的控制协议是Openflow，但绝非仅仅Openflow。可以实现控制功能的协议其实很多，除了最知名的Openflow以外，还有：Netconf、PCEP、LISP、MP-BGP、SNMP等等。

1.5 北向API

此API的主要作用在于提供SDN控制器及其以下部分(南向控制协议、网络设备)能够作为网络驱动供上层应用调用。此上层应用可以是各种APP，同样也可以是Openstack、vCloud等云管理平台。

2 ONOS特色

2.1 ONOS特色介绍

白皮书中介绍，一个操作系统应具备下述功能

1，为用户管理有限的资源。

2，隔离和保护NOS用户。需要操作系统能复用多个应用和多个设备。

3，提供一个可用的抽象层让用户灵活的使用操作系统所管理的服务和资源，并且无需了解网络的复杂性。

4，为外部操作系统提供安全保障。

5，提供敏捷高效的服务，那么用户就不需要创建、重建相同的服务。

这些都是网络应用所需要的。通常控制器的所控制的范围十分局限，通常设置为控制一个设备。ONOS具备一个操作系统所具备的所有功能，不仅仅是控制器的功能，例如可以提供高效敏捷的抽象层，能够将不同的控制器使用者隔离开来，能够提供有价值的服务等等。ONOS实现了高可用、可扩展的系统设计方案，基于此基础上对系统的层次结构以及网络实体进行高度抽象，这种优秀的设计和高度的抽象保障了系统的演进和能够被优化得更快更有效。ONOS的设计理念是能在任何硬件（包括白牌机）上灵活的创建服务并且大规模部署，因其可靠性强，性能好，灵活度高的特点适用于面向服务提供商和企业骨干网，它不仅可以满足运营商提供敏捷和灵活的需求，并且有可能使其摆脱设备供应商的束缚，因此很多运营商愿意接受ONOS。缺陷目前使用不够广泛，还没有很好的证明自己。

3 ONOS架构

3.1 ONOS架构图

如下图是ONOS的架构图

3.2 北向接口抽象层

ONOS架构中有两个强大的北向抽象层：意图框架和全局网络视图。意图框架屏蔽服务运行的复杂性，允许应用向网络请求服务而不需要了解服务运行的具体细节，这就意味着网络运营商和应用开发者可以进行高级编程。意图框架处理所有应用的请求，判断可以满足哪些应用，解决应用之间的冲突，执行管理者的策略，对网络编程提供请求的功能，交付请求的服务给应用。全局网络视图为应用提供了网络视图，包括主机、交换机以及网络相关的状态参数，如利用率。应用可以通过APIs对网络视图进行编程，一个API可以为应用以网络图的形式提供网络视图。

3.3 分布式核心

ONOS可以作为服务部署在服务器集群上，在每个服务器上运行相同的ONOS软件，因为对称性部署是一项很重要的设计考量，可以在ONOS服务器发生故障时可以快速地进行故障恢复。而且网络运营商可以在不发生中断的情况下添加服务器，轻松地扩容控制平面处理能力。ONOS实例协同工作形成被其它网络和应用视作单一的平台。应用和网络设备无需知道是和单一的ONOS实例交互还是和多个ONOS实例交互。这一特征实现了ONOS的可扩展性，可以无缝扩充ONOS容量。分布式核心提供实例间的通信、状态管理，领导选择等服务。事实上，多个实例表现为一个逻辑实体。通过使用Publish/Subscribe模型中的高速消息，ONOS实例可以将更新信息快速通知给其他实例。对设备而言，只有一个主ONOS实例，如果这个主实例出现故障，则连接另一个实例，无需重新创建新实例并重新同步流表。对于应用而言，可以通过网络图形抽象层持续获取网络的视图。此外，实例故障和数据平面的故障对应用来说是透明的，这样可以极大地简化应用开发和错误处理。

3.4 南向接口抽象层

南向抽象层由网络组件构成，例如交换机、主机或是链路。ONOS的南向抽象层将每个网络组件表示为通用格式的对象。分布式核心可以实现南向接口协议和设备无感知。这个网络组件抽象层允许添加新设备和协议，以可插拔的形式支持扩展，插件根据规格映射（或翻译）通用网络组件描述或操控设备，反之亦然。所以，南向接口确保ONOS控管多个不同的设备，即使它们使用不同的协议(openflow,netconf)。ONOS通过协议与设备连接，协议细节被网络组件插件或适配器屏蔽。事实上，南向接口的核心是在不知道具体协议细节和网络组件的条件下维护网络组件对象（设备、主机、链路）。通过适配层API，分布式核心可以与网络组件对象状态保持一致，适配层API将分布式核心与协议细节和网络组件相隔离。

3.5 软件模块化

软件模块化是ONOS一大特征，基于软件的形式可以很方便地进行添加、改变和维护。 ONOS的主体架构是围绕分布式核心的分层架构。所以，从宏观结构上说，北向接口与南向接口API将应用、分布式核心和适配层相互隔离，可以独立添加新的应用和协议适配器。从具体细节来看，分布式核心内部的子结构也能体现模块化特征，分布式核心的存在价值就是约束所有子系统的规模并保证模块的可拓展性。此外，连接不同模块的接口是至关重要的，允许模块不依赖其他模块独立更新。这样就可以不断更新算法和数据结构，并且不会影响整体系统或是应用。显然，ONOS很重视接口，因为接口可以促进模块业务和职责的分离，尽量使子系统之间的交互更为自然、简单。这一特点是确保软件稳定更新的关键。

ONOS源代码的树形结构不仅仅为了遵循而是要加强这些结构原则。合理控制模块大小并且模块之间保持适当依赖形成一个非循环的结构图，模块之间通过API模块相互关联。

4 ONOS功能

ONOS具有下述核心功能：

4.1 分布式核心平台

分布式核心平台，提供高可扩展性、高可靠性以及高稳定性能，实现运营商级SDN控制器平台特征。ONOS像集群一样运行，使SDN控制平台和服务提供商网络具有网页式敏捷度。

4.2 全局网络视图

ONOS含有全局网络视图功能，在集群中通过ONOS服务器管理和共享网络状态。提供一个对应底层网络的网络视图。当网络视图信息发生变化时，将变化消息发送到相应的Openflow控制器并下发到指定的交换机上。

4.3 ONOS多实例

ONOS运行在多个服务器上，每个作为专属的master openflow控制器，管理网络子集中的交换机，当数据平面容量增长或者在控制平面需求增长时，附加的ONOS实例可被添加入集群中分发控制平面的负载，体现了良好的可扩展性。

4.4 ONOS容错能力

ONOS有很好的容错能力，因为ONOS有一个Master实例控制还有很多冗余实例，所以当有一个实例失败时zookeeper会选择另一个ONOS实例来接管此交换机。

4.5 北向接口抽象层APIs

北向接口抽象层/APIs，图像化界面和应用提供更加友好的控制、管理和配置服务，抽象层也是实现网页式敏捷度的重要因素。

4.6 南向接口抽象层APIs

南向接口抽象层/APIs，可插拔式南向接口协议可以控制OpenFlow设备和传统设备。南向接口抽象层隔离ONOS核心平台和底层设备，屏蔽底层设备和协议的差异性。且南向接口是从传统设备向OpenFlow白牌设备迁移的关键。

4.7 软件模块化

软件模块化，让ONOS像软件操作系统一样，便于社区开发者和服务提供商开发、调试、维护和升级。总结下来好处具有以下几点：保证架构的完整性和连贯性、简化测试结构，允许更多的集成测试、减小系统某部分改变的负面影响，从而降低维护难度、组件具有可扩展和可定制的特性、规避循环依赖的情况。

5 ONOS技术实现

5.1 ONOS使用的开源软件

ONOS的第一个模型使用了若干的开源软件来构建整个系统。如使用FloodLight的一些现有模块，如switch manger、I/O loop、link discovery、module management、以及REST API。也使用到了Zookeeper, Titan, Cassandra以及Blueprints等开源软件。

5.2 ONOS使用的技术

ONOS维持了一个全网拓扑试图，从而允许一个ONOS集群内的实例能相互之间分享和管理网路信息。其全网拓扑信息包括switch、port、link和host等信息。ONOS使用Titan graph database来存储，并使用Cassandra 来保障分布式和可持续性。由于Cassandra具有一致性存储的特性，所以保障了网络试图的最终一致性。

ONOS使用Zookeeper来存储交换机和控制器之间的关系数据。每一个ONOS实例都需要连接Zookeeper。Zookeeper曾经是Hadoop的一个子项目。现在已经好似一个顶级项目。它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

RAMCloud中文名字应该叫“内存云”，顾名思义，使用内存来代替普通硬盘来存储，从而大大提高存储速度。 Optimized Data Model： 优化向来都是一个复杂的事情。他们新设计了一个data model，也不追求数据完整性了，许多更新都是相对独立的，从而大大减少了数据的读写操作，优化了性能。

读取拓扑是一个非常耗时的操作，所以新的ONOS将拓扑信息存在高速缓存中，从而提高了读取拓扑的速度。前面已经提到由于周期获取数据而引起的性能问题，所以一个事件通知机制非常必要。模型二创建了一个实例内部的发布-订阅的事件机制，然后将这个通信系统部署在了Hazelcast上，发布订阅模式无需赘述。

ONOS用自己设计的API取代了生成的Blueprints graph API。Figure4展示了网络视图所包含的内容。ONOS的API主要由以下三个主要部分组成：对底层设施拓扑的抽象描述接口，处理网络或系统Events（事件）的接口，提供安装流表等信息的接口。