基于控制集群的SDN流表更新机制

刘惠临， 林亚飞

（安徽理工大学 计算机科学与工程学院，安徽 淮南 232001）

0 引 言

软件定义网络（Software Defined Networking，SDN）是一项新兴的网络技术，针对目前互联网中云计算、大数据等业务需要快速、灵活的实时配置和调度网络资源的需求，创造性地提出了网络控制功能和数据转发功能分离的设计思想，实现网络状态在逻辑上的集中控制。其中远程的SDN控制器实现链路发现、拓扑管理、流表下发等一系列基本操作；交换设备只负责高效率的数据转发，而进行转发决策的指导规则也下发自集中控制器［1］。

1 背景知识

目前在SDN技术中，ONF标准化组织提出的架构在业界的影响力最大，该架构中面向数据层的南向接口为OpenFlow协议，该协议对转发规则抽象称之为流表（Flow Table），相当于传统网络设备的二层MAC地址转发表和三层IP路由表。

OpenFlow协议中流表项主要由3部分构成，如图1所示。

图1 OpenFlow控制系统简单架构

其中Header fields（包头域）用来和交换机接收到的数据包的包头做匹配；而Counter（计数器）记录交换机数据流的相关计量信息；Actions用来决定匹配后的数据包下一步应该怎么处理（见图1），交换机所能执行的Actions（动作）大致可以分为4种：

1）转发数据包给设备的物理端口或一系列的虚拟端口；

2）没有明确转发动作的表项，将丢弃其匹配的数据包；

3）修改数据包的包头内容；

4）转发数据包给控制器做下一步处理［2］。

在SDN技术所提出的概念中，传统网络的层次化架构被消除，源 MAC地址、目的 MAC地址、VLAN id、源IP地址、目的IP地址、TCP／UDP端口等这些原本属于各网络层级的信息，被统一封装到1个流表项中，集中控制器由于相对传统分布式网络的各独立设备具有全局拓扑视图能力，从而能更有效地利用各类路由算法生成数据转发策略并下发。流表下发到交换机后，存储在三态内容寻址存储器（Ternary Content addressable Memory，TCAM）上。

OpenFlow流表的更新过程相对比较复杂，因为规则的制订是由集中控制器完成，而不是依靠各交换设备的独立算法在本地实现。如果控制器能够确保在多个交换机上的流表更新是实时和同步完成的，那么对于所有数据包的处理就具有一个统一的指导原则；但是实际情况并非如此，控制器向分布式的多个交换机写入的新流表项的动作是按照先后顺序执行的，这会导致数据包在不同交换机上可能按新规则处理，也可能按旧规则处理。同时，由于常规的SDN网络拓扑结构中，控制器只设置1个，从而给控制器带来了繁重的处理负担和安全风险（一旦控制器故障或遭破坏，则整个SDN网络运转可能会陷入瘫痪）。

2 需解决的问题

根据以上相关知识的描述，可以总结归纳出流表运行维护过程中几个亟待解决的关键问题：首先是更新一致性［3］，即由于数据转发层面的分布式特性，任意数据包在传输过程中，只能按照统一规则匹配处理，而不能在不同交换机上依次按旧、新规则中的流表项处理；其次是集中控制系统所带来的可靠性和安全风险问题。现有研究中对这些问题尚未有较为成熟的方案，因此，针对它们展开研究，对SDN网络技术的发展具有重要意义。

3 控制集群

针对前文提出的两方面问题，首先关注控制器的可靠性问题，后续工作中搭建的网络拓扑结构为规避控制器带来的系统风险，需依赖此问题的解决方案。

OpenFlow控制器的可靠性受制于集中化所带来的缺陷，单一控制器出现的意外状况会给整个网络带来巨大影响，所以，在这里引入控制集群（或称多控制器）的概念，即通过多个控制器的分工协作分散风险和决策处理负担。网络中的交换机在初始化阶段需建立一个或多个控制器的链接。多个控制器之间为主从关系，即选择1台控制器作为主控制器，基本的设计架构如图2所示。

目前的SDN网络领域尚未有多控制器之间建立联系的东西向扩展技术，但实际上目前的SDN控制器都是软件方法实现的，所以控制器是安装在服务器平台上的，为此，文中利用现在已相当成熟的服务器集群技术来搭建控制器集群，如Lifekeeper，ROSE等集群软件。当然控制器集群有其特殊性，最为关键的是主控制器的选择，主控制器负责全网域内的交换机和其它控制器状态信息的生成和维护，全网拓扑信息的归集和下发。

主控制器的选取可以利用已有的多种分布式集群的主节点选取算法，实现难度并不大，但需要考虑算法的复杂度以及由网络质量问题引起的延迟等。为进一步提高控制集群的协同性，可以在协议中增加一种“身份”消息用来明确控制器之间的主从关系。该消息的值设置有3种，缺省值是EQUAL，此时控制器的“身份”为可以响应交换机发来的请求；该值还可以设为SLAVE，此时控制器只能监听网络状态但不能响应，实际相当于将控制器设定为“副”控制器；当值设为 MASTER时，该控制器就作为“主控制器”存在，但集群系统中有且只有1个MASTER。

4 保持流表更新一致性的机制

4.1 方案描述

为了解决流表的更新一致性问题，文中提出一种基于过渡规则的机制，这里的过渡规则指的是新规则集向旧规则集转换的过程中同时出现在两套规则中的共同流表项。

根据对数据更新一致性问题的理解，利用上述函数标记规定如下形式的两条定义：

1）对任意数据包 p，H （p）＝H1（p）或H2（p）；

2）假如对数据包p有H（p）＝H2（p），那么对于同一数据流中的后继数据包q，也应有H（q）＝H2（q）。

对流表更新机制而言，如果SDN网络对数据包的转发结果符合上述两条定义，则可以称作该机制满足数据更新一致性。综合上述研究基础以及定义，可以详细叙述该机制的实施方案，文中将该方案的运作分为如下4个时间段：

4.2 网络拓扑结构

为了进一步阐述更新机制，我们建立了一个SDN网络拓扑结构，在该结构中，对控制器采用了控制集群的形式，以避免系统在更新过程中由控制系统带来的风险和隐患。数据流从主机Host 1到达Host 2所经由的交换机集合为｛u，t，s，v，r，w，y，z｝；基于规则1的数据转发路径用实线表示，而基于规则2的数据转发路径用虚线表示，如图3所示。

图3 SDN网络拓扑

数据包上传的对象是控制器集群，这里采用主、副两部控制器，它们之间通过负载均衡技术实现协作运行（分担数据包的接收、规则的下发等工作）。过渡规则的数据包转发示例如图4所示。

图4 过渡规则的数据包转发示例

图4中，基于过渡规则的数据转发用带箭头的虚线表示，交换机u，v将数据包上传给了控制集群，但w，y，s，z和t却没有上传，原因如下：数据包从Host1到达Host2的转发过程中，如基于h1处理，则无法到达w，y，t，在处理规则转变为h12时，数据包或者是被交换机u，v拦截后上传控制集群，或者是继续按照规则1继续转发；经过s，z转发的数据包，其处理方式保持不变，如果s，z已经加载了过渡规则后，仍然接收到数据包，那么则说明u，v还没有完成过渡规则的替换，所以s，z对此时接收到的数据包可以继续按照规则1路径转发。

4.3 逻辑证明

文献［4－5］对一致性机制进行逻辑证明，实际就是验证该机制能否满足文中两条定义的要求，其中主要是定义1的验证，证明的过程可以拆解为3个部分：

综上所述，对任意数据包p，在网络中转发时H（p）＝H1（p）或 H2（p）。

5 结 语

文中提出的更新机制解决了流表更新一致性的问题，具有一定的通用性，并且利用控制集群有效降低了控制负载，提高了可靠性。在后期研究过程中，还有一些需要关注的方面，例如OpenFlow流表项存储开销几倍于传统交换机，但是TCAM存储器又比较昂贵，所以需要精简流表的尺寸；控制集群的相互通信机制也需要进一步改进［7－8］。

［1］毕军.软件定义网络SDN与OpenFlow解析［M］.北京：人民邮电出版社，2014：65－103.

［2］雷葆华，王峰.SDN核心技术剖析和实战指南［M］.北京：电子工业出版社，2013：29－78.

［3］Reitblatt M，Foster N，Rexford J，et al.Abstractions for network update［C］／／Proceedings of the ACM SIGCOMM Conference on Applications，Technologies.New York：Architectures and Protocols for Computer Communication，2012：323－33.

［4］McGeer R.A safe，efficient update protocol for openFlow networks［C］／／Proceedings of the First Workshop on Hot Topics in Software Defined Networks.New York：ACM，2012：61－66.

［5］左青云，陈鸣.基于OpenFlow的SDN技术研究［J］.软件学报，2013，24（5）：1078－1097.

［6］王淑玲，李济汉.SDN架构及安全性研究［J］.电信科学，2013，3（20）：117－122.

［7］王明倩，任月鸥.基于 Web服务的应用集成研究［J］.长春工业大学学报：自然科学版，2008，29（6）：705－708.

［8］裘晓峰，赵粮，高腾.VSA和SDS两种SDN网络安全架构的研究［J］.小型微型计算机系统，2014，34（10）：2298－2303.