论文_浅谈SDN网络中的OpenFlow技术

浅谈SDN网络中的OpenFlow技术
摘要：本文对OpenFlow的技术体系结构进行了分析研究，并且根据集团数据中心云计算环境的特点提出了OpenFlow流表设计模型，分析了如何基于流表进行数据包转发。

设计了适用于集团数据中心云计算网络的流表匹配方案，利用用户空间和内核空间进行流表快速匹配，以达到提高转发效率的目的。

最后，按照标准的OpenFlow测试用例进行匹配项匹配测试，验证了方案的可行性。

关键词：OpenFlow SDN 云计算网络
1．引言
集团数据中心网络以硬件网络设备为基础，每一个机房模块
为一个三层网络域，造成不同机房模块之间的虚拟机迁移受到阻碍。

用户在申请计算资源的过程中，包括业务上线、下线、创建
和回收计算资源都是动态完成的，而相关的网络配置信息，如网
段的网关、接口所允许的VLAN信息等都需要人工配置，这为网络管理和运维带来了新的挑战。

基于OpenFlow技术所设计的SDN网络，是将传统网络中的控制层面与转发层面相分离，将基础物理网络作为Underlay网络，虚拟网络作为Overlay网络，在不改变物理连接的情况下，可以让申请计算资源的过程中同步完成相关网络配置，减少人工干预和
网络运维压力。

2．SDN与OpenFlow概述
2.1 SDN架构
软件定义网络（Software Defined Networking, SDN）的核心思想是将数据转发层面与控制层面解耦，并以编程的方式定义网络架构，SDN架构（如图1）分为转发层、控制层和业务层。

图1 SDN架构图
控制器开放北向接口与业务应用进行交互，南向则使用OpenFlow协议与交换机通信与管理，SDN网络具有很好的感知与管控能力，它并不是具体的网络协议，确切的说是一种新的体系框架，它推动网络向更新更好的方向发展[1]。

2.2 OpenFlow技术模型
OpenFlow技术的体系架构中包括三个重要的组成部分，分别是OpenFlow的控制器、交换机和协议（如图2）。

OpenFlow
交换机
控制器
安全通道
流表
图2 OpenFlow架构图
OpenFlow控制器是OpenFlow整体架构的核心大脑，用它来实现对网络中的交换机进行集中控制，OpenFlow控制器通过安全通道连接到OpenFlow交换机，并且将流表下发至OpenFlow交换机。

OpenFlow交换机承载着从控制器上下发来的流表信息，根据此信息进行数据报文的转发和更新流表信息。

控制器开放北向的API接口，通过云平台进行调用[2]。

3．OpenFlow流表匹配与转发
3.1 OpenFlow流表结构
流表是OpenFlow协议的重要组成部分之一，数据匹配与转发过程需要通过流表项进行匹配，它与传统物理网络设备上的转发表很相像。

在众多流表项当中，匹配域与优先级二者决定了流表项的大部分功能，整个流表结构如表1所示：
表1 流表结构
匹配域：是匹配数据包进入交换机时的端口、报文头等消息。

从1.0版本开始的12个匹配域，最新版已经可以支40个匹配域，
可以做到非常精确的匹配。

表2为1.0版匹配域示例。

表2 OpenFlow匹配域
顺序。

流表项的匹配，优先级值大的优先级更高，优先级的值是0-65535。

计数器：记录了大量的信息，包括匹配成功和丢弃的数据包，流表的超时时间。

计数器可以针对很多个维度进行统计。

指令集：对于匹配上的流表进行后续动作的指定。

匹配到流表项后网络中的数据包需要进行的处理操作。

包括Meter、Apply_Actions、Clear_Actions、Write_Actions、Write_Metadata、Goto_Table。

超时时间：主要包括两种超时时间，分别是idle time和hard time，idle time 表示的是空闲超时，在特定时间内没有数据包进行匹配，则会删除表项。

硬超时hard time 只要阈值超过超时时间的设置则会删除表项。

Cookie：插入Cookie作为控制器流表下发的标识项。

3.2 OpenFlow流表匹配过程
OpenFlow 交换机中流表匹配的过程，首先要将报文拆开进行数据报文头的匹配解析，再经过由优先级不同的流表以此进行匹配，并且数据包都是基于流进行转发和执行动作，所有报文进入
交换机接口后的动作都会根据匹配结果进行（如图3）。

图3 流表匹配流程
有两种获取流表的方式，第一种是主动获取，全部收集的信息由控制转化成流表发送到交换机；第二种是被动获取，在交换机未能匹配的数据包上传给控制器，因为控制器为整个网络的核心大脑，由它决定如何处理后，下发给交换机相应的流表信息。

被动获取无需维护全部的流表信息，当交换机有真实的流量转发时在获取流表保存即可[3]。

3.3 OpenFlow数据转发流程
OpenFlow中数据包都是基于流转发的，所有报文进入交换机端口后交换机根据匹配结果，执行流表动作。

在多级流表中处理流程是流水线型的，流水线跳转处理时只能是大于自己表号的流表中跳转，以避免环路的发生。

数据包处理流程如图4所示：
根据匹配域（入端口+数据包头+元数据）找出优先
级最高的流表项；
执行指令集：
修改数据包并更新匹配域
更新动作集
更新元数据
将匹配数据和动作集发送到下一流表
图4 数据包流水线处理流程
OpenFlow交换机中的流表从0开始按照顺序编号。

流水线处理总是从第一张流表开始，即数据包最先与编号为0流表中流表项匹配，根据匹配结果进行后续流表匹配流程，最后在流水线处理结束时执行指令集。

多级流表的流水线处理，使得指令集不断累积，从而实现更为复杂的网络业务。

4．OpenFlow流表匹配优化与测试
4.1 OpenFlow流表优化方案
本方案采用纯软件实现流表匹配，纯软件方式实现的交换机为Open vSwitch（简称OVS）。

为了解决软件方案实现流表匹配效率相对低下的问题，结合Linux内核，将流表分布在内核空间和用户空间两个部分。

其中用户空间实现OpenFlow交换机的核心功能，包括与控制器的交互，流表的维护,相关配置信息的存储，及对内核空间流表的维护等。

系统的用户空间工作效率相比内核空间要低，则可以设计用户空间完成流表匹配的业务处理流程，而流表的快速匹配功能选择在内核空间中实现。

内核空间保存一定
时间内的流表，其功能相对单一，仅仅负责数据包和流表的匹配以及对匹配后的动作项执行。

内核空间流表的更新、添加、删除是由用户空间维护的，而且在内核空间未匹配上流表后，也是由用户空间进行处理。

数据包在内核空间以及用户空间整体转发流程[4],如图5所示：
图5 用户空间与内核空间流表匹配整体流程图数据包要经过内核空间端口进入OpenFlow交换机后，先是在内核空间实现快速流表匹配流程，如果匹配成功则根据匹配结果得到的动作集执行动作。

数据包在内核态实现的是精确匹配，一般是通过匹配二层MAC地址、入端口以及用户态下发的其他字段实现的，不同报文不会匹配到同一条内核空间流表。

如果数据包在内核空间未能匹配到相关流表，则将数据包上传到用户空间，在用户空间实现流表的匹配。

根据匹配结果直接对数据包执行动作，同时下发流表到内核态，方便后续同类报文能在内核态实现快速匹配。

如果数据包在用户空间也没有匹配到流表，则会根据
OpenFlow 交换机的默认配置执行动作。

用户空间和内核空间都保存流表，但用户空间保存的流表是很据网络业务生成的规则,用户可根据具体网络业务下发配置生成用户空间流表。

内核空间流表仅仅是用于数据包的快速匹配，其流表是根据用户空间的流表（规则）生成的。

为了保证网络业务及时生效，内核空间流表会有老化时间，一般老化时间在秒级范围。

内核空间流表特点是数量多,更新快,匹配速度也快,用户空间流表则相对处理速度慢，但它可配置、体现网络的全局配置。

4.2 流表项匹配测试
控制器与虚拟机之间通过OVS 相互连接，三台测试虚拟机进行发包测试，通过OVS 所在控制器节点抓取数据包进行分析。

各种匹配项在流表中的流程各不相同，所以在流表之间的相互作用下构造出不同的内核空间流表。

测试环境抽象图如图6所示：
test-1test-3
控制器test-2OVS
图6 流表匹配测试网络拓扑图
以测试匹配dl_src 源MAC 地址为例，选择测试虚拟机1为源
MAC地址，目的MAC地址选择测试虚拟机2，优先级设置高于默认normal，便于优先匹配。

使用iperf流量测试工具发送流量，在控制器所在主机使用tcpdump抓包工具进行报文收集。

报文中只有测试虚拟机1发往测试虚拟机2的数据流量，在测试虚拟机3上并没有，说明流表匹配是正确的。

4.3 匹配项覆盖域测试
本文中对流表的匹配项的覆盖情况做了处理，用户空间是根据整体网络的全局流表生成向内核空间下发的流表信息，并不会将内核空间的流表覆盖。

用户空间流表配置如下：
流表1：
priority=20,in_port=9,dl_src=test1_mac,dl_dst=test2_mac,action s=drop
流表2：
priority=30,in_port=9,dl_src=test1_mac,dl_dst=test2_mac,tcp,act ins=output_test3
流表1会匹配源MAC地址是虚拟机1的和目的MAC地址是虚拟机2的数据包进行丢弃。

流表2优先级高于流表1，在协议匹配上为TCP，会将此数据包转发到虚拟机3。

该流表将源MAC地址为虚拟机1和目的MAC地址为虚拟机2的MAC地址的数据包丢弃。

在测试虚拟机1上持续发送UDP 报文到测试虚拟机2上，此时内核空间只产生流表1的表象。

然后通过测试虚拟机1向测试虚拟机2发送TCP报文。

在测试虚拟
机3上tcpdump抓取的报文发现接收到了TCP的报文信息。

虽然流表1在匹配项上完全覆盖流表2的内容，但是转发成功，所以用户空间根据整体网络的全局流表生成向内核空间下发流表信息的设计思路是正确的。

5．结论
本文在以OpenFlow为代表的SDN快速发展的背景下，针对云计算数据中心虚拟交换机的应用场景，提出一种流表存储方案和基于该存储方式的流表匹配方案。

经过测试，验证了方案的可行性。

未来，云计算数据中心OpenFlow技术将更多专注于性能的提升以及对智能网络策略的支持，我们还会继续跟进，争取早日实现应用到生产环境。

参考文献：
[1] Thomas D. Nadeau. 软件定义网络SDN与OpenFlow解析.人民邮电出版社2014.
[2] Nick McKeown, Tom Anderson, Hari Balakrislinan, et al. OpenFIow: enabling innovation in campus networks.[J]. Computer Communication Review, 2008, 38(2): 69-74
[3]Open Networking Foundation. ONF Overview. [OL].
[4] 李向文. 支持OpenFlow交换机的关键技术研究与实现[D]武汉邮电科学研究院, 2014。