opendaylight框架分析PPT课件
OpenDayLight 代码学习研究
ODL学习修改记录1.1ODL概述Opendaylight是一个以模块化、可插拔、灵活的、基于Java的控制器为核心的开源平台。
从北往南，它首先包括供上层应用和业务逻辑使用的北向开放API，有OSGi和REST两类。
上层应用程序利用这些北向API获得网络智能信息、运行算法处理分析以及组合新的网络策略；其次，它包括控制器平台本身，它是一组可动态组合的模块用于汇集网络信息，比如网络中有哪些元素、其统计信息如何等；最南边是能够支持多种协议的南向接口，如Openflow 1.0 1.3 BGP-LS等，这些南向接口可以调用设备上服务抽象层SAL。
1.2ODL架构原则Open Daylight Controller在设计的时候遵循了六个基本的架构原则：(1) 运行时模块化和扩展化（Runtime Modularity and Extensibility）：支持在控制器运行时进行安装、删除和服务的更新。
(2) 多协议的南向支持（Multiprotocol Southbound）：南向支持多种协议。
(3) 服务抽象层（Service Abstraction Layer）：南向多种协议对上提供统一的北向服务接口。
(4) 开放的可扩展北向API（Open Extensible Northbound API）：提供可扩展的应API，通过REST或者函数调用方式。
两者提供的功能要一致。
(5) 支持多租户、切片（Support for Multitenancy/Slicing）：允许网络在逻辑上（或物理上）划分成不同的切片或租户。
控制器的部分功能和模块可以管理指定切片。
控制器根据所管理的分片来呈现不同的控制观测面。
(6) 一致性聚合（Consistent Clustering）：提供细粒度复制的聚合和确保网络一致性的横向扩展（scale-out）。
1.3框架概述上图所示，南向通过plugin的方式来支持多种协议，包括OpenFlow1.0、1.3，BGP-LS 等。
opendaylight框架分析ppt课件
以自己定义的容器接口iContaineraware,从中发现各个bundle之间、Componet之间、全局和 容器Container之间的依赖和调用关系。
• bundle的抽象基类，管理全局和容器相关的服务，当然bundle本身就是一个大服务。 •Container是OpenDaylight中的一个网络域，有很多链接信息、整个域网络信息等，由
精选PPT课件
6
主要方法如下：
• Start(context)启动方法，会遍历其所提供的实现，依次配置依赖关系。 • getGlobalImplementations()获取全局的实现类，其导出接口的实现类。 • getImplementations() 获取容器相关的实现 。 • Configureglobalinstance(c, Imps[i])，c是前面提到的component • configureInstance（）在一个容器中配置实现的依赖关系。 • containerCreate(String containerName)配置Componet，里面说明了导出的接口和依赖
器注册iContaineraware接口以便容器的生命周期转换点调用。
•4）最后调用bunndle的钩子函数init()。该函数的功能代码的注释已经概括的很明确。
精选PPT课件
8
ArpHandler
• ArpHandler 所实现的接口有 Ihostfinder, Ilistendatapacket, Icacheupdateaware，
• 如前在所介绍的，其没有全局的实现，不会在启动过程中，配置Component，其会在先而
计算机网络技术第11章SDN与NFV技术课件
配置策略 监控性能
配
置
管
理
➢ 应用平面 ➢ 配置管理平面
网元
数
据
SDN数据路径
层
CDPI代理
转发引擎/处理功能
模块
网元
SDN数据路径 CDPI代理
转发引擎/处理功能 模块
网元设置
SDN架构的构成
11.1 SDN概述
➢ 结论
– SDN的本质就是软件定义网络，希望应用软件可以参与 对网络的控制管理，满足上层业务需求，通过自动化 业务部署简化网络运维就是SDN的核心诉求。
– SDN并不是一个具体的技术，而是一种网络设 计的理念，SDN的本质就是让用户应用可以通 过软件编程充分控制网络的行为，让网络软件 化，进而敏捷化。
– 一般认为SDN应该具备如下特征：
➢控制面与转发面分离；（核心属性） ➢具备开放的可编程接口；（核心属性） ➢集中化的网络控制； ➢网络业务的自动化应用程序控制。
北向服务接口。Hydrogen版本中全线采用AD-SAL，Helium版本中AD-SAL和MDSAL共存，Lithium版和Beryllium版中已基本使用MD-SAL架构。 ➢ 开放的可扩展北向API（Open Extensible Northbound API）：提供可扩展的 应用API，通过REST或者函数调用方式。两者提供的功能要一致。 ➢ 支持多租户、切片（Support for Multitenancy/Slicing）：允许网络在逻 辑上（或物理上）划分成不同的切片或租户。控制器的部分功能和模块可以 管理指定切片。控制器根据所管理的分片来呈现不同的控制观测面。 ➢ 一致性聚合（Consistent Clustering）：提供细粒度复制的聚合和确保网络 一致性的横向扩展（scale-out）。
OpenDaylight Helium版本与Hydrogen版本比较
OpenDaylight Helium版本与Hydrogen版本比较1OpenDaylight Helium版本业界组织OpenDaylight联盟最近发布了其开源SDN软件的2.0版本，即Helium（氦）版本，该2.0版本加入了一些有关Helium和OpenDaylight未来发展方向的新理念，致力于研发出“开放、易懂”的SDN解决方案。
且更多新厂商的加入对OpenDaylight项目的支持，印证了OpenDaylight目前的发展和进步。
1.1Helium版本变化Helium版本相较于1.0氢版本的一些变化：（1）OpenDaylight结合OpenStack。
在Helium版本中最明显的特征是OpenDaylight与OpenStack之间整合的方式，其中包括在Open vSwitch数据库整合项目中一些明显的改善，以及高级的OpenStack特征(如安全小组、分布式虚拟路由器和负载均衡即服务)的技术预览。
（2）组策略插件(Group Policy Plugin)。
能够在以策略为重点的北向API中提供比Affinity更好的体验，提供多样性选择，可以实行单一的模型也可以同时实行两种模型。
（3）DLUX(openDayLight User eXperience)。
通过更多拖放功能的图形用户界面增强用户体验，更易拖拽，且设备图形显示更美观。
（4）NFV（网络功能虚拟化）。
推动SDN与NFV的发展，重新构建网络，且新增11个新的协议、应用及技术到SDN和NFV平台中，使之更灵活的、互操作性更可用。
（5）变化最大的是配备了一个新的用户界面和一个更简单并可定制的功能安装过程，并使用了Apache Karaf容器，提供开发者更方便测试和管理SDN生产环境的平台。
使用Karaf容器后，OpenDaylight的启动方式也有了很大的改变，如进入OpenDaylight目录，切换到bin目录下，执行启动命令：启动成功后安装各功能模块也较简单，直接通过feature命令进行安装，如安装L2switch功能：新的用户界面显示相比较1.0版本完全变化，直接将Nodes、YangUI、Topology、Network、Connection manager、Flows等模块功能显示，更显直观，如下图部分功能显示：（6）更高的可用性，以及加强和增加新的协议，如OpenFlow的表格型模式、PacketCable多媒体、应用程序的策略框架和工具、服务功能链接等。
软件定义网络(SDN)与SDN系统架构PPT
软件定义网络（SDN）LAFILE_楊過2016.06.27报告纲要报告目的：主要介绍关于SDN的一些概念，特别是帮助大家理解对SDN核心技术方面概念的理解，并通过实验对SDN系统架构加深印象。
1. SDN2. OpenFlow3. Of-CONFIG4. NETCONF/YANG5. OpenFlow交换机及OVS6. 实验及结果演示7.报告总结8. 参考文献9. 致谢1. SDN◆1.1 什么是SDN?◆1.2 SDN产生的原因是什么？◆1.3 与传统网相比SDN的优点是什么？◆1.4 SDN的核心技术是什么？1.1 什么是SDNSDN（software defined networking，软件定义网络）是一种新兴的基于软件的网络架构及技术，其最大的特点就在于具有松耦合的控制平面与数据平面，支持集中化的网络状态控制（如图1.1.1），实现底层网络设施对上层应用的透明。
图1.1.1 传统网络架构与SDN架构对比1.1.1 目前传统路由智能路由器：也就是智能化管理的路由器，通常具有独立的操作系统，可以由用户自行安装各种应用，自行控制带宽、自行控制在线人数、自行控制浏览网页、自行控制在线时间、同时拥有强大的USB共享功能，真正做到网络和设备的智能化管理，其网络结构如图1.1.1.1。
图1.1.1.1 传统三层路由设备系统图1.1.2 SDN架构SDN 将数据与控制相分离，分成新的体系结构, 包括数据层、控制层和应用层。
◆<a> 控制平面, 包括具有逻辑中心化和可编程的控制器, 可掌握全局网络信息, 方便运营商和科研人员管理配置网络和部署新协议等.◆<b> 数据平面, 包括哑的(dumb) 交换机(与传统的二层交换机不同, 专指用于转发数据的设备)。
交换机仅提供简单的数据转发功能,可以快速处理匹配的数据包,适应流量日益增长的需求。
◆<c> 应用平面，包含着各类基于SDN 的网络应用, 用户无需关心底层设备的技术细节, 仅通过简单的编程就能实现新应用的快速部署根据提出的SDN概念，目前有下列几种SDN 体系架构（如表1.1.2.1）：表1.1.2.1 目前三种主要研究的SDN体系结构◆NFV：ETSI（European Telecommunications Standards Institute，欧洲电信标准化协会）从网络运营商角度触发提出，采用了资源虚拟化的方式，在硬件设备中建立一个网络虚拟层，负责将硬件资源虚拟化，形成虚拟计算资源、虚拟存储资源和虚拟网络资源等，运营商通过软件来管理这些虚拟资源。
SDN环境部署与OpenDaylight开发入门
5 OpenDaylight综述
5.3 OpenDaylight的子项目简介
5.3.22 子项目Group Based Policy（GBP）/Project Facts（GBP项目）简介 5.3.23 子项目L2 Switch（L2层交换机项目）简介 5.3.24 子项目LACP（链接聚合控制协议项目）简介 5.3.25 子项目OF-CONFIG（OF-CONFIG项目）简介 5.3.26 子项目OpenDaylight DLUX（ODL的DLUX项 目）简介 5.3.27 子项目Service Function Chaining（服务功能 链项目）简介 5.3.28 子项目VTN（VTN项目）简介
4.8 POX控制器
4.11 博科的 Brocade SDN控制 器
4.9 Beacon控 制器
4.12 Maestro 控制器
4 现有SDN控制器简述
4.13 IRIS控 制器
4.14 Extreme公司 的OneController
控制器
4.15 本章总 结
4 现有SDN控制器简述
4.5 思科的APIห้องสมุดไป่ตู้控制器和Open SDN控制器
5 OpenDaylight综述
5.3 OpenDaylight的子项目简介
5.3.15 子项目FaaS（网络构造即服务项目）简介 5.3.16 子项目NeutronNorthbound（Neutron北向 项目）简介 5.3.17 子项目ALTO（应用层流量优化项目）简介 5.3.18 子项目CAPWAP（无线接入点的控制和提供）简 介 5.3.19 子项目Controller Core Functionality Tutorials（控制器核心功能向导项目）简介 5.3.20 子项目Controller Shield（控制器盾项目）简 介 5.3.21 子项目DIDM（设备认证和驱动管理项目）简介
opendaylight框架分析
分布式转发
控制器采用分布式转发架 构，将控制平面与数据平 面分离，提高了网络的可 靠性和扩展性。
协议支持
支持多种南向协议，如 OpenFlow、NETCONF 等，以实现对不同网络设 备的兼容和控制。
北向API
RESTCONF
Opendaylight提供RESTCONF北向API，支持通 过HTTP/HTTPS协议对网络进行管理和配置。
发展
经过多年的发展，Opendaylight已经成为SDN领域的重要开源项目之一，拥有广泛的社区支持和活跃的开发者 群体。
Opendaylight的架构和组件
架构
Opendaylight采用模块化设计，主要由控制器、存储库和插件模块组成。控制器负责处理网络流量 和控制逻辑；存储库提供数据持久化服务；插件模块支持南向协议和北向API的扩展。
04 Opendaylight的优缺点 分析
优点分析
开放性
标准化
Opendaylight是一个开源的SDN框架，允 许用户根据需求进行定制和扩展，降低了 技术门槛和成本。
Opendaylight遵循国际标准，保证了与其 他设备和系统的互操作性，提高了网络的 灵活性和可扩展性。
社区支持
丰富的功能
Opendaylight拥有庞大的开发者社区，可 以快速获取帮助和解决方案，加速了问题 的解决和功能的完善。
特点
具有模块化、可扩展性和灵活性，支 持多种南向协议（如NETCONF、 RESTCONF等），北向API丰富，易 于集成第三方应用。
Opendaylight的起源和发展
起源
Opendaylight起源于2013年，由一组网络行业的领军企业（包括思科、IBM、Juniper等）共同发起，旨在开发 一个开源的SDN控制器。
Opendaylight基础
OpenDaylight中MD-SAL学习笔记2014/09/25 | 编辑：李呈| 阅读：1,0851 前言在学习OpenDaylight的过程中，总是遇到AD-SAL( API-Driven SA L)和MD-SAL（Model-Driven SAL）等概念。
在努力查找资料学习之后，有了一点学习笔记，写出来加深印象。
同时也给同样迷惑的同学一点帮助。
2 About MD-SALMD-SAL使得在SDN控制器那些丰富的服务和模块可以使用统一的数据结构和南向和北向的API。
上图引用地址：https:///images/4/4d/SAL-C omparison.pngMD-SAL提供请求路由（request routing）和基础设施去支持服务的适配，但它不提供服务的适应本身;业务适配是由插件提供。
MD-SAL认为适配插件是一个普通的插件：它向SAL提供数据，并通过模型生产的API 来读取消费数据。
2.1 Request outing为SAL中，request routing可用于消费者的请求路由，从而寻找到对应的生产者。
当一个plugin注册之后，就会在routing table中有对应记录，consumer向SAL发起RPC应用申请的时候，会由request routing 查找routing table，找到对应的plugin。
在md-sal/sal-binding-api/...、binding/api/rpc目录下可以找到Rp cRouter.java等文件，都与RPC routing有关。
当然request routing还有notification的routing,并不仅仅只是rpc。
1 registerService(ng.Class<S\> clazz, S service, java.util.Dictionary<ng.String,?> properties)可实现bundle的注册。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
.
4
与Floodlilght的简单区别
• 采用OSGI框架，各模块间功能隔离开来，有利于扩展性、而且可以动态部署。OSGI的依赖
关系管理，有多种实现方式，可以通过 Dependency Manager 对象来注册服务，并通过反 射注明依赖的服务。而Floodlight只是单纯的java包之间的引用，扩展性不好，支持的南 向接口少，目前只有OF1.0；但是易于上手。是一个Openflow控制器.
所提供服务
•Data Packet Services 为数据报文的处理，提供服务 •Topology Service为应用提供节点和链路的更新信息， •Inventory service为如节点或者节点连接提供API查询 •Flow Programming Service 流编程服务 •Resource service资源服务，
dependencymanager对象，
•2）再获取全局相关的服务，每个实现通过dm创建一个componet，接着配置这个componet。
这里每个Component就是一个服务，里面说明了导出的接口和依赖的接口
•3）然后将这个componet放到dm和缓存（并发map：dbglobalinstances）中。接着向osgi容
.10对于Fra bibliotek个Packet-in的处理过程
•OF中的核心，Controller
南向设备通信的控制台，与Flooodlight中的Controller类功能 类似，相对简化，Of报文首先到达Controller,会将此报文发送 对已经注册过监听of报文的类中进行处理，其中 DatapacketMuxDemux只处理packet-in报文 ，其会进一步处理，交由处理DiscoveryService（处理的是 LLDP）,其后，交给实现了Ipluginoutdatapacketservice SAL层处理，最后交给实现了Ilistendatapacket监听报文的应用。 这与Floodlight处理报文的过程同。
相互协作，
• SAL：整个架构引入了业务抽象层，将服务抽象化，使得上层（北向）和下层（南向）之
间的调用相互隔离.
• MD(Model Drive)：使用Yang工具，使用业务模型驱动来设计接口、实现业务功能，根据
yang文件，Yang工具直接生成业务管理的“骨架”，主要用于南北接口数据的适配，使开 发者真正专注于具体业务。
• bundle的抽象基类，管理全局和容器相关的服务，当然bundle本身就是一个大服务。 •Container是OpenDaylight中的一个网络域，有很多链接信息、整个域网络信息等，由
ContainerManager管理容器 。而OSGI管理各个bundle;
•每个具体的接口实现和容器的Container为关键字通过DependencyManager(依赖管理)创建
的接口，最后放到dm及缓存中。会在CM的bundle启动中调用。
• CreateServiceDependency()生成服务依赖对象，需要被子类调用，在配置componet的依
赖关系的时候需要用到。
.
7
Bundle启动过程
•1）每个bundle都会从start(context)启动，先根据osgi上下文信息，生成bundle对应的
器注册iContaineraware接口以便容器的生命周期转换点调用。
•4）最后调用bunndle的钩子函数init()。该函数的功能代码的注释已经概括的很明确。
.
8
ArpHandler
• ArpHandler 所实现的接口有 Ihostfinder, Ilistendatapacket, Icacheupdateaware，
.
5
OpenDayLight中的bundles
•核心基类 ：ComponentactivatorabstractBase 实现了 Osgi提供的 BundleActivator,
以自己定义的容器接口iContaineraware,从中发现各个bundle之间、Componet之间、全局和 容器Container之间的依赖和调用关系。
opendaylight
总体架构分析 模块，osgi Bundle 与floodlight之间的简单对比 SAL层 之OF Packet的处理流程 Md-SAL－模型化驱动简单分析 Clustering－集群
.
2
.
3
核心技术
• OSGi：由于采用OSGi体系结构，其技术提供一种面向服务的架构，将应用视为对等模块的
一个Componet，每个Component就是一个服务，里面说明了导出的接口和依赖的接口。 DM以Component的形式来管理依赖关系。
.
6
主要方法如下：
• Start(context)启动方法，会遍历其所提供的实现，依次配置依赖关系。 • getGlobalImplementations()获取全局的实现类，其导出接口的实现类。 • getImplementations() 获取容器相关的实现 。 • Configureglobalinstance(c, Imps[i])，c是前面提到的component • configureInstance（）在一个容器中配置实现的依赖关系。 • containerCreate(String containerName)配置Componet，里面说明了导出的接口和依赖
• 如前在所介绍的，其没有全局的实现，不会在启动过程中，配置Component，其会在先而
会在ContainerManager,启动后，调用在调用configureInstance，配置依赖关系。
bundle启动过程中导出这个接口，并通过Createservicedependency()生成服务依赖对象。
其所依赖的对象，都是其它budnle所导出的接口，如依赖于SAL层的DataPacketService， DijkstraImplementatio，这个模块中所导出的Irouting接口，负责寻路。完成对ARP报文的 处理。
.
9
SAL服务抽象层
主要作用将服务抽象出来，不管控制器和网络设备之间 使用何种协议，提供协约国的一服务，是odl 的核心设计，支持多种南向协议，为各模块和应用提供一致的服务，这些服务的实现 ，是由插件公开 (基于已存在的组件（如OF）和网络设备的功能）)的所提供的接口，但是与SAL是松耦合的。具体将请 求，映射到相应的插件，完成服务。