随着社会的进步，网络规模急剧膨胀、传输数据量的剧烈增长和应用类型的持续增多，导致传统 IP 网络的结构和功能日趋复杂，尤其是作为网络核心的路由器，通过不断增长的 ＲFC 数量对现行网络进行修补和网络协议的多样化［1］，使其变得臃肿不堪。这与路由器最初的定义目标背道而驰。与此同时，由于专有的硬件设备和操作系统，网络在很大程度上是封闭的，从而造成了创新的艰难。但是，纵观当前网络行业的发展趋势，现有网络中所大量部署的网络设备和网络协议也将在相当长一段时间内延续现有的网络体系结构［2］。
为解决当前传统网络所面临的上述问题，世界各国都开始了对下一代互联网的研究，比如美国的 GENI［3］、欧盟的 FIＲE［4］、日本的 JGN2plus［5］和我国的 SOFIA［6］等。在经过包括 ForCES［7］、4D［8］架构、ＲCP［9］、SANE［10］和 Ethane［11］在内的前期工作基础上，于 2008 年，斯坦福大学的 Nick McKeown 教授提出了 OpenFlow［12］概念，并逐渐推广到 SDN 概念。其核心思想是: 将路由决策控制功能从传统 IP 网络互联节点解耦出来，即与数据转发平面分开，支持集中化的网络状态控制，实现底层网络设施对上层应用的透明，能够通过软件编程实现硬件对数据的转发规则的控制。这是一种新型的网络架构，设计之初是为了方便研究员在真实的网络流量环境中利用现有基础设施来进行实验，验证其观点，进行创新［2］。
SDN 一经提出便受到了学术界和产业界的高度重视，给传统网络带来巨大冲击的同时，也为解决传统网络所面临的问题提出了新的思路。
1 基于 OpenFlow 的 SDN 组件
基于 OpenFlow 的 SDN 构架主要由两部分组成:
OpenFlow 交换机和控制器。OpenFlow 交换机是数据转发平面，根据流表负责数据的转发; 而控制器则是路由管控平面，负责抽象底层设备，维护全网视图。如图 1所示。【1】
OpenFlow 交换机至少包含 3 部分: 流表 ( FlowTable) 、安全通道 ( Secture Channel) 和 OpenFlow 协议( OpenFlow Protocol) 。其中流表主要由流表项组成，即匹配字段( Match Field) 、计数器( Counter) 和操作( Action)等; 安全通道则用于连接交换机和控制器的通道接口，负责两者互相通信; 而 OpenFlow 协议则是为控制器提供了一种标准格式来配置和管理 OpenFlow 交换机。
控制器( Controller) : 如图 2 所示，在 ONF 给出的软件定义网络体系架构中［13］，控制层中的控制软件，与基础设施中的交换/路由等网络设备经由控制和数据平面接口交互，与应用层各种 APP 经由开放 API 交互。总之，控制器对下负责底层网络设备的抽象，对上负责提供并维护全局视图，提供应用层的各种 APP 的接口。【2】
2 现有控制平面扩展性问题及解决
随着 SDN 关注度的提升，随之而来的是研究投入的加强和应用的增加，机遇增加的同时也带来了挑战。
如在扩展平面方面，随着网络规模的增加，一味提升集中控制器的性能不能解决，必须增加控制器数量来分担任务; 再者控制器数量的增加，又会带来控制器的放置问题，根据不同的性能指标，放置问题也会多种多样。下面将列举出 SDN 控制平面所遇到的问题即解决方案，介绍 SDN 扩展平面的发展。
2. 1 控制器数量的变化
在 SDN 提出初期，其控制平面的一种设计就是将所有的控制功能移到一个集中控制器上，即单控制器。
一经提出，研究人员便将全部精力集中在控制器性能及应用的高效性、创新性和实用性上，尤其是在数据中心网络，经常利用中央控制器来进行协调和资源调度，其在文献［14 ～ 20］中均有体现。文献［14］中实时地为流再次计算新的路径，文献［16］中强制性的为包路由使其能够符合策略，文献［18］中主服务器存储分布式文件系统的元数据( Metadata) ，通过大量实验拓扑结构证明，在大多数情况下，单控制器足够管理一个较大的网络。
然而将来是大数据时代，在对大规模网络进行管控时，控制器中存储的数据量过大，所需处理的请求事件过于频繁，必将导致 SDN 控制器流表的爆炸性增长，流的映射及查询开销剧烈增加; 同时，单一控制器的处理能力及 I/O 能力均有限，在面对大规模网络的复杂应用，必然会产生系统性能瓶颈。文献［19］介绍了一种解决方案，即将简单的控制功能移植到交换机上，减少了提交给交换机的事件请求，诸如此类思想的产品有 DIFANE 和 DevoFlow。虽也提高了控制平面的可扩展性，但交换机需要特殊的 ASIC( Application －Specific － Integrated Circuits) 和一般性能的 CPU 来实现这些简单功能，这就需要生产商的支持，从而增加了难度，且这种思想也违背了 SDN 设计理念。
早期关于 SDN 的提议均是基于流的，其都会产生额外的流初始化时延，文献［20］中详细阐述了单控制器在扩展性方面所面临此的问题，即若网络直径足够大，控制器的部署位置同样会对流的建立延迟产生影响。
图 3 较好地说明了此问题: 相比右图，左图中仅有一个控制器，当跨区域建立流表和通信时均会产生额外的时延。早期在 NOX［21］上进行的基准实验，表明单控制能每秒处理 3 000 个流初始化，其中包含 0. 1 ms 的流安装时间。在该种情况下，多控制器的思想便应运而生。其思想是用多个独立的控制器来替代一个全能的控制器，每个控制器只负责部分网络，使其共同管控整个网络，逻辑上相当于一个中央控制器。【3】
2. 2 控制器布控问题
多控制器解决了单控制器的性能瓶颈问题，但同时也带了许多新的问题，其中最相关的是控制器的数量和部署以及全局状态的一致性问题。
部署问题，即对于给定的网络拓扑，控制器该如何放置、每个控制器管理哪些交换机等。以不同的性能指标为标准，比如可靠性、安全性和一致性等，又有不同的放置方案。国外已有了相关研究，文献［22］通过大量的实验，以平均时延和最坏时延为衡量标准，针对不同拓扑结构，来研究控制器所需数量以及控制器在拓扑中所放置的位置对时延的影响，也证明了随机部署与科学部署对时延的影响。但本文并未得出一个一般性的、适用于所有的网络拓扑的结论，控制器的数量和位置随拓扑的变化而变化。
而控制器的部署，重点是分区问题，即对于广域网，需要将其划分为多个子网，多个控制器分别管理其域内交换机。文献［37］中，介绍了更具有普遍性的多控制器管控网络的区域划分算法，引入了 DevolvedController 的概念。提出了 Path － partition 和 Partition －path 两种启发式算法，前者先路由再划分区域; 而后者是先划分区域再路由。通过测试分析，两者各有优略，前者能够使每个控制器监控的链路数更少，但由于其需要考虑每个控制器中已划分的链路，故其所找到的路径更长，更适合常规网络，而后者更适合非常规网络，如 fat － tree 网络等。具体情况需具体分析，恰当地选取更合适算法。
时延只是控制器部署所需考虑的一个方面因素，可靠性也是一个必须考虑的因素。可靠性主要是指控制器与交换机、控制器之间的通信。之间某条链路或者交换机出了故障，都会破坏正常的数据转发或者全局的一致性。文献［38］提出了“受保护”交换机概念，使故障快速恢复的可能性最大，但只适合单控制器情况。文献［23］提出了一种贪婪的控制器放置算法，但其可靠性近似公式准确性欠佳。而文献［24］在两者基础上提出了基于聚类的控制器放置算法和基于贪婪的控制器放置算法，分别实现了全局和局部的可靠性优化效果。但其结果与随机放置算法相对比，无法证明其算法的优势。文献［25］也提出了类似的控制器优化部署，在一定程度上增强了故障恢复能力，但也均有局限性。
另外，在 SDN 控制平面安全性方面，相比前者，相关研究较少。集中化的控制面承载着网络环境中的所有控制流，是网络服务的中枢机构，其安全性直接关系着网络服务的可用性、可靠性和数据安全性，是 SDN安全首先要解决的问题。文献［26］提出了 AVANT －GUAＲD 这种新的架构，通过在 OpenFlow 数据平面增加相关功能，来应对 SDN 安全问题。其能够抵御侵透攻击，比如 TCP － SYN 洪，增强了 SDN 网络的弹性和可扩展性。但为了实现此功能，OpenFlow 交换机需足够的指令来处理模块操作。文献［27］提出了一种检测 DDOS 攻击的方法; 文献［28］则设计了一种识别大的聚集流量功能，用于检测网络异常的方法。
2. 3 SDN 控制器架构
近年来，学术界和工业界研究人员已开始探索建立分布式 SDN 控制器架构，用于解决控制平面所面临的扩展性和可靠性问题，使得网络的运营管理达到最佳的状态。文献［29］对控制器的平面结构做了高度的概括和总结可分为 3 类: ( 1) 集中控制器，即单控制器，如 NOX 等。( 2) 去中心化结构，平面类型，每个控制器地位相等，根据每个控制器的逻辑拓扑视图，又可分为两类: 一种为每个控制器拥有相同的全局试图，如HyperFlow、Onix; 另一种为每个控制器只拥有局部试图。( 3) 分层结构，即控制器分为不同的等级，等级越低监控的区域越小，等级越高监控的范围越大，如Kandoo。
2. 3. 1 单控制器模型单控制器比较成熟的模型有 NOX［30］、Beacon［31］、Meastro［32］等，其在一定程度上能代表单控制器模型。
文中将从各个单控制器开闭源、开发语言、是否支持OpenFlow 协议、是否支持多线程、开发单位及适用化境等进行比较。【4】
2. 3. 2 多控制器控制平面模型HyperFlow［33］，基于事件的分布式控制平台。HyperFlow平面采用逻辑集中物理分散方式，是 OpenFlow 方面的第一个分布式控制平面。HyperFlow 通过在网络中部署多台控制来管理 OpenFlow 交换机，每台交换机同步共享全局网络视图的同时，只需管理本区域内的OpenFlow 交换机。控制器之间通过数据信道、控制信道和自身的信道，发布/订阅模式，来互相通信。经分析测试结果发现: 在足够的控制带宽下，HyperFlow 能够处理频率 ＜ 1 000 次/s 的网络事件，略有不足; 再者，全网视图的更新和控制器之间的信息发布与传输时延紧密相关等等。所以，HyperFlow 在面临一致性要求高、网络事件更新频繁之类的大型网络中，可能会面临瓶颈。
Onix［34］在可靠性、可扩展性和通用性方面，更胜一筹。Onix 网络构架由物理网络基础设施、网络连接基础设施、Onix 和网络控制逻辑等部分组成，通过 NIB( Network Information Base) 来维护网络全局的状态，通过 3 种策略来实现控制平面的可扩展性: 分区、聚合、一致性和稳定性。此外，Onix 的全局网络视图分布在低层次不同的分布式控制器上，在上层逻辑节点进行聚合决策。虽 Onix 的 NIB 采用的是较成熟的分布式系统，但也继承了其缺点。总体而言，Onix 是基于OpenFlow 的 SDN 发展的一个方向: 多控制器分区管控。使用 Python/C ++ 语言基于 Linux 平台上开发，用于解决较大规模真实网络的部署方案。
Kandoo［35］一种分层结构，其中有两种等级的控制器: 拥有全局视图的逻辑中心根控制器( Ｒoot Controller)和只拥有局部视图的局部控制器( Local Controller) ，每个交换机只能被一个 Kandoo 控制器控制，每个 Kandoo控制器可控制多个交换机。其使用 C、C ++ 和 Python共同开发，较低的内存成本，支持动态可加载的插件，插件可由 C、Python 和 Java 实现。支持 OpenFlow 协议实验证明，单 Kandoo 控制器在 Xeon E7 － 4807 使用单线程，可接收来自512 个交换机超过每秒1 MB 的吞吐量。【5】
3 研究方向展望
传统网络创新的艰难和缓慢，与 SDN 形成了鲜明的对比，引起了越来越多的机构和组织的关注。但其带来机遇的同时也提出了挑战，尤其是可扩展性方面。
文献［36］指出可扩展性既不是 SDN 引起的，也不是SDN 特有的，可在不失去 SDN 优势的同时解决可扩展性问题。但根据不同的性能指标，扩展性方面的侧重类型也不同，在可靠性和区域划分方面研究的较多，但安全方面却较少，属于起步阶段。一个成熟的网络应该全面发展，不能厚此薄彼。再者，如上所述的 SDN控制平面的 3 种架构，每种均有其适用环境、优点和缺点，但未来发展的趋势并未达成共识，有利于促进其共同发展的同时，也不利于统一化标准的制定，如 API等。最后，SDN 提供了一个新的网络架构，但在发展中也遇到了问题，这些问题在传统网络发展中也曾遇到过，如区域的划分，控制器( 服务器) 的部署等等，这些解决方法可借鉴到 SDN 网络当中。
4 结束语
本文介绍了基于 OpenFlow 的 SDN 网络的发展背景和趋势以及其组件，并重点介绍了 SDN 控制平面可扩展性方面遇到的问题及解决方案，对 SDN 可扩展性方面未来研究方向进行了展望。在现阶段，虚拟控制器的发展也成为了热点，下一阶段应结合多控制器和虚拟化中的虚拟控制器，提出针对大规模网络的资源调度问题的解决方案。
参考文献
［1］ 张顺淼，邹复民． 软件定义网络研究综述［J］． 计算机应用研究，2014，30( 8) : 2246 －2251．
［2］ Mckeown N，Anderson T，Balakrishnan H，et al． OpenFlow:enabling innovation in campus networks ［J］． ACM SIG-COMM Computer Communication Ｒeview，2008，38 ( 2 ) :69 － 74．
