OpenDaylight应用指南(txt+pdf+epub+mobi电子书下载)

作者：唐宏、刘汉江、陈前锋、李鹏,等

出版社：人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

OpenDaylight应用指南试读：

前言

关于SDN的著述已经很多，一直以基于OpenFlow为核心的控制与转发技术介绍为主，这也是早期 SDN 技术研究的一个主要特点。随着工业界对 SDN/NFV 技术的理解和研究的不断深化，各种开放性的SDN技术、开源社区和技术标准不断涌现，OpenDaylight开源控制器社区就是其中的典型代表。自2014年4月发布第一个版本以来，OpenDaylight改变了SDN控制器技术长期以来局限于OpenFlow框架的格局，很好地体现了传统网络技术与SDN技术的共存架构，也体现了通信技术与 IT 技术在软件实现架构上的充分融合，目前已经成为工业界最受关注的SDN控制器项目之一。但由于OpenDaylight涉及广泛的网络基础概念，且社区成立时间较短，目前系统性的介绍较少。

本书的写作目的非常明确，一是为那些SDN的初学者和中级技术人员，提供一个了解OpenDaylight开源社区的快速参考工具，需要编者提供一个基本忠实于社区内容的项目概述和用例介绍；另一个目的就是反映我们对OpenDaylight技术的理解和应用实践，这需要编者从实用的角度针对一个具体的应用场景，介绍从编排、控制器到转发平面的端到端设计与实现。本书尽最大可能保留这两个特点，以帮助网络设计人员和控制器开发人员快速了解OpenDaylight社区及其控制器实现思路，便于后续深入学习。

本书共分三个部分：

第一部分

成稿过程遇到很多困难，最大的困难来自于OpenDaylight社区本身，在社区建立初期，各项目文档和代码均尚未稳定，排除代码质量本身的因素，各个发布版本间的实现框架和项目实现思路会发生较大变化，如从AD-SAL向MD-SAL的转变，而这些变化本身往往体现了 OpenDaylight设计思路的变迁过程，能准确地反映这些变化和过程需要良好的ICT专业背景；其次，社区项目增长非常迅速，成稿过程中恰逢“锂”版本发布，建立了大量新增项目和补充文档，编者不得不根据新增内容进行修订；另外，OpenDaylight潜在的应用场景非常广泛，从 IDC 网络到运营商广域网，专业类型也横跨宽带、传输、移动网络以及运营支撑系统等多个SDN/NFV领域，横贯这些知识点需要较高的专业能力和较牢固的技术基础。

尽管如此，我们仍然努力完成此书的编著，鉴于成稿仓促，OpenDaylight社区仍在发展的初级阶段，内容纰漏和观点偏差难以避免。我们相信，SDN是一个众人拾柴的过程，每个人都有自己的理解，只有勇于讲出自己的视角和故事，我们最终才能完成 SDN 这个巨大的拼图。因此，编者希望平实地介绍OpenDaylight相关技术，而非像以往的SDN书籍那样，花较多篇幅去辨析什么是真正的SDN架构，业界现阶段的发展重点都已聚焦于各类开源实现。

参与本书撰写以及开源方案实现的人员，既有长期从事电信运营网络研究的技术专家，也有新近加入SDN研究的IT新兵，这是一个有趣的技术组合，也是一种有益的技术转型尝试，SDN时代将是一个ICT跨界人才辈出的年代。

中国电信广州研究院的刘汉江、陈前峰、李鹏、罗雨佳、欧亮、王勇、莫博奇等参与了本书各章节的编写工作，对他们的辛勤付出表示衷心的感谢！唐宏2015年10月于广州第一部分

基础概述

简要介绍SDN/NFV技术和OpenDaylight开源社区，帮助读者了解OpenDaylight的技术背景、社区状况、版本发布情况、项目组成等。

第1章

SDN/NFV概述

1.1 SDN/NFV介绍

互联网产业的迅猛发展不仅催生了云计算等新技术的涌现，也促使大量互联网创新应用取得巨大成功。在此期间，互联网业务及其核心收益，也由以往的以网络运营商管道接入为主，向着以用户体验为核心的应用价值进行转变，传统管道服务的日益低值化，促进了运营商不断寻求适应新型业务发展的网络新技术。

然而，当前建立在尽力而为 IP 网络及其运营支撑系统之上的运营商承载网络，由于智能化承载控制平面的缺失，以及业务与网络设备的紧耦合造成的系统封闭性，存在着网络资源利用率低、新业务部署周期长、感知和差异化保障不足、网络维护复杂困难等诸多问题，严重影响了移动互联网时代的竞争力。

为此，积极开拓信息和网络应用新技术，建设开放、高扩展、敏捷、智能化新型网络，为客户提供便捷、丰富、个性化、高体验的网络服务，已成为通信业和网络运营商的最新发展目标。在这个背景下，以研究新技术、新架构为目标的SDN和NFV技术应运而生，相关的网络技术变革不仅已成为业界共识，而且将逐步成为未来运营商业务与网络转型的核心技术。

本章将简要阐述SDN/NFV技术的架构和特点以及这两者之间的关系。

1.1.1 SDN架构和技术特点

软件定义网络（Software Defined Networking，SDN）起源于斯坦福大学的校园网络，是一种新型的网络架构和技术，它的核心设计理念是将传统IP网络的数据转发和路由控制进行分离，实现集中控[1]制，分布转发，通过软件可编程的方式来简化和优化网络。

图1-1所示为目前业界理解的SDN一般架构，主要由以下三个层面组成：基础设施层、控制层、应用层。[2]图1-1 SDN的逻辑架构

基础设施层由转发设备组成，主要负责数据处理、转发和状态收集等功能。

控制层由 SDN 控制软件组成，可通过 OpenFlow（OF）、PCEP（Path Computation Element Communication Protocol，路径计算单元通信协议）等标准化协议与下层进行通信，控制底层网络设备的转发行为，处理数据平面的资源编排，维护网络拓扑、状态信息等。控制层还将网络能力进行抽象，向应用层提供开放的API（应用程序[3]接口）。

应用层由众多业务和应用软件构成，这些软件可根据控制层抽象的网络信息执行相应的控制算法，形成网络策略，然后将控制策略通过控制层转化为流量控制命令下发给转发设备。

SDN技术自出现以来，形成了众多流派，可以大致将其分为两大类：SDN过渡技术和OpenFlow。其中，I2RS（Interface to the Routing System）和overlay是最具代表性的SDN过渡技术。I2RS是IETF成立的SDN工作组，其出发点是维持现有路由体系架构不变，在网络设备上提供专用接口供用户开发应用。overlay 是Big Switch、VMware等厂商主导的虚拟化解决方案，其核心思路是采用VxLAN（Virtual extensible Local Area Network，虚拟可扩展局域网）、NVGRE（Network Virtualization using Generic Routing Encapsulation，网络虚拟化通用路由封装）、STT（Stateless Transport Tunneling）协议等隧道技术在物理网络上叠加虚拟的逻辑网络。用户可以灵活定义逻辑网络、调整网络策略。而 ONF定义的OpenFlow 遵循控制与转发分离的设计原则，其转发层由OpenFlow交换机组成，控制层与转发层之间通过标准化的OpenFlow协议（南向接口）进行通信，控制器可通过“流匹配”的方式定义网络转发规则，向交换机下发相应的流表，OpenFlow 交换机执行相应流表的动[4]作即可高速转发数据包。

从上述SDN技术的几种不同实现方式，可以总结出以下几大技术特征。

控制与转发分离：将传统IP设备的控制面和转发面进行分离，转发设备抽象为一个通用的受控的网络设备，只关注转发和存储能力，与业务特性彻底解耦。控制面则通过控制协议控制转发面的流量行为。

集中控制：将网络信息进行抽象处理构成统一的控制平台，实现逻辑上的集中式控制，从而获取网络资源的全局信息，并根据全局状态实现资源的全局调度和优化，提高网络控制的灵活性。

开放可编程：通过开放的API，应用层可以告知控制层如何进行网络资源操作才能更好地满足业务需求（如带宽、时延、计费等）。另外，用户还可根据业务需求定制网络功能，实时配置网络参数，加快业务响应速度，缩短业务开通时间。

网络虚拟化：SDN 通过软件控制简化的底层网络硬件，突破传统网络操作系统与专用硬件紧耦合的组织架构，将网络由静态的物理[5]网络转变为面向用户、面向应用的动态逻辑网络。

1.1.2 NFV架构和技术优势

网络功能虚拟化（Network Functions Virtualisation，NFV）最初是由全球领先的7家电信运营商提出的，旨在通过虚拟化技术实现软硬件的解耦，将网元功能抽象为独立的应用，并部署于基于标准服务器、存储、交换机构建的统一平台上。NFV 改变了运营商构建网络的方法，不再依赖于专用的网络设备，通过标准的大容量的IT设备即可实现网络功能。

ETSI网络功能虚拟化行业规范工作组（ETSI NFV ISG）是目前业界一致认可的NFV相关标准体系研究的领跑者和主要推动者，主要[6]由以下 5 个工作组组成：IFA、TST、EVE、REL、SEC，目前它已经制订和发布了NFV虚拟化需求、NFV用户案例、NFV体系框架等多个文档。图1-2所示为ETSI提出的NFV架构。图1-2 ETSI定义的NFV架构

整个NFV架构从下至上可以分为3层：基础设施层、虚拟网络层和运营支撑层。

基础设施层主要包括NFV基础设施（NFV Infrastructure，NFVI）及虚拟化基础设施管理（Virtualize Infrastructure Management，VIM）系统，其中，NFVI主要包括物理硬件层和虚拟化层，虚拟化层将物理硬件层的计算、存储、网络等硬件资源抽象为虚拟计算资源、虚拟存储资源、虚拟网络资源，从而将软件功能与底层硬件进行解耦，为虚拟网络层的VNF提供部署、管理和执行的环境。VIM的主要功能是实现对NFVI资源（包含硬件资源和虚拟资源）的管理和监控。

虚拟网络层主要包括虚拟网络功能（Virtualize Network Function，VNF）、网元管理系统（Element Management System，EMS）与VNF管理系统（VNF Manager，VNFM）。VNF是部署在虚拟机上的虚拟化网元，其网络功能及对外的运维接口与物理的专用设备保持一致。EMS是VNF的业务网络管理系统，通常由VNF厂商提供，完成传统的网元管理功能及虚拟化环境下的新增功能。VNFM主要负责VNF的资源及生命周期相关的管理，如网元的实例化、扩容与缩容等功能。

运营支撑层主要包括OSS/BSS与编排器（orchestrator）。OSS/BSS除支持传统网络管理功能外，还支持在虚拟化环境下与 orchestrator的交互，完成维护与管理功能。orchestrator负责网络业务、VNF与资源的总体管理，是整个NFV架构的控制核心。

orchestrator、VNFM与VIM合起来称为MANO（NFV Management and Orchestration），主要解决虚拟化网络的部署和网络资源调度等问题。

NFV 通过虚拟化技术实现软硬件的解耦和功能抽象，使网元功能运行在通用的x86 服务器上。如果网络功能和性能都能达到要求，NFV将会给网络运营商带来巨大的价值：

网络设备功能不再依赖于专用硬件，标准的x86服务器设备成本相对较低，可降低昂贵的网络建设成本；

通过开放的API 可以获得更灵活的网络能力，使用软件加载的方式即可完成新业务的上线、业务的更新等，大大减少新业务的建设周期；

通过调整相应VNF的虚拟资源即可实现网络能力的弹性伸缩，因此，可根据实际业务的需求按比例扩大、减少相应的网络规模，灵活性好，扩展性高；

通过统一平台的集中化管理，可充分实现资源的灵活共享，能有效提高管理和维护的效率。

1.1.3 对SDN与NFV关系的理解

随着互联网产业的迅猛发展，业务承载需求发生了翻天覆地的变化，研究新技术、新架构进行网络变革已成为业界共识，SDN和NFV技术应运而生，逐渐成为下一代网络架构发展的核心技术。那么，它们之间究竟有着怎样的关系呢？

显然，这两者的侧重点不同。首先，SDN 是软件定义网络，侧重于实现控制和转发的分离，将转发设备功能简化，通过标准化的接口实现IP数据包分组转发的集中控制。而NFV是网络功能虚拟化，侧重于网元功能的变革上，将传统专用网络设备的功能和硬件进行解耦，使网元功能部署于标准服务器、存储设备、交换机构建的统一平台上，从而使网络不再依赖于专有硬件，降低运营商的网络建设成本和运维成本。

其次，SDN的概念是 2009年提出的，相对NFV的提出时间（2012年）较早，标准化程度也相对较高。SDN已有OpenFlow为代表的标准化南向接口协议，且处于持续更新中，而NFV尚无完善的标准协议，但有具备指导性意义的白皮书。

再次，SDN 起源于校园网，在数据中心和企业网中已出现成功的商用案例，并将逐步应用于广域网。而NFV由运营商提出，目前主要的应用有运营商的移动核心网设备、网络边缘设备等。

虽然SDN与NFV的设计理念完全不同，但它们之间有一定的合作[6]关系。NFV白皮书对SDN和NFV的关系做出了相应的说明。总体来说，SDN和NFV是相互补充但又互不依赖的关系，如图1-3所示。虽然SDN和NFV可以独立部署，但如果两者协同应用将是一个强大的组合：结合SDN提出的控制平面和数据平面分离的方法，NFV可以提高性能、兼容现有部署、简化运维工作；反之，NFV可通过提供SDN可运行的基础设施来支持SDN。目前研究较热的业务功能链（Service Function Chaining，SFC）就是SDN与NFV紧密结合的应用案例，在NFV平台上部署SDN控制器，动态控制NFV 虚拟网元之间的网络连接或者数据流，从而通过组合不同的网元实现丰富的网络能力，如图1-4所示。图1-3 SDN和NFV的关系图1-4 SDN与NFV结合的应用案例

1.2 控制器概述

从SDN的架构来看，控制器是SDN技术的核心，具有“承上启下”的作用，控制器向下对转发面的行为进行控制和管理，向上将网络能力进行抽象，通过开放的API支持上层不同业务的网络需求。而NFV技术主要集中在解决网元功能的虚拟化上，需要控制器配合解决业务选路方法、流量控制和性能监控等问题。因此，控制器在SDN和NFV技术中都具有非常重要的地位。

目前，SDN控制器有两大阵营：商用控制器和开源控制器。不同的SDN控制器在实现语言和设计目标上有着一定的差异，因此，各自具有不同特点和优势。根据南向接口协议的不同，可以将其大致分为两类：支持 OpenFlow的SDN 控制器和支持多种南向接口协议的SDN控制器。

1.2.1 商用控制器

随着SDN/NFV技术的发展，各大设备厂商、IT厂商纷纷发布了自己的商用控制器，如思科（Cisco）的CiscoOne、华为的SNC、Brocade的Vyatta SDN控制器、Juniper的Contrail、华三的VCF等。

表1-1列出了市场上主流的SDN商用控制器产品的一些相关信息，包括支持的南向接口、北向接口、控制器产品原型等。从该表中可以看出：大多数的商用控制器都是基于开源控制器OpenDaylight开发的，南向接口大多支持OpenFlow，而且大多都会在北向提供开放接口供用户开发应用。表1-1 商用控制器对比

由于不同厂商对标准的理解不同，SDN 商用控制器还存在一定程度的互通性问题，主要表现为以下两个方面：一方面，不同厂商的控制器之间难以互操作；另一方面，部分交换机只能和固定的控制器[7]互通，和其他厂商的控制器无法成功建立安全通道。这些问题的解决需要社会各界的共同努力。

1.2.2 开源控制器

由于使用商用控制器依然需要在一定程度上依赖厂商，且商用控制器本身还存在互通问题，研究和了解开源控制器、基于开源控制器进行定制开发已经成为了目前业界的热门做法。现有开源控制器有OpenDaylight、Floodlight、Ryu、NOX/POX、OpenContrail、Trema、ONOS等，以下简单介绍几款主流的开源控制器。

1.Floodlight

Floodlight 是创业公司Big Switch在 2012年2月发布的开源控制器。Floodlight是一款基于Java实现，在Apache软件许可证下免费发布，可与任何支持OpenFlow的网络设备互操作的控制器，目前Floodlight仅支持OpenFlow 1.0（OF 1.0）和OpenFlow 1.1（OF 1.1）。Floodlight具有以下特点：

使用模块化加载的核心架构；

通过OpenStack Quantum插件实现与OpenStack的对接；

北向的REST API支持Java和Jython等。

2.Ryu

Ryu是日本运营商NTT的实验室支持开发的一款开源SDN控制器。该控制器是取名于日语“flow”的意思，完全由Python语言编写，具有以下几大特点。

系统架构完善，支持插件式开发。

提供OpenStack Quantum插件，支持OpenStack。Ryu分为两部分：Ryu-manager和Ryu-client。其中，Ryu-manager是运行在OpenStack的控制节点，用于处理开发者编写的网络集中控制逻辑，并将任务分发给下面的计算节点。计算节点使用Ryu-client的API为OpenvSwitch部署相应的配置策略。

比较全面地支持OpenFlow协议，目前已经支持OF 1.0、OF 1.2、OF 1.3以及OF 1.4等版本的协议。除此之外，还能支持OF-Config、NETCONF等控制协议。

3.ONOS

ONOS是2014年12月由斯坦福大学和加州大学伯克利分校 SDN 创立的开源社区，AT＆T、NTT等电信运营商为其主要的合作伙伴。ONOS旨在设计一款可用性高、性能优、抽象性和扩展性好的运营商级的开源SDN网络操作系统。ONOS具有以下几大特点：

全分布式控制架构，支持分布式统一逻辑网络视图；

支持OpenFlow和白盒硬件；

支持插件式管理等。

4.OpenContrail

OpenContrail是由Juniper公司开发的一个用于软件定义网络的集成软件系统。该软件系统可以在 OpenStack 虚拟云的管理平台下实现不同虚拟机之间的虚拟网络的自定义，实现OpenStack中不同租户之间虚拟网络的隔离和控制，还提供防火墙入侵检测系统、深度包检测、数据缓存等网络管理功能。OpenContrail系统的主要组件有：WebUI、configuration node、control node、vRouter和analytics node。

WebUI：提供一个可视化的界面，方便管理者管理虚拟网络并监控网络的状态。

configuration node：负责接收来自WebUI通过REST API发送的配置信息，将配置信息通过 Schema 转换器进行转换后通过 IF-MAP 服务将配置信息发送到control node上。

control node：负责订阅并收取 configuration node 转换后的IF-MAP（Interface for Metadata Access Point）配置信息。

vRouter：是OpenContrail系统配置的末端节点，它接收XMPP服务器发送的配置信息，将其解析后存入本地的数据库中，然后根据数据库中的配置信息来调整网络的转发和配置。

analysis node：负责收集configuration node、control node和vRouter上的状态信息，通过Sandesh协议的方式进行数据传递。analytics node提供REST API，可以通过访问接口获得OpenContrail系统的状态信息。

OpenDaylight是目前备受瞩目的开源控制器之一，也是本书的重点，第1.2.3节将简单介绍 OpenDaylight 控制器（controller）的技术特点，使读者从宏观上了解 OpenDaylight 控制器。第3章将详细介绍OpenDaylight中的控制器项目，包括基础架构、组成模块、安装环境、开发流程等。

1.2.3 OpenDaylight控制器概述

OpenDaylight是一款基于Java开发的控制器，其项目架构与第1.1.1节提到的SDN架构总体上是一致的，但不包括最底层的基础设施层，也就是说OpenDaylight将不涉及转发面组件的工作，如图1-5

[8]所示。总体来看，OpenDaylight具有以下几大特点。图1-5 OpenDaylight架构分析

南向接口不仅支持OpenFlow，还支持SNMP、PCEP、BGP-LS、OF-Config等其他标准化协议，甚至允许出现私有化接口。

引入了业务抽象层（SAL），这使得上下层模块之间的调用可以相互隔离，屏蔽多种南向协议的差异，为上层的功能模块提供一致性服务。

北向提供开放可扩展的API，用户可根据需要通过调用函数或者REST接口开发应用。

OpenDaylight具有模块化、可扩展的控制器核心。采用开放服务网关（Open Service Gateway Initiative，OSGi）体系结构，解决功能组件之间的隔离问题，实现代码和功能的灵活加载，并可支持运行时业务或应用的安装、更新、删除等插拔操作。

使用 YANG工具可直接生成业务管理的“骨架”，开发者只需专注于具体业务，根据业务驱动模型工具来设计接口，实现业务功能。

OpenDaylight拥有一个开源的分布式数据网格平台，该平台不仅能实现数据的存储、查找和监听，更重要的是它使得OpenDaylight支持控制器集群。

第2章

OpenDaylight社区

2.1 OpenDaylight社区介绍

OpenDaylight是Linux基金会负责管理的开源项目，旨在建设一个开放的SDN网络系统控制平台，推动 SDN和NFV 技术的创新实施和透明化。本章将详细介绍 OpenDaylight社区，使读者能够更全面地了解OpenDaylight。

2.1.1 OpenDaylight开源社区

2013年4月，Big Switch、Brocade、思科、Citrix、Ericsson、IBM、Juniper、微软、Redhat、NEC、VMware、Arista、戴尔（Dell）、Fujitsu、惠普（hp）、英特尔（Intel）、Nuagenetworks以及Plumgrid等18个国际知名厂商联合建立了OpenDaylight项目（OpenDaylight Project，ODP），他们的共同目标是以透明、开放、公平、协作为原则建立一个供应商、客户、合作伙伴和开发人员可以[9]共同使用的SDN开源平台，从而推动SDN的产品化和商业化。

该项目主要由非营利性组织Linux基金会负责管理，任何厂商只需贡献一定量的资金和工程研发人员即可成为OpenDaylight社区会员。目前OpenDaylight的会员等级主要有铂金、金、银三类，会员等级越高影响力就越大，如铂金会员可指定一个代表作为技术指导委员会（Technical Steering Committee，TSC）成员。图2-1所示为现阶段[10]OpenDaylight的铂金、金级会员和部分银级会员。

OpenDaylight社区将会定期组织一系列的活动帮助会员分享想法、创建代码，通过相互协作，最终将优秀代码和技术选入OpenDaylight基础设施软件平台中。任何开发人员都可以在该平台的基础上进行二次开发，并将其应用于实际生产环境中。

与其他开源项目一样，OpenDaylight社区提供多种参与方式：OpenDaylight新手可以从入门指南（Getting Started Guide）开始入手，而期望熟悉代码库的开发人员则可以访问开发者Wiki（Developer Wiki）。在研究ODP的过程中，遇到任何问题还可以通过邮件列表（mailing list）或freenode.net的IRC #opendaylight与OpenDaylight开发者社区的其他会员一起讨论。图2-1 OpenDaylight会员示意

2.1.2 OpenDaylight社区管理

大型开源社区通常有两类管理模式：业务管理和技术管理，ODP 也不例外，其技术领导包含技术指导委员会和主要组件的项目管理者，而业务领导实例化为董事会。

OpenDaylight社区通过“技术指导委员会章程”规定两者的职责和权限，董事会主要负责设定ODP的策略方向（包括ODP的范围、技术愿景、方向），并对TSC提出的项目发布计划进行指导。而 TSC 则在董事会设定的策略方向内提供技术指导，制定发布规划、确立发布质量标准、挑选最佳的开发程序、监控技术进程，如果提交者和项目负责人之间出现技术冲突，TSC还需要负责调停。不仅如此，TSC还是ODP与其他联盟和组织之间的接口人。

那么，怎样才能成为TSC成员呢？

任何组织和个人都有可能成为TSC成员。TSC最初由白金会员分别指定一个代表组成，TSC组织成立之后，将会通过投票的方式将一些活跃的代码提交者选举为TSC成员。为了保证ODP的公平性和中立性，任何厂商都不可以控制投票权，如果发现与白金会员有关的非指定TSC成员（新选举出的TSC成员），该白金会员指定的TSC会员代表必须马上辞职。TSC还会选出一名主席负责与董事会沟通，主席可作为不投票的旁观者参与董事会的会议。对于TSC成员（包括主席）的选举办法，董事会每年都会重新评估。

ODP包含多个小项目，每个项目的运营都离不开以下几类角色：贡献者（contributor）、提交者（committer）和项目管理者（project leader）。

贡献者负责开发代码或贡献其他成果，通过贡献高质量修补程序和功能优化代码有可能被选举为提交者。

提交者负责控制技术方向，决定相应项目的设计、代码和修补等，具有将代码提交到源代码管理系统的权限，但其权限仅限项目本身，一个项目的提交者通常没有其他项目的提交权限。

项目管理者负责设定项目的整体方向并向TSC汇报，项目管理者通常从提交者中通过投票的方式选出。

2.1.3 OpenDaylight社区运营

OpenDaylight是一个多项目、多厂家的SDN开源软件生态系统，它的发展离不开行业领先的各大厂商不同程度的支持。在初创时期，Linux基金会为ODP提供了必要的组织和协作框架，在这个共同的框架下，很多公司和组织纷纷参与进来，贡献了不同的技术资源。创始阶段的部分贡献情况如下。

思科主要贡献了控制器技术，提供了控制器基础框架和一些控制器基本功能的代码。因此，OpenDaylight控制器的框架与思科的商用控制器OnePK较为相似。

IBM贡献了虚拟网络覆盖技术DOVE的开源版本，可将现有物理网络的基础设施抽象为虚拟网络，这不仅能简化网络的设置和管理，还能灵活实现网络的收缩和扩展，从而加快业务的交付进程。

Redhat主要致力于解决SDN解决方案与Linux系统、OpenStack、KVM平台整合的问题。

NEX为OpenDaylight提供网络虚拟化支持，提交了VTN（Virtual Tenant Network，虚拟租户网络）模型和相应的代码，使用户可以更好地管理网络资源。

除此之外，还有很多厂商为ODP贡献了开源技术和代码，这里无法一一列出。在TSC和董事会的领导下，各大厂商各司其职，ODP 在初创阶段的基础上迅速发展。现在，ODP已拥有30多个子项目，在本书的成稿过程中，也已发布开源软件的第三版——Lithium（锂）版本。那么，ODP的子项目是如何出现、如何运作的呢？

ODP的项目生命周期文件（daylight project lifecycle）将项目分为三个阶段：孵化期、成熟期和核心期。TSC根据该文件的精神制定了开发进程，开发进程将会为项目提供方向性指导。

任何人都可通过提交建议书的方式创建孵化期项目并提交给 TSC 审核，审核通过后项目开始运行，TSC根据开发进程监督和评估项目的变化，决定是否需要调整项目的状态。当达到一定的条件时，[11]项目可能经历如图2-2所示的生命周期。

孵化期：拥有实际的项目资源，但被公认为是初期阶段的项目。

成熟期：是一个成功的功能完整的开源项目。

核心期：OpenDaylight的核心项目。

通常将项目从孵化期推向核心期比创建一个新的孵化期项目的难度要高很多。图2-2 项目生命周期示意

2.2 OpenDaylight版本介绍

OpenDaylight 社区成立之后便迅速发展，短短一年时间内就推出了第一个开源控制器平台——Hydrogen。Hydrogen 版本推出一个多月之后，其后续版本Helium 就出现了。除此之外，期盼已久的Lithium版本于2015年6月29日完成了项目发布计划。到目前为止，OpenDaylight已经逐渐成为最大、最成功的开源控制器项目（拥有约466个开发人员，贡献约230万行代码）。

2.2.1 Hydrogen版本简介

Hydrogen是OpenDaylight发布的第一个版本，它针对不同的用户提供三个不同的版本，希望用户能够尽快上手和运行。

基础版：主要适用于在物理或虚拟环境中进行SDN和OpenFlow方面的概念验证和学术活动的探索者，包含基于OSGi的模块化、可扩展、多协议的SDN控制器，在控制器的业务抽象层（SAL）中集成的OpenFlow协议库和插件的实施模块，OVS数据库（OpenvSwitch Database）的配置和协议管理支持模块，基于Java的NETCONF和YANG工具。

虚拟化版：主要适用于数据中心用户，该版本包括所有基础版的组件、创建和管理虚拟租户网络（Virtual Tenant Network，VTN）和虚拟化的Overlay的功能以及安全和网络管理方面的应用。

服务提供商版：适用于管理现有网络并希望向 SDN和NFV 过渡的提供商和网络承载公司。它包括基础版的所有组件、服务提供商网络中的常见协议的支持模块（如LISP、BGP-LS、PCEP、SNMP等）和一些网络管理应用。

图2-3所示为Hydrogen版本的系统架构。图2-3 Hydrogen版本系统架构

2.2.2 Helium版本简介

Helium（氦）是OpenDaylight社区发布的第二个版本，该版本的发布意义重大，具有“开放SDN的崛起（The Rise of Open SDN）”之称。与Hydrogen版本相比，Helium具有一个全新的用户接口、简洁且可定制的安装进程，这主要得益于Apache Karaf（Apache Karaf是一个封装了OSGi的运行环境）的使用。

OpenDaylight软件是若干组件的组合，包括可插拔控制器、接口、协议插件、应用等。基于这个共同的平台，用户和供应商可以进行创新和合作，从而促进SDN/NFV解决方案的商业化。

在Helium版本中，OpenDaylight平台主要在以下关键领域出现了演变和改善。

对于那些期望使用OpenDaylight来进行网络管理的用户，该版本可提供与OpenStack更深层次的整合，包括OVS数据库整合项目中的显著改善，安全组、分布虚拟路由、负载均衡即服务等高级OpenStack特征的技术预览。

通过分布式部署与同步机制实现高可用性及系统冗余。

增强集群和安全功能，安全网络引导基础设施（Secure Network Bootstrapping Infrastructure，SNBI）项目提供网络设备和控制器自动且安全的整合，SNBI 通过零接触方式（无需手工配置）即可引导制造商预装的IEEE 802.1AR进行安全认证。

增加和加强新协议，包括：OpenFlow TTP（OpenFlow table type pattern）、多媒体缆线封包（packetcable multimedia）等。

为业务功能链（Service Function Chaining，SFC）提供应用策略框架和工具。

这里无法穷举Helium版本中OpenDaylight平台的变化，图2-4所示为Helium版本系统架构，将该图与图2-3对比读者可清楚地发现Helium版本在项目设置和架构方面的变化。图2-4 Helium版本系统架构

2.2.3 Lithium版本简介

Lithium是OpenDaylight的第三个发布版本，图2-5所示为该版本的系统架构。和OPNFV（Open Platform for NFV，NFV开放平台）一样，Lithium版本有望嵌入到二十多种商业产品和解决方案中，帮助服务提供商和企业逐渐向可编程的SDN智能网络转变。图2-5 以OpenStack为例的Lithium版本架构示意

Lithium版本新特性的主要表现如下。

扩展性和性能的提升：OpenDaylight的Integration Group项目针对终端用户定义的用例和需求进行测试，从而提高Lithium版本核心架构组件的扩展性和性能。

针对云数据中心平台的网络服务：结合 SFC（Service Function Chaining）、VTN和GBP（Group Based Policy）项目的特性提供OpenStack Neutron框架的本地支持，不仅使用户可以更轻松地进行设备设计，还使得用户定制化服务链（包括防火墙、负载均衡和其他网络业务应用）的用户级/组级策略更加简单。

增加安全和自动化的新特性：Unified Secure Channel 项目使广泛分布的网络设备和OpenDaylight之间能够建立统一的安全通信机制；TSDR（Time Series Data Repository）项目使得能够采集和分析网络行为数据；DIDM（Device Identification and Driver Management）项目提供终端用户发现和管理其基础设施的能力；Persistence项目确保面向应用数据能够实现查询逻辑的持久性；Topology Processing Framework项目可用于多协议、underlay和overlay网络的拓扑聚合和拓扑过滤。

用于互操作的新的增强型的API：NIC（Network Intent Composition）项目使控制器能够基于网络行为和网络策略描述的“意图（intent）”来管理网络业务和网络资源，而ALTO（Application-Layer Traffic Optimization）项目为简化的网络视图和网络业务提供抽象和服务。这些新策略和抽象证明GBP项目已经引入了Helium版本中。

增加6个新协议：SXP（Source Group Tag eXchange）项目、LACP（Link Aggregation Control Protocol）项目、IoTDM（Internet of Things Data Management）项目、SMNP Plugin项目、OpFlex（Open Policy Framework）项目和CAPWAP（Control and Provisioning of Wireless Access Points）项目，通过这些新协议来支持不断壮大的用户案例。

本小节提到的相关项目更详细的介绍可参见第2.3节。

2.3 OpenDaylight项目简介

由于Lithium版本的项目最多也最全面，因此本节将对该版本的所有子项目做一个简单的介绍。

Controller（控制器）项目：为多厂家网络的SDN部署提供一个高可用、模块化、可扩展并可支持多协议的控制器基础框架。在该项目中，模型驱动的业务抽象层使控制器支持多个南向协议插件，而面向应用的可扩展北向架构为控制器提供丰富的北向API：针对松耦合应用的RESTful Web服务和针对协作应用的OSGi服务。另外，基于控制器平台的OSGi框架为控制器带来了模块化、可扩展的特性，还能为OSGi模型和服务提供版本控制和生命周期管理。

OpenDaylight Root Parent项目：是OpenDaylight中所有项目的Maven配置基础，包含外部依赖、默认版本、依赖管理、插件管理、库信息等所有共同信息。它能为参与版本发布的所有项目提供统一的设置，其他项目的配置只需继承 odlparent即可获得ODL的统一设置，这在很大程度上能够帮助简化项目配置。

YANG Tools项目：是一个旨在开发必需的工具和库的基础设施项目，它能为Java项目（基于JVM语言）和应用提供NETCONF和YANG支持，在OpenDaylight中，使用YANG作为模型化语言的应用有控制器MD-SAL和NETCONF/OFConfig插件。

AAA项目：为用户开发身份认证、授权、计费等功能，包括为用户提供适用于多种身份认证、授权、计费机制的通用模型，提供可插拔的机制并为通用系统提供插件。

BGP LS PCEP（BGPCEP）项目：为控制器提供两种南向接口插件——作为L3拓扑信息来源的BGP（包括作为BGP扩展的BGP-LS、BGP-FlowSpec）和为底层网络提供实例化路径的PCEP（Path Computation Element Protocol）。

DLUX项目：为控制器的使用者提供新的交互式Web UI应用，它选择AngularJS作为主要的前端技术，希望能够通过图形化的用户界面提高用户体验。AngularJS是当前比较流行的客户端MVVW（Model-View-ViewModel）框架，常被用来做SPA（Single Page Application）的开发。

L2Switch项目：该项目将L2的具体处理代码分离出来，组成一个独立的项目，提供基本的L2交换机功能并创建一些可重用的服务，如提供模块化的事件驱动的数据包处理程序（packet handler）、地址跟踪、最优路径计算、基本的生成树协议等。

LISP Flow Mapping Service 项目：该项目提供 LISP 映射系统服务，包括 LISP Map-Server和LISP Map-Resolver 服务，负责提供和存储数据到数据平面节点和OpenDaylight应用的映射。LISP（Locator ID Separation Protocol）是一个提供灵活的映射和封装框架的技术，它可用于数据中心网络虚拟化、网络功能虚拟化等 overlay网络应用之中。映射数据包括使虚拟化节点可达的虚拟地址到物理网络地址的映射以及流量工程、负载均衡等各种各样的路由策略。OpenDaylight应用和服务可使用北向REST API在LISP映射服务中定义映射和策略，数据平面设备通过南向LISP插件具备LISP控制协议的能力，如图2-5所示。

Neutron Northbound项目：是一个向OpenStack的网络管理项目Neutron提供北向接口的插件项目，是使OpenDaylight与OpenStack协同工作的重要项目。它提供网络、子网、端口、负载均衡、VPN、安全策略等REST API，并随着OpenDaylight的发展，不断地增加。

ODL SDNi App项目：OpenDaylight SDN 接口应用项目旨在通过开发软件定义网络接口应用（Software Defined Networking interface，SDNi）保证SDN控制器之间的通信，该应用可在Helium版本的OpenDaylight上部署。

OpenFlow Protocol Library项目：OpenFlow协议库将会实施OpenFlow v1.3及后续版本协议。该库是控制器的OpenFlow南向插件的基础，支持第三方供应商的扩展。

OpenDaylight OpenFlow Plugin项目：OpenFlow是SDN架构中实现控制层和转发层之间交互的厂商中立的标准通信接口。该项目旨在开发一个支持OpenFlow规范的插件，该插件将实现OF 1.0、OF 1.3、OF 1.4及后续版本的支持和整合。

Persistence Store Service项目：本项目是一个数据库统一操作服务框架，该框架的作用是实现应用在查询数据时的查询逻辑持久性，主要应用在需要连接数据库查询数据的应用中，例如AAA项目和TSDR（Time Series Data Repository）项目。框架将不同的数据库查询方式封装起来，暴露统一的接口给ODL应用使用，提供数据查询、增加、删除等数据操作功能，并且维护查询操作的完整性。框架可以支持不同类型的数据库，关系型数据库如MySQL，非关系型数据库如MongoDB或者内存数据库。

SNBI（Secure Network Bootstrapping Infrastructure）项目：提供安全、自动、集成的网络设备和控制器。通常，在安全通信建立之前，操作人员必须在一系列网络设备之间执行手动密钥分发过程。而SNBI使用零接触的方法即可引导安装IEEE 802.1AR证书的产品进行安全认证。SNBI 设备和控制器能够自动发现对方，获取指定的IP地址并建立安全的IP连接。另外，这个发现过程可展示网络的物理拓扑，识别每个设备的类型（如它可能是一个常规的网络设备或控制器），并为每个设备指定域，设备类型和域信息可用于控制器联合流程的初始化。SNBI还包括控制器和转发单元上创建的组件和功能，这些组件和功能可包括单个的网络单元服务，如性能分析、流量探测、流量传送等。

SNMP4SDN项目：提供一个 SNMP 南向插件实现 OpenDaylight控制器对现有商用以太网交换机的控制，该插件可提供管理配置的能力。该项目使SDN不再局限于 OpenFlow，支持以太网交换机作为 SDN网络的数据面设备，它主要经历以下三个阶段的演进：（1）创建一个SNMP南向插件配置通过SNMP配置以太网交换机；（2）插件通过CLI（Command Line Interface，命令行接口）对以太网交换机做一些SNMP不能访问的设定；（3）实现SAL API的扩展。

SNMP Plugin项目：SNMP是一个实现网络管理的协议。它可用来收集信息、配置IP网络设备，如交换机、路由器、打印机、服务器等。该项目致力于南向插件的需求，使应用和控制器服务能够使用SNMP 与网络设备实现交互。SNMP南向插件使应用充当SNMP管理者与支持SNMP代理的设备的交互。

SXP（Source-Group Tag eXchange Protocol）项目：SXP是一个传送IP地址和源组标签（Source Group Tag，SGT）之间绑定信息的控制协议。在SXP中，源组是一系列具有共同网络策略的连接网络的端节点。每个源组通过一个特殊的SGT值（16字节）标识（大多数思科设备都支持 SGT 标识）。该项目旨在 ODL中实现 SXP，使 ODL获取大型已安装思科设备的绑定信息，并提供给应用和网络单元。当前的实施支持SXP协议的版本4，并提供对1～3版本的支持。此外，作为单向连接的扩展，版本4还增加了双向的连接类型。

TCP-MD5项目：本项目库为操作系统提供TCP-MD5（RFC2385）支持，可用于保护BGP 会话和PCEP 会话。该项目定义了一个使用 Java 本地接口库（Java Native Interface，JNI）实现的简单API，可用于设置与TCP channel关联的MD5密钥。虽然相应的代码已经存在于BGPCEP 项目中，但该项目旨在将这些代码分离为一个独立的组件，使其生命周期独立于BGPCEP 项目，这将带来以下益处：不同提交者带来的无限潜力、明确的问题阐述以及更为稳定的版本。

Topology Processing Framework项目：旨在创建拓扑聚合的框架，提供统一的拓扑视图。该项目主要提供两大产品特点：拓扑聚合和拓扑过滤。拓扑聚合是指从数据库获取 underlay 拓扑信息，然后将其聚合为一个或多个 overlay 拓扑，这些拓扑基于router ID、管理IP和datapath ID等映射关系创建，提供多协议节点抽象（多协议节点抽象是通过RPC转发实现的）的统一视图，使应用无需关注多个拓扑和多个节点标识。这个框架还提供过滤拓扑视图，该过滤可应用到交换机、交换机组、特定链接和其他对象。

ALTO（Application-Layer Traffic Optimization）项目：ALTO是一个为应用提供网络信息的IETF协议，定义映射成本服务、过滤映射服务、端节点属性服务、端节点成本服务等网络服务，从而引导应用使用网络资源。该项目致力于在 OpenDaylight 中实现ALTO。为了实现ALTO基础协议（RFC7285），该项目将在OpenDaylight中实现这些服务并通过北向API开放给他人使用。

CAPWAP（Control And Provisioning of Wireless Access Points）项目：该项目是为了“有线和无线网络通过适当的抽象实现统一管理”的长远目标而提出的。现阶段它致力于提供 CAPWAP 协议作为一个南向接口。Lithium 版本中该项目的作用范围包括：为CAPWAP提供南向MD-SAL插件、CAPWAP协议库、CAPWAP和IEEE 802.11之间的绑定关系、CAPWAP和IEEE802.11间绑定关系的标准测试应用、本地映射支持。

Controller Core Functionality Tutorials项目：该项目面向开发者提供各种基础功能的教程，以期开发者能快速理解 OpenDaylight的项目结构、基础功能，从而能加入到OpenDaylight社区开发。这些教程涉及的工程有Controller、YANG Tools、OpenFlow Java以及OpenFlow Plugin，其中包含各种基础操作有ConfigSubsysterm、NETCONF、RESTCONF、flow以及MD-SAL的相关操作。该项目提供的各个教程均是使用标准的项目结构（例如ArcheType），并且每个教程均采用分步式的方法介绍。

Defense4All项目：是一个用于检测和缓解DDoS攻击的SDN应用。在本项目定义的系统中，应用通过ODC北向REST API与OpenDaylight控制器之间实行交互，主要执行以下两大功能：监控被保护流量的行为并将攻击流量转移至被选攻击缓解系统（Attack Mitigation System，AMS）。该项目的实现方法如下：应用通过OpenDaylight控制器向每个被保护网络（Protected Network，PN）的合适位置下发流条目，采集和聚合流量并利用流条目的counter 字段做流量统计，识别异常流量，然后再向被选网络位置下发流条目，将异常流量转移至被选 AMS。当攻击消失时，应用将移除相应的流条目，使流量回归到正常的路径。

DIDM（Device Identification and Driver Management）项目：将提供一个可用于通知控制器发现它所控制的新设备、标识设备类型、将设备驱动注册为路由类型的RPC（Remote Procedure Call，远程过程调用）、搜集设备数据、定义库存模型、调用设备驱动的框架。该项目使用 SNMP 协议与设备进行交互时需要进行安全认证，因此它需要使用SNMP南向插件项目、AAA项目（进行认证管理）中的一些组件。

Documentation项目：提供OpenDaylight项目群的文档。该项目计划建立内容基础框架，用来改善各个 OpenDaylight 项目的用户说明以及确保不断增长的内容的质量。整个项目管理包括内容编辑、内容发布以及设置内容格式等。

Group Based Policy（GBP）项目：定义以应用为中心的策略模型，将应用的网络连接从底层网络抽象出来。该工程提供一个简单的

试读结束[说明：试读内容隐藏了图片]

下载完整电子书