浅谈OpenDaylight的二次开发

OpenDaylight做为一款开源SDN网络控制器，依托于强大的社区支持以及功能特性，成为了目前主流的SDN网络控制器开发平台。在比较稳定的OpenDaylight Helium版本中，已经为开发者提供了大量的网络管理功能与二次开发接口。可是因为OpenDaylight架构复杂以及开发工具的多样化，形成了二次开发思路不够清晰的问题。本文旨在为读者梳理出一条比较清晰的OpenDaylight二次开发路线，下降OpenDaylight的二次开发难度。

1、 OpenDaylight架构简析

要想清晰的看到OpenDaylight为咱们提供了什么，最直观的方式就是对OpenDaylight架构图进行梳理，如图1：

图1

如你们所知道的那样，OpenDaylight的结构层次从下到上依次划分为数据平面（包括物理交换设备与虚拟交换设备等）、南向接口与协议插件、控制平面（包括核心控制部分与相关服务）、上层网络应用与服务。数据平面设备的相关技术开发已经超出了OpenDaylight二次开发范畴，所以咱们的目光限定在南向协议与插件、控制器服务与上层应用的开发。整体来讲，OpenDaylight的二次开发能够分为如下三个层面：

• 基于OpenDaylight REST APIs的上层网络应用开发
• 基于SAL内核相关服务的控制器组件与上层网络应用开发
• 基于SAL内核相关服务的南向协议插件开发与上层服务接口开发

固然，若是进行更具体的划分，每一个层面还能够划分出更多的开发方向，可是就大的开发方向来讲，主要使用以上三种开发模式。

下面简单介绍一理图1中的数据平面，以帮助读者理解咱们的SDN网络控制器功能实现的具体场景。在该图中咱们能够看到肯定的设备主要有实现OpenFlow功能的物理设备与承载Open vSwitch的虚拟交换设备，下面分类介绍一下：
实现OpenFlow功能的物理设备：通常为提供多网络接口的物理交换机，在交换机操做系统上实现对OpenFlow协议的支持，固然在混合方式交换机上能够实现传统的交换转发方式。实例包括Cisco的IOS交换机操做系统，Broadcom的ICOS交换机操做系统等。

承载Open vSwitch的虚拟交换设备：此处所指的虚拟交换设备能够是咱们在物理交换机虚拟化出的虚拟交换机，也能够是咱们在实验环境下搭建的模拟交换设备。比较典型的应用就是咱们在进行SDN实验时所使用的mininet模拟网络搭建工具，其实质就是使用Python语言对Open vSwitch的功能进行封装，为用户提供网络建立、删除、更新与属性控制等功能。

2、OpenDaylight的上层网络应用及北向插件开发

对于OpenDaylight二次开发这个层面来说，通常所作的最多的是对OpenDaylight的Web可视化界面进行修改，同时进行更多的数据展现与添加功能操做控件。对于这些需求的开发，咱们须要使用的是SAL提供的基础服务，调用他们所提供的REST APIs，或者使用SAL提供的基础服务开发本身的服务接口，而后在上层使用各类开发语言与开发工具进行相对应功能的开发。开发框架图如图2所示：

图2

1. SAL是什么？

SAL的全称为Service Abstraction Layer（服务抽象层），分为MD（Model-Driven）与AD（Application-Driven）两种。SAL为整个OpenDaylight项目框架提供基础设施服务，包括了各类OpenDaylight开发须要用到的基础功能，相似于Linux内核。AD-SAL与MD-SAL并无本质上的区别，只是API消费者与供应者之间的查询路由方式有所区别。在AD-SAL中，并无使用YANG对相关请求与通知功能进行建模，而是直接静态地使用了Java APIs进行路由与适配。在MD-SAL方式中，首先须要使用YANG对南向插件须要实现的功能建行功能建模，再使用YangTools与Maven生成相关Java APIs，经过对模型的查询来动态地进行路由与适配。相关信息能够参阅OpenDaylight的开发者手册：
Page 51, OpenDaylight Developer Guide Helium SR2

2. 基于OpenDaylight REST APIs的上层网络应用开发

基于OpenDaylight REST APIs进行上层网络应用开发，是三个开发层面中相对来讲最简单的一种方式。直接调用OpenDaylight REST APIs进行开发，可使开发者屏蔽掉底层复杂的功能实现，而专一于功能的创新与开发。可是直接使用API进行开发仍旧不够简便，由于须要进行大量的GET/POST等操做，所以，能够在查询到API的基础上，将相相似的功能用开发语言进行封装，作出SDK，从而提高开发效率。

使用这种方式的关注点更多集中于Web可视化界面的开发，下面就几种主流Web开发框架作一下讨论：

• Python + Django：笔者目前从事的研究主要是OpenDaylight与OpenStack功能进行对接，所以更多的关注这种架构的实现。Django是一种基于MTV的Web开发框架，OpenStack的Horizon界面项目是基于这种框架进行开发的。另外，OpenStack的整个工程项目都是使用Python进行开发，所以，使用Python + Django的开发方式能够比较好的实如今OpenStack云平台中加载OpenDaylight网络管理功能与界面添加。
• LAMP：PHP是一种便捷的网络后端开发语言，有强大的函数库与简洁的调用方式，若是单纯基于OpenDaylight进行Web UI的开发，这种选择不失为一种良好的方案。
• Java Spring：Java Spring是一种基于MVC的Web开发框架，使用这种方案的优势是OpenDaylight内核使用Java进行开发，当咱们须要开发本身的插件为上层应用提供接口的时候，这种方式比较便于接口的对接。如图2中的应用B所示。

下面简单列出一些经常使用的API模块，供读者参考，具体API挂载点会因版本不一样而略有差别，在此再也不列出，只介绍相关功能：

表1 OpenDaylight SAL层经常使用API模块

以上简单罗列了经常使用的API模块，更多具体信息读者能够自行查询相关文档。经常使用的API挂载点通常具备以下形式：http://127.0.0.1:8080/controller/nb/v2/topology/default。同时，使用API获取的返回数据通常为XML/JSON形式，因此建议使用相关开发工具先进行数据解析，而后封装为SDK以提高开发效率。

实践参考：https://www.sdnlab.com/11480.html

3. 基于SAL内核相关服务及北向插件的控制器组件与上层网络应用开发

在上一小节中，咱们讨论了如何利用OpenDaylight已有的REST APIs进行上层网络应用的开发，这种方式能够说是依赖于OpenDaylight平台的外部开发，并不是嵌入OpenDaylight内部的应用开发。这种开发方式能够实现的关键是OpenDaylight已经为咱们提供了相应的开发接口，但若是现有的OpenDaylight没有为咱们提供相关的接口，这就须要咱们进行更深一层次的开发，即基于SAL内核相关服务进行所需的控制器组件与上层网络的应用开发。

本小节所述的基于SAL内核相关服务的控制器组件与上层网络应用开发方式通常的应用场景是上层网络应用程序须要借助已有的SAL相关服务及南向插件/协议实现某些特定的功能，而该功能并未由OpenDaylight控制器给出REST API，如图2所示的应用B的开发。这种方式相对来讲更能够称的上是OpenDaylight的二次开发。在介绍具体内容以前，首先须要了解如下储备知识：

• OSGi与OSGi组件：OpenDaylight平台的后台。为整个工程项目提供了模块化管理的方式，即OSGi组件。每一个组件能够实现某些特定的功能，并加载到工程的运行环境中。
• Maven工具：Maven工具是用来实现对于OpenDaylight整个工程项目进行管理控制的工具。能够用Maven生成不一样的项目，不一样的组件。每个Maven项目包含一个项目控制文件pom.xml，一个src文件夹，一个test文件夹。一般pom.xml文件使用结构化的文档来对整个项目的属性配置、外部依赖、编译进程与外部输出等进行设置，实现了工程的自动化管理。在src文件夹内包含项目或组件相关的源程序，test文件夹中包含相关测试程序。Maven是该小节所述的开发方式的基础，读者能够参考官方网站的文档进行学习。
• Apache Karaf：Karaf工具是基于OSGi的OpenDaylight特性容器，用于实现OpenDaylight各功能组件的热插拔。

基于SAL内核相关服务的控制器组件与上层网络应用开发须要借助于OpenDaylight开发平台已经实现的模块与组件，调用其Java APIs以帮助实现咱们所须要的功能。下面简单罗列一下OpenDaylight为咱们提供的相关编程服务接口：

表2 OpenDaylight模块/组件列表

完整组件列表能够查阅：https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces

鉴于MD-SAL的复杂性，咱们将在下一小节进行重点讨论，在本小节咱们将主要关注基于AD-SAL来实现北向应用插件的开发。流程图以下：

在上述流程图中须要实现的各个步骤都涉及到了多种文件的配置与工具的使用，请有兴趣的读者自行查阅相关文档了解相关设置.能够参考如下文章。

实践参考：https://www.sdnlab.com/11456.html

3、OpenDaylight的南向插件/协议开发

在上一小节中，咱们讨论了如何基于AD-SAL以及相关北向插件服务进行特定应用北向插件的开发，在这种开发方式中，主要是使用的AD-SAL服务。在接下来的章节中，咱们主要介绍一下基于MD-SAL进行南向插件的开发。

OpenDaylight的南向插件，又叫作南向协议插件，主要承担如下任务：

• 处理控制器与南向网络设备之间的会话
• 提供多种接入网络设置功能的抽象接口

基于MD-SAL的南向协议插件开发方式是咱们横向拓展OpenDaylight功能的实现方式，是一套从底层到上层的完整功能开发路线。与前两种开发方式不一样的是，咱们须要实现的功能在现有的OpenDaylight并未提供太多的功能实现，必须依赖于工业标准或者自主开发的协议算法，在南向插件层进行功能添加，并将插件绑定在SAL上，从而能够转入前述的两种开发方式中。具体开发流程如图4所述：

图4

此处关于插件与SAL交互及其工做方式不作介绍，有兴趣的读者能够参考：
Page 54, OpenDaylight Developer Guide Helium SR2

由上图咱们能够看出，整个MD-SAL南向插件开发的第一步源自于对于所要实现功能的YANG建模。YANG是用于对南向协议插件具体功能实现进行服务接口封装的工具，经过进行YANG建模与Yang Tools工具的配合，咱们能够产生须要功能的Java API，再通过Maven的编译能够产生JAR包做为OSGi组件插入到控制器中。此时，南向协议插件的服务就能够被其它插件经过API调用开发。

在另外一方面，经过编写Java源代码来具体实现咱们所要添加的协议或者工业标准的功能，经过Maven编译工具生成JAR包做为OSGi组件插入到控制器中。这样，在其它插件调用相对应的Java API时，就能够依据必定的路由方式及查询方式来映射API与功能实现。实现上层应用对所添加功能的调用。

4、总结

在本文中，咱们简单介绍了OpenDaylight二次开发的三种方式，更多的详细叙述读者能够参阅开发者手册与相关源代码。本文所提出的三种方式针对不一样的应用场景，具体方式的选择能够参考下图：

本文帮助读者梳理了OpenDaylight的二次开发路线，但愿读者在读完本文以后对于OpenDaylight的二次开发有个更加清晰的认识。基于OpenDaylight复杂的软件架构，仅仅了解以上的内容是远远不够的，须要结合更多具体的代码进行实践学习，在实践中掌握OpenDaylight并开发出好的SDN控制器。

后记

这篇文章是在接触OpenDaylight一段时间以后的一个阶段性总结，主要是帮助本身以及处在OpenDaylight开发入门阶段的朋友可以清晰地了解咱们在OpenDaylight能作些什么而且如何去作。但这篇文章毕竟只是个概略性地介绍与梳理，在后续的研发中，还须要不断地结合代码去实践这些开发理念。同时，在写这篇文章的时候，仍是感受到本身有许多的不足，所以，文章不免出现疏漏，但愿读者可以帮助纠正，你们共同进步。

做者简介：

郝鹏（fabirdblue@foxmail.com），毕业于美国宾夕法尼亚大学，电子工程硕士，从事SDN相关研发工做。