SDN及ODL概括性总结

1、SDN是什么？
SDN(Software Defined Network)即软件定义网络，是一种网络设计理念。

网络硬件可以集中式软件管理，可编程化，控制转发层面分开，则可以认为这个网络是一个SDN网络。

SDN 不是一种具体的技术，不是一个具体的协议，而是一个思想，一个框架，只要符合控制和转发分离的思路就可以认为是SDN.
2、传统网络面临的问题？
1）传统网络部署和管理非常麻烦，网络厂商杂，设备类型多，设备数量多，命令行不一致2）流量全局可视化难
3）分布式架构中，当网络发生震荡时，网络收敛过程中，有可能出现冗余的路径通告信息4）网络流量的剧增，导致底层网络的体积膨胀、压力增大；网络体积越大的话，需要收敛的时间就越长
5）想自定义设备的转发策略，而不是网络设备里面的固定好的转发策略
-------->sdn网络可以解决的问题
3、SDN的框架是什么
SDN框架主要由，应用层，控制层，转发层组成。

其中应用层提供应用和服务（网管、安全、流控等服务），控制层提供统一的控制和管理（协议计算、策略下发、链路信息收集），转发层提供硬件设备（交换机、路由器、防火墙等）进行数据转发、
4、控制器
1）控制器概述
在整个SDN实现中，控制器在整个技术框架中最核心的地方控制层，作用是上接应用，下接设备。

在SDN的商业战争中，谁掌握了控制器，或者制定了控制器的标准，谁在产业链条中就最有发言权
2）控制器功能
南向功能支撑：通过openflow等南向接口技术，对网络设备进行管控，拓扑发现，表项下
发，策略指定等
北向功能：目前SDN技术中只有南向技术有标准文案和规范，而北向支持没有标准。

即便如此，控制器也需要对北向接口功能进行支持，REST API,SOAP,OSGI,这样才能够被上层的应用调用
东西向功能支持：分布式的控制器架构，多控制器之间如何进行选举、协同、主备切换等3）控制器的种类
目前市场上主要的控制器类型是：opendaylight （开发语言Java），Ryu(开发语言python), FloodLihgt(开发语言Java)等等
5、opendaylight（ODL）控制器介绍
ODL拥有一套模块化、可插拔灵活地控制平台作为核心，这个控制平台基于Java开发，理论上可以运行在任何支持Java的平台上，从Helium版本开始其官方文档推荐的最佳运行环境是最新的Linux（Ubuntu 12.04+）及JVM1.7+。

ODL控制器采用OSGi框架，OSGi框架是面向Java的动态模型系统，它实现了一个优雅、完整和动态的组件模型，应用程序（Bundle）无需重新引导可以被远程安装、启动、升级和卸载，通过OSGi捆绑可以灵活地加载代码与功能，实现功能隔离，解决了功能模块可扩展问题，同时方便功能模块的加载与协同工作。

自Helium版本开始使用Karaf架构，作为轻量级的OSGi架构，相较于早前版本的OSGi提升了交互体验和效率，当然其特性远不仅仅于此。

ODL控制平台引入了SAL（服务抽象层），SAL北向连接功能模块，以插件的形式为之提供底层设备服务，南向连接多种协议，屏蔽不同协议的差异性，为上层功能模块提供一致性服务，使得上层模块与下层模块之间的调用相互隔离。

SAL可自动适配底层不同设备，使开发者专注于业务应用的开发。

此外，ODL从Helium开始也逐渐完成了从AD-SAL（Application Driven Service Abstraction Layer）向MD-SAL（Model Driven Service Abstraction Layer）的演进工作，早前的AD-SAL，ODL控制平台采用了Infinispan技术，Infinispan是一个高扩展性、高可靠性、键值存储的分布式数据网格平台，选用Infinispan来实现数据的存储、查找及监听，用开源网格平台实现controller的集群。

MD-SAL架构中采用Akka实现分布式messageing。

6、ODL的总体框架
ODL控制器主要包括开放的北向API，控制器平面，以及南向接口和协议插件。

北向API 有OSGI和REST两类，同一地址空间应用使用OSGI类，而不同地址空间的应用则使用REST 类。

OSGI是有状态的连接，有注册机制，而rest是无状态链接。

上层应用程序利用这些北
向API获得网络智能信息、运行算法进行分析并且设计部署新的网络策略
控制器平台包括一系列功能模块，可动态组合提供不同服务。

其中主要包括拓扑管理、转发管理、主机监测、交换机管理等模块。

服务抽象层SAL是控制器模块化的核心，自动适配底层不同的设备，使开发者专注于业务应用的开发。

SAL北向连接功能模块，以插件的形式为之提供底层设备服务。

南向连接多种协议插件，屏蔽不同协议的差异性，为北向功能模块提供一致性服务，SAL起到中间调度作用。

7、ODL的版本信息
ODL的版本目前已发布了四个版本，按元素周期表元素进行命名。

四个版本分别是Hydrogen(氢)版本、Helium(氦)版本、Lithium（锂）、Beryllium（铍）。

Hydrogen(氢)版本分为三个版本：Base、Virtualization、Service Provider。

Helium(氦)版本有下列版本：Helium、Helium-SR1、Helium-SR1.1、Helium-SR2、Helium-SR3、Helium-SR4
Lithium（锂）版本Lithium-SR1、Lithium-SR2、Lithium-SR3、Lithium-SR4
Beryllium（铍）版本Beryllium，Beryllium-SR1
备注：SR：修正版或更新版，修正了正式版推出后发现的Bug。

8、ODL在设计的时候遵循了六个基本的架构原则
1）、运行时模块化和扩展化（Runtime Modularity and Extensibility）：支持在控制器运行时进行服务的安装、删除和更新。

2）、多协议的南向支持（Multiprotocol Southbound）：南向支持多种协议。

3）、服务抽象层（Service Abstraction Layer）：南向多种协议对上提供统一的北向服务接口。

Hydrogen中全线采用AD-SAL，Helium版本AD-SAL和MD-SAL共存，Lithium和Beryllium中已基本使用MD-SAL架构。

4）、开放的可扩展北向API（Open Extensible Northbound API）：提供可扩展的应用API，通过REST或者函数调用方式。

两者提供的功能要一致。

5）、支持多租户、切片（Support for Multitenancy/Slicing）：允许网络在逻辑上（或物理上）划分成不同的切片或租户。

控制器的部分功能和模块可以管理指定切片。

控制器根据所管理的分片来呈现不同的控制观测面。

6）、一致性聚合（Consistent Clustering）：提供细粒度复制的聚合和确保网络一致性的横向扩展（scale-out）。

9、什么是SAL?
1）SAL的全称为Service Abstraction Layer（服务抽象层），分为MD（Model-Driven）与AD（Application-Driven）两种。

SAL为整个OpenDaylight项目框架提供基础设施服务，包括了各种OpenDaylight开发需要用到的基础功能，类似于Linux内核。

AD-SAL与MD-SAL 并没有本质上的区别，只是API消费者与供应者之间的查询路由方式有所区别。

在AD-SAL 中，并没有使用Y ANG对相关请求与通知功能进行建模，而是直接静态地使用了Java APIs 进行路由与适配。

在MD-SAL方式中，首先需要使用YANG对南向插件需要实现的功能建行功能建模，再使用YangTools与Maven生成相关Java APIs，通过对模型的查询来动态地进行路由与适配
2）Ad-sal的工作机制
←北向Plugin可以通过调用AD-SAL的北向API来实现对南向Plugin的调用，操作其所管理的设备和服务。

AD-SAL中，抽象服务由南向和北向API实现，南北向API是一对一映射关系。

← 开发者在使用AD-SAL开发时需要考虑到下层协议Plugin对抽象层所提供的功能的支持程度
3）MD-SAL的工作机制（未看完）
学习中的难点：maven模块,yang tool工具，osgi模型。