写在前面
这是我入门SDN以来的第一篇论文，它是一篇中文综述，看起来相对容易。也让我对SDN有了进一步的认识。下面是我的一些心得。
全文框架
SDN 将数据平面与控制平面解耦合,简化了网络管理.
- SDN诞生背景。
- SDN三层结构及关键技术
- 数据层
- 控制层
- 应用层
- SDN 在不同应用场景下的最新研究成果。
- 未来工作。
概述
- 随着网络规模的不断扩大,封闭的网络设备内置了过多的复杂协议,增加了运营商定制优化网络的难度,科研人员无法在真实环境中规模部署新协议。
- 同时,互联网流量的快速增长(预计到2018年,全球流量将达到1.6´1021字节[1]),无法做到真正的负载均衡，网络运营商的变革意愿强烈。
- SDN起源于Stanford的Clean Slate 研究课题，Mckeown 教授正式提出了SDN 概念。
- SDN分为三层
- 控制层：可编程的控制器，掌控全网信息。
- 数据层：哑的(dumb)交换机,仅仅负责转发功能。
- 应用层：通过北向接口与控制层交互，实现特定的需求。
1. SDN的体系结构
SDN 标准接口机制确保层次之间既保持相对独立,又能正常通信,因此,标准接口设计的好坏是SDN 成功设计的关键.
1.1 SDN诞生背景
随着网络的快速发展,传统互联网出现了如传统网络配置复杂度高等诸多问题,这些问题说明网络架构需要革新
当然最先出现的不是SDN，而是一些其它的可编程网络架构，这些可编程网络的相关研究为SDN的产生提供了可参考的理论依据。
| 架构名称 | 特点 | 缺陷 |
|---|---|---|
| 主动网络 | 允许数据包携带用户程序,并能够由网络设备自动执行.用户可以通过编程方式动态地配置网络,达到了方便管理网络的目的。 | 需求低、协议兼容性差 |
| 4D架构 | 将可编程的决策平面(即控制层)从数据平面分离,使控制平面逻辑中心化与自动化。 |
借鉴计算机系统的抽象结构,未来的网络结构将存在转发抽象、分布状态抽象和配置抽象这3 类虚拟化概念。
| 抽象类型 | 简介 |
|---|---|
| 转发抽象 | 剥离了传统交换机的控制功能,将控制功能交由控制层来完成,并在数据层和控制层之间提供了标准接口,确保交换机完成识别转发数据的任务. |
| 分布状态抽象 | 控制层需要将设备的分布状态抽象成全网视图,以便众多应用能够通过全网信息进行网络的统一配置 |
| 配置抽象 | 用户仅需通过控制层提供的应用接口对网络进行简单配置,就可自动完成沿路径转发设备的统一部署 |
- SDN标准制定组织：ONF（Open Networking Foundation）
1.2 体系结构概述
针对不同的需求，许多组织提出了相应的架构。
SDN架构
- SDN 架构最先由 ONF 组织提出,并已经成为学术界和产业界普遍认可的架构。
- 数据平面与控制平面之间利用SDN 控制数据平面接口(control-data-plane interface,简称CDPI)进行通信,CDPI 具有统一的通信标准,目前主要采用OpenFlow 协议。
- 控制平面与应用平面之间由SDN 北向接口(northbound interface,简称NBI)负责通信,NBI 允许用户按实际需求定制开发。用户无需关心底层设备的技术细节,仅通过简单的编程就能实现新应用的快速部署。
- 数据平面由交换机等网络元素组成,各网络元素之间由不同规则形成的SDN 网络数据通路形成连接。
- 控制平面包含逻辑中心的控制器,负责运行控制逻辑策略,维护着全网视图。通过访问CDPI代理来调用相应的网络数据通路。
NFV架构
- 欧洲电信标准化组织(European Telecommunications Standards Institute,简称ETSI)提出的 NFV 架构随之发展起来,该体系结构主要针对运营商网络。
- 网络运营商的网络由专属设备来部署,这些专属设备功能变得繁杂,而管理这些繁杂的硬件设备造成运营成本及能耗的增加,从而导致运营商网络的发展遇到瓶颈。
- NFV采用了资源虚拟化的方式,在通用设备上运行虚拟机或者容器来实现网络功能,NFV降低了设备成本,缩短了新网络服务的部署周期,从而适应网络运营商的发展需求。
- NFV 既可以基于非OpenFlow 协议，例如ForCES等多种传统接口标准化协议,又能与OpenFlow协同工作。
OpenDaylight架构
- 由各大设备厂商和软件公司共同提出了OpenDaylight,目的是为了具体实现SDN 架构,以便用于实际部署。
- OpenDaylight 继承了SDN架构形式,同时又结合了NFV 的特点。
- ODL与SDN都具有三层架构，ODL的控制层采用自带的Java虚拟机实现。
- ODL与SDN架构最大的不同在于:OpenDaylight控制器的南向接口除了支持OpenFlow 协议之外,还支持NETCONF等配置协议和BGP等路由协议,并支持生产厂商的专有协议(如思科的OnePK 协议).
- 为了能够处理不同的标准协议,OpenDaylight 增加了服务抽象层SAL,它负责将不同的底层协议标准转换成OpenDaylight 控制层所理解的请求服务。
三种架构对比
1.3 开放式接口与协议设计
东西向接口
- 由于单一控制机制容易造成控制节点失效,严重影响性能,可采用多控制器方式,此时,多控制器之间将采用东西向通信方式。
南向接口协议
- 逻辑上,它既要保证数据层与控制层之间的正常通信,又要支持两层独立更新。
- 物理上,设备生产厂商需要开发支持这种标准接口的设备,因为传统网络设备是不能在SDN 网络之中运行的。
- 然而南向接口协议有很多种。
Openflow
- 主流的南向接口是Openflow，是基于流的概念来匹配规则的,因此,交换机需要维护一个流表(flow table)来支持OpenFlow,并按流表进行数据转发,而流表的建立、维护及下发均由控制器来完成。
- Openflow发展史
| 版本 | 简介 |
|---|---|
| Openflow 1.0.0 | 规定流表头为12 元组(如源/目的IP 地址、源/目的MAC 地址等.然而,1.0.0 版本还不完善,如支持的规则和动作过少、仅支持单表、无关联动作的组合容易造成组合爆炸等问题。 |
| Openflow 1.1.0 | 增加了部分规则,并开始支持多级流表、群组表和动作集等功能 |
| Openflow 1.2 | 增加了对IPv6 源/目的地址的支持 |
| Openflow 1.3 | 支持流控机制 |
| Openflow 1.4.0 | 增加了流表删除和复制机制,并考虑了流表一致性问题. |
- 随着OpenFlow 支持的功能不断增加,流表将容易产生负载过重的问题。如何支持不同粒度、任意组合的功能,是OpenFlow 下一步发展的关键所在。
- Openflow 并未指定如何配置和管理转发设备环境,因此,ONF 提出了OF-CONFIG 协议。作为配置协议,OF-CONFIG 扩展了NETCONF 标准,采用XML 配置交换机环境,填补了OpenFlow 在配置方面的缺失。
ForCES协议
- IETF 提出了ForCES 协议。
- ForCES 对网络设备内部结构重新定义,将转发元素(forwarding element,简称FE)和控制元素(control element,简称CE)分离,形成两个独立的逻辑实体。
- 两个逻辑实体之间依靠 ForCES 协议通信.该协议工作在主从模式下,即,CE 通过ForCES协议主动将指令下发给FE,FE 被动接受这些指令,并通过硬件执行每数据包级的分组转发。
OnePK
- 思科公司提出了OnePK 协议。
- OnePK 则是思科公司针对 SDN 产品专门开发的接口协议,该协议可以运行在思科所研发的专属平台上,并支持开发者用C 或Java 编写的程序。OnePK 除了支持专有的OnePK 协议之外,还可支持OpenFlow 协议等。
典型的三种南向接口协议对比
