一、OpenDaylight应用基础开发（介绍）

1 SDN介绍

SDN：Software-Defined Networking 软件定义网络

1.1 SDN起源

Clean Slate课题：2006年，美国斯坦福大学启动了一个名叫Clean Slate的研究课题。当时网络从最初的小型专用局域网络，变成了空前庞大和复杂的世界级网络。网络规模的持续扩张，网络设备的不断增加，超过了早期设计的承受能力，也使得网络维护变得举步维艰。由此设立了Clean Slate课题，来解决这些问题，探讨未来网络的可能性架构。

2011年，由Google、Facebook、微软等公司共同发起成立了一个对SDN影响深远的组织，那就是ONF（Open Networking Foundation，开放网络基金会）。ONF的主要发起成员是德国电信、Facebook、Google、微软、雅虎等公司。这些公司要么是网络服务提供商，要么是运营商，没有一个是来自设备商的。他们成立ONF的目的，是为了推动SDN和OpenFlow协议的发展。他们希望SDN这个网络新技术不要被设备商控制，成为设备商的赚钱工具。上述发起人里面，最值得一提的是Google。

2010年，Google开始将数据中心与数据中心之间的网路连线（G-scale），转换成SDN架构。整个改造分为三个阶段。到了2012年，整个Google B4网络完全切换到了OpenFlow网络。改造之后，Google B4网络的链路带宽利用率提高了3倍以上，接近100%。

2013年4月8日，在Linux基金会的支持下，作为网络设备商中的领导者，Cisco与IBM、微软等公司一起，发起成立了开源组织OpenDaylight，共同开发SDN控制器。OpenDaylight强调SDN控制器不仅仅局限于OpenFlow，而是应该支持多种南向协议。同时，OpenDaylight还强调，应该用分布式的控制平台，取代单实例的控制器。这样可以管理更大的网络，提供更强劲的性能，还能增强系统的安全性和可靠性。由此诞生了一些列厂家自研发的SDN控制器。

未来发展：
未来，随着网络规模的扩大，SDN控制器肯定会继续往分布式的方向发展。控制器之间的分工协作会更加深入，甚至可能出现集群。控制器也会引入NFV虚拟化技术，与OpenStack等云平台进行整合。

1.2 什么是SDN?

即把控制面从转发面分离出来，控制面控制多台设备。 SDN是新兴的网络技术构架，具有动态可管理，高适应性，以及优秀的成本效益，以满足今天高带宽应用的动态需求。SDN架构解耦网络控制层和转发层，通过对网络控制的直接编程，使得基础网络承载可以被抽象成各种可为上层应用调用的服务。 OpenFlow® 协议是SDN解决方案的基本要素。

传统网络中，各个转发节点都是独立工作的，内部管理命令和接口也是厂商私有的，不对外开放，各个节点各自实现自己对数据的控制转发。

SDN网络，就是在网络之上建立了一个SDN控制器节点，统一管理和控制下层设备的数据转发。所有的下级节点，管理功能被剥离（交给了SDN控制器），只剩下转发功能。

控制和转发分离之后，借助规范化的API接口，用户可以通过编写软件的方式，对网络进行管理。整个网络，就像个完整的机器人一样可供驱使。

1.3 SDN三层架构

上北下南，SDN控制器向上与应用平面进行通信的接口，叫做北向接口，也叫NBI接口（northbound interface）。SDN控制器向下与数据平面进行通信的接口，叫做南向接口，也叫CDPI接口（control-data-plane interface，控制数据平面接口）。

北向接口相对来说比较好搞，麻烦的是南向接口及其协议。因为它直接影响到SDN控制器的命令能否准确下达到无数的底层网络设备。

因此，SDN技术的发展史，简而言之，就是围绕SDN控制器和南向接口的“王位争夺史”。

2 OpenDaylight介绍

2.1 什么是OpenDaylight

2013年，由Linux Foundation和多家网络巨头如Cisco、Juniper和Broadcom 等公司一起创立开源项目OpenDaylight (ODL)， OpenDaylight是SDN开发及运行的平台。

2.2 ODL发布的版本

https://wiki.opendaylight.org/view/Release_Plan

2.3 ODL平台架构

南向通过 plugin 的方式来支持多种协议，包括OpenFlow1.0、1.3，BGP-LS 等。这些模块被动态挂载到服务抽象层（SAL），SAL 为上层提供服务，将来自上层的调用封装为适合底层网络设备的协议格式。

控制器为应用（App）提供开放的北向 API。支持 OSGI 框架和双向的 REST 接口。OSGI框架提供给与控制器运行在同一地址空间的应用，而 REST API 则提供给运行在不同地址空间的应用。所有的逻辑和算法都运行在应用中。

2.4 ODL各子项目依赖关系

1. 确定项目类型是平台架构部分、还是南向插件部分、还是业务功能部分
2. 如何使用这些项目
3. 项目是需要依赖哪些项目的

2.5 ODL架构特点

• 基于OSGi的模块化设计
• 多南向协议-OpenFlow，Netconf，OVSDB…
• 模型驱动的业务抽象层(MD-SAL)是ODL的核心
• 全分布式的消息及存储机制

3 OpenDaylight初步实践

3.1 实验环境

两台互通的虚机：一台Ubuntu 16.04桌面版，上面已经下载了ODL Oxygen-SR1版本karaf-0.8.1（OpenDaylight控制平台），另一台Ubuntu 14.04版本，已经安装了mininet 2.2.0版本（虚拟网络设备资源）

3.2 实验目的

• 了解并掌握ODL的启动方式，JVM的参数配置
• 了解并掌握bundle，feature，log等基本的命令使用
• 了解并掌握karaf的基本配置

3.3 ODL的下载和运行

下载：
已发布最新版本下载地址：http://docs.opendaylight.org/en/latest/downloads.html
运行：
启动参数配置：修改Java虚拟机运行内存，karaf启动方式，启动参数（clean,debug…）

4 代码层面知识

4.1 OSGI（规范）

OSGi（Open Service Gateway Initiative，直译为“开放服务网关”）实际上是一个由OSGi联盟发起的以Java为技术平台的动态模块化规范，OSGi不是一个应用层面的框架，而是设计层面的规范。软件设计就不外乎复用、内聚、耦合三个主题，OSGi作为Java的模块化规范，也是为了更好地解决Java在这三个主题的问题。OSGi规定了如何定义一个Module以及这些模块之间如何交互。在OSGi规范中，Java模块被称为Bundle，OSGi规范就是指导怎么令这些Bundle能更好的有高内聚性、有松耦性，能更好地被复用。基于OSGi的应用，就是由一个一个Bundle组成的，通过OSGi把这些Bunde组织在一起，就形成了系统。

OSGI框架

4.2 Bundle

4.2.1 概念

Bundle是OSGi中最基本的单位，通俗地讲，如果说OSGi是基于Java平台的“模块化开发体系”，那么Bundle便是其中的“模块”

一个符合OSGi规范的Bundle首先必须是一个符合JAR文件格式规范的JAR包，JAR文件格式规范里定义的/META-INF/MANIFEST.MF文件用于描述JAR包的元数据信息，如JAR包的版本、数字签名信息等，Bundle在MANIFEST.MF文件中添加了大量扩展定义，如描述该Bundle可以提供哪些资源、依赖哪些其他Bundle、启动或卸载时要执行哪些动作等

4.2.2 Bundle生命周期

4.2.3 Bundle间的依赖

OSGi对Java平台的类加载机制的一个重要改进就是支持包级别的类导入和导出。在OSGi中，每个Bundle都有自己的类加载器，完成内部类和外部类的隔离。该加载器能够看到Bundle Jar文件内部的类和资源。Bundle通过配置jar包中的MANIFEST.MF，可以控制从Bundle导出的包，而没有导出的包，则在Bundle外部是不能够访问的。这样就很好地完成了内部类和外部类的隔离。
Import-Package：引用其他Bundle的接口
Export-Package：暴露给其他Bundle接口访问

4.3 Karaf（类似于OSGI的一个发行版本）

提供了更丰富的功能
Karaf, 一个基于OSGi的运行环境, 提供了一个轻量级的OSGi容器,可以用于部署各种组件和应用程序

Karaf容器的特点：

• 系统服务：
  自带service wraper功能，把karaf包装成系统服务，设置为守护进程，karaf项目可以一直运转
• 热部署
  尽管OSGi支持热部署，但并不是自动热部署，需要调用一些API去执行插拔的动作。
• 动态配置
  Karaf在$KARAF_HOME/etc文件夹中存储配置文件。这些配置内容可以在Karaf运行时动态修改。
• 日志处理
  基于Log4J的日志系统，同时支持多种日志API，如JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi等。
• 控制台
  可以在控制台进行服务管理、安装bundle等操作。还可以扩展自己的控制台命令。可以通过SSH远程访问其他服务器上的Karaf控制台。
• 多实例管理
  一个服务器上可以运行多个Karaf实例。对实例的管理可以在Karaf控制台中进行。
• Bundle仓库
  Karaf中内置了Pax URL的MVN协议，可以从Maven中央仓库安装bundle。
• Bundle集合(Feature)
  类似于Eclipse的Feature，Karaf中也支持Feature，即bundle的集合。使用Feature可以简化OSGi应用的部署。

4.4 Feature概念

feature屏蔽了bundle之间的复杂的依赖关系