浅谈OpenDaylight的二次开发
OpenDaylight作为一款开源SDN网络控制器，依托于强大的社区支持以及功能特性，成为了目前主流的SDN网络控制器开发平台。在比较稳定的OpenDaylight Helium版本中，已经为开发者提供了大量的网络管理功能与二次开发接口。但是由于OpenDaylight架构复杂以及开发工具的多样化，造成了二次开发思路不够清晰的问题。本文旨在为读者梳理出一条比较清晰的OpenDaylight二次开发路线，降低OpenDaylight的二次开发难度。
一、 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的功能进行封装，为用户提供网络创建、删除、更新与属性控制等功能。
二、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
三、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与功能实现。实现上层应用对所添加功能的调用。
四、总结
在本文中，我们简单介绍了OpenDaylight二次开发的三种方式，更多的详细叙述读者可以参阅开发者手册与相关源代码。本文所提出的三种方式针对不同的应用场景，具体方式的选择可以参考下图：
本文帮助读者梳理了OpenDaylight的二次开发路线，希望读者在读完本文之后对于OpenDaylight的二次开发有个更加清晰的认识。基于OpenDaylight复杂的软件架构，仅仅了解以上的内容是远远不够的，需要结合更多具体的代码进行实践学习，在实践中掌握OpenDaylight并开发出好的SDN控制器。
后记
这篇文章是在接触OpenDaylight一段时间之后的一个阶段性总结，主要是帮助自己以及处在OpenDaylight开发入门阶段的朋友能够清晰地了解我们在OpenDaylight能做些什么并且如何去做。但这篇文章毕竟只是个概略性地介绍与梳理，在后续的研发中，还需要不断地结合代码去实践这些开发理念。同时，在写这篇文章的时候，还是感觉到自己有许多的不足，因此，文章难免出现疏漏，希望读者能够帮助纠正，大家共同进步。