SDN与OpenFlow架构--初识

一，为什么需要SDN

1，传统网络的缺点：

　　a，传统网络及其设备的只可配置，不可编程，只能按照已定义好的协议处理或转发数据，不能适应需求新变化，不能自主开发新功能。

　　　　如购买一个电饭煲，可以煮饭，煲汤。但是我突然想煮玉米，这就不行了。

　　b，网络的分布式控制与管理架构带来的制约。如果在网络中新增加一个设备，其流经链路上的网络设备在规划和配置上可能都要发生变化。

　　　　网络的部署，配置与管理需要落到每台设备上去手工完成，每个设备都紧耦合了三个层面，分别是管理平面，控制平面，数据平面。

• 管理平面：配置和管理网络设备提供用户访问界面或窗口（命令行或图形界面）。
• 控制平面：路由表，MAC表和MPLS标签表等控制表是数据平面数据转发的依据。
• 数据平面：根据控制平面相关控制表给出的信息，进行具体的报文处理或转发。

2，SDN的出现：

a，SDN的设计思想：

• 解耦：将控制平面和管理平面提取出来，在转发设备上只留下数据平面；实现了控制平面和数据平面的解耦，通过控制器管理其所属的转发设备，这些转发设备没有路由器，交换机之分。
• 抽象：将SDN架构按照计算机模型抽象成SDN模型，OpenFlow交换机模型，NOS（网络操作系统）操纵下的全局网络视图。
• 可编程：除了传统的命令行接口和网关协议，还可以通过Shell脚本，Python脚本对整个网络进行管理。

　　控制逻辑和数据转发分离和网络可编程是SDN最为显见的优势。

b，SDN三层架构：SDN将传统转发设备中的控制平面提取成控制器，将管理平面提取成各类应用

　　三层架构是如何运作的：如果我只想让基础设施层的设备实现集线器的功能，我可以在应用层编写一个Python脚本，交给控制器，每当基础设备有数据不知道怎么处理时，它会把这个包交给控制器处理，控制器执行脚本后将会回复这个基础设备应该向哪里转发，似乎就是一个数据包经过了一个集线器一样。

　　所以我们可以在应用层编写不同的脚本去自定义数据报的处理方法。

二，OpenFlow架构

　　OpenFlow三层架构是ONF定义的SDN主流技术架构，对转发面进行了标准化，控制层与转发层采用OpenFlow协议。

　　OpenFlow架构如下：

　　

　　4大平面和2大接口

　　

　　~~四大平面：

• 应用平面：主要处理负载均衡，访问控制，应用加速等问题
• 控制平面：核心是控制器（也叫网络操作系统NOS），主要将SDN应用层请求转换到SDN Datapath（如上面所说的Python脚本）和为SDN应用提供底层网络抽象模型（通过不断与底层交换机的交互保持实时更新）
• 数据平面：网元和它所包含的SND数据通路就像是传统网络中，二级交换级和MAC表。区别在于MAC表是二级交换机自己生成的，而SDN数据通路是控制器下发的
• 管理平面：负责静态工作，如网元初始化配置，指定控制器和定义控制器应用范围等

　　~~两大接口：

• 北向接口：向应用层提供抽象的网络视图，使应用能直接控制网络的行为；

　　　　　　　　控制器将网络能力封装后开放接口，供上层应用调用。

　　　　　　　　直到目前，还没有一个标准的北向接口协议，REST API成为SDN北向接口的主流设计。

• 南向接口：实现转发行为控制，设备性能查询，同级报告，事件通知等功能。最流行的南向接口协议是OpenFlow协议。下图是控制器通过OpenFlow1.0协议和交换机交互

　　

　　顺便，也说一下东西向接口

　　

　　因为控制器为了提高处理效率和减轻控制器的压力，类似于DNS服务器，采取的分布式布局（如Google B4网络架构）。借助东西接口，可以选举和协同控制器，切换主备控制器等。

　　~~ OpenFlow架构需要理解的三个组成部分：

• 流表：指示交换机如和进行流的处理。
• 安全通道：负责控制器与交换机之间的交互，也就是走一些相关的OpenFlow协议。
• OpenFlow协议：定义了一种南向接口标准。

三，OpenFlow协议详解

1，OpenFlow协议的版本：

　　到目前为止一共有1.0到1.5这6个版本，其中1.0和1.3版本是最常用，稳定的版本。

• OpenFlow1.0=》只支持 Ip4，和以下各个版本不兼容

　　

• OpenFlow1.1：流水线，组表，形成流水线处理流表匹配的各个过程，能避免单流表过度膨胀的问题
• OpenFlow1.2 ：可扩展匹配，多控制器，IP6
• OpenFlow1.3 ：计量表（控制关联流表的数据包的传输效率)，IP6扩展头，支持的匹配关键字增加到40个
• OpenFlow1.4 ：在1.3增加流表同步机制（多个流表可以共享相同的匹配字段，还可以定义不同的动作）
• OpenFlow1.5 ：在入向匹配的基础上增加出向流表

　　1.3版本及以后控制器通过OpenFlow协议与交换机交互

　　

2，流表项：

　　每个流表都有特定条目的流表项（Flow entry），每个流表项里包括动作（丢弃，转发，交给下一个流表等）。传统网络对匹配到的流只有两种处理，丢弃或转发。　　

　　当然，流表中不会只有动作这一个流表项，以OpenFlow1.0为例，还有源目IP，MAC地址等，这些数据放在包头域中，它们决定了交换机执行怎样的动作；同时还有计数器，以监测流的动向，实现流量可视化，充分利用链路。

　　OpenFloqw1.0中的动作

　　

　　OpenFlow可以对数据包头部进行修改，这是跟传统网络最大的区别

　　到了OpenFlow1.3版本，流表项变成了

　　

• 包头域改为匹配域，增加优先级，动作改为指令，增加超时时间和cookie）
• 优先级用于标志流表项匹配的优先次序，优先级越高越早匹配，默认优先级为0
• 计数器主要对每张表，每个端口，每个流等进行计数，方便流量监管（如多少流量流经这个端口，这张表查找了多少次）
• 通过指令可以生成动作集（动作集里的动作按顺序执行）

3，流表匹配：

　　OpenFlow1.1版本：多流表的流表匹配称为流水线处理，交换机从流表0开始查找，序号从小到大；每个包按照流表的优先级依次去匹配流表中表项，优先级高的优先匹配，一但匹配成功，对应的计数器将立即更新；如果没能找到匹配的表项，则转发给控制器。

　　1.3版本及以后的

　

区别：a，之前匹配到表直接执行动作，现在可能会先丢到动作集里去

　　　b，没有表匹配，之前是交给控制器，丢弃或交给下一个流表。现在，table-miss是一个参数（即流表项只要存在这个参数，就算未匹配也

　　　　会往动作集里加动作），用于解决未匹配流的丢弃和转发问题 。table-miss是通过将匹配域的所有字段（所有网络字段都可能作为匹配域）

　　　　均改为通配符ANY来实现的。

　　  c，当流表项的指令集中不包含GoTo-Table时，才执行动作集里的动作。

另一种表示：

Tip：对动作集的相关操作

由于流水线匹配是按照流的特征据决定处理的方法，所以流表项都有相应的指令集。但是有些指令集对不同流都是适用的，例如：不同的流可能会有相同的下一条IP地址

这时如果每个流表项都添加这个动作，则会在一定程度上造成资源的浪费，影响数据平面转发的效率。于是就是有了=》

组表：OpenFlow交换机只含有一个组表，独立与流水线之外。组表中包含许多组表项，每条组表项的结构如下：

4，如何生成流表

　　首先需要了解交换机与控制器之间的交互

　　

• Hello：建立连接用Hello初始化　
• Features Request就是控制器问交换机有什么功能。如接口，配置，地址，宽带信息等
• set config，控制器做一个简单的适合交换机的设置 =》至此，交换机和控制器相互认识
• packet in 如果交换机缓存足够，只会将分组头信息和在缓存里的序号发给控制器；如果缓存不足，则会将整个数据分组封装进Packet-in消息发送给控制器

　　如：pc1 ping pc2，但是交换机没有流表，不知道往哪个接口发，就需要先把这个包打包好向控制器申请流表

• packet out 封装好数据分组传给OF交换机
• port status 如端口被shot down掉，端口寻址到新的mac地址，维持网络视图的实时更新。

　　Flow-mod：下发流表项如（match *，output all）广播数据包=》这样就让交换机变成了集线器。也可以删除和修改流表。

　　OpneFlow v1.0中的Flow-mod消息格式

　　

OpenFlow协议三类消息：

5，举个例子：

假设初始化一个最为简单SDN模型，主机h1想 ping 一下h2，会经历哪些过程？

• h1向交换机发送arp包
• 交换机将arp包封装packet-in给控制器
• 控制器packet out给交换机一个流表项，因为这个模型是刚初始化的，所以交换机里没有流表，控制器将会命令这个交换机广播这个数据包来寻找h2
• h2收到交换级转发的arp request，回复自己的mac和ip等信息
• 交换机收到h2发来的arp reply，交换机不知道怎么转发，再次packet-in
• 控制器更新，下发流表项
• 交换机从控制器所指定的端口将arp reply发送给h1

6，OF-CONFIG协议：

　　提供一个开放接口用于远程管理和配置OF交换机

　　作为OpenFlow协议的伴侣协议，构建流表和控制流的走向等由OpenFlow控制，但在交换机上配置控制器IP地址，如何配置交换机端口上的队列则由OF-CONGIF协议完成。

　　OF-CONFIG提供配置OF交换机的能力，这里所指的OF交换机可以是一个物理交换机，也可以是一个虚拟的网络转发设备。

四，SDN的发展现状

• 现阶段多数厂商推出的SDN硬件交换机都是支持混合模式的，利用本身已有的操作系统优势，在系统里增加对OpenFlow协议的支持。

　　　具体思路是数据分组进入混合模式交换机后，交换机根据端口或VLAN进行区分，亦或经过一级流表的处理，以决定是传统模式还是SDN模式。

• 加速商业化，使得传统网络设施支出比例缩水；朝着流量可视化的方向发展。

• 目前面对的挑战：组织机构上的障碍：将SDN控制重构视为对控制命令乃至工作的威胁；复杂的社会性挑战：角色和权力的改变。