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控制重构视为对控制命令乃至工作的威胁；复杂的社会性挑战：角色和权力的改变。
