软件学报  2015, Vol. 26 Issue (1): 62-81   PDF    
软件定义网络(SDN)研究进展
张朝昆, 崔勇, 唐翯祎, 吴建平    
清华大学 计算机科学与技术系, 北京 100084
摘要:网络抽象促使软件定义网络(software-defined networking,简称SDN)的产生.SDN将数据平面与控制平面解耦合,简化了网络管理.首先从SDN诞生发展的背景入手,梳理了SDN的体系结构,包括数据层、控制层和应用层,并按照SDN的层次结构深入阐述其关键技术,特别分析了一致性、可用性和容错性等特性.然后,论述了SDN在不同应用场景下的最新研究成果.最后,展望未来研究工作.
关键词软件定义网络     接口     交换机     控制器     网络抽象    
State-of-the-Art Survey on Software-Defined Networking (SDN)
ZHANG Chao-Kun, CUI Yong, TANG He-Yi, WU Jian-Ping    
Department of Computer Science and Technology, Tsinghua University, Beijing 100084, China
Abstract: Network abstraction brings about the naissance of software-defined networking. SDN decouples data plane and control plane, and simplifies network management. The paper starts with a discussion on the background in the naissance and developments of SDN, combing its architecture that includes data layer, control layer and application layer. Then their key technologies are elaborated according to the hierarchical architecture of SDN. The characteristics of consistency, availability, and tolerance are especially analyzed. Moreover, latest achievements for profiled scenes are introduced. The future works are summarized in the end.
Key words: SDN (software-defined networking)     interface     switch     controller     network abstraction    

传统网络的层次结构是互联网取得巨大成功的关键.但是随着网络规模的不断扩大,封闭的网络设备内置了过多的复杂协议,增加了运营商定制优化网络的难度,科研人员无法在真实环境中规模部署新协议.同时,互联网流量的快速增长(预计到2018年,全球流量将达到1.6x1021字节[1]),用户对流量的需求不断扩大,各种新型服务不断出现,增加了网络运维成本.

SDN起源于2006年斯坦福大学的Clean Slate研究课题[2].2009年,Mckeown教授正式提出了SDN概念[3].利用分层的思想,SDN将数据与控制相分离.在控制层,包括具有逻辑中心化和可编程的控制器,可掌握全局网络信息,方便运营商和科研人员管理配置网络和部署新协议等.在数据层,包括哑的(dumb)交换机(与传统的二层交换机不同,专指用于转发数据的设备).交换机仅提供简单的数据转发功能,可以快速处理匹配的数据包,适应流量日益增长的需求.两层之间采用开放的统一接口(如OpenFlow[4]等)进行交互.控制器通过标准接口向交换机下发统一标准规则,交换机仅需按照这些规则执行相应的动作即可.因此,SDN技术能够有效降低设备负载,协助网络运营商更好地控制基础设施,降低整体运营成本,成为最具前途的网络技术之一.因此,SDN被MIT列为“改变世界的十大创新技术之一”[5].SDN相关技术研究迅速开展起来,成为近年来的研究热点.2013年,SIGCOMM会议收录了多篇相关文章,甚至将SDN列为专题来研讨,带动了SDN相关研究的蓬勃发展.

本文第1节首先论述SDN诞生与发展的背景,以此提出SDN分层的体系结构,并讨论SDN开放式接口.第2节和第3节分别对SDN数据层和控制层的关键技术进行详细阐述.第4节论述SDN在不同场景下的应用.第5节针对未来工作提出见解.最后给出本文结论.

1SDN体系结构

SDN是当前最热门的网络技术之一,它解放了手工操作,减少了配置错误,易于统一快速部署.本节首先论述了SDN诞生发展的背景,指出SDN的产生及快速发展的必然性定律.接下来探讨了SDN主流的体系结构.由于SDN标准接口机制确保层次之间既保持相对独立,又能正常通信,因此,标准接口设计的好坏是SDN成功设计的关键.

1.1SDN诞生发展的背景

随着网络的快速发展,传统互联网出现了如传统网络配置复杂度高等诸多问题[6],这些问题说明网络架构需要革新,可编程网络的相关研究为SDN的产生提供了可参考的理论依据[7].主动网络[8,9]允许数据包携带用户程序,并能够由网络设备自动执行.用户可以通过编程方式动态地配置网络,达到了方便管理网络的目的.然而由于需求低、协议兼容性差等问题,并未在工业界实际部署.4D架构[10,11]将可编程的决策平面(即控制层)从数据平面分离,使控制平面逻辑中心化与自动化,其设计思想产生SDN控制器的雏形[12].

借鉴计算机系统的抽象结构,未来的网络结构将存在转发抽象、分布状态抽象和配置抽象这3类虚拟化概念[13].转发抽象剥离了传统交换机的控制功能,将控制功能交由控制层来完成,并在数据层和控制层之间提供了标准接口,确保交换机完成识别转发数据的任务.控制层需要将设备的分布状态抽象成全网视图,以便众多应用能够通过全网信息进行网络的统一配置.配置抽象进一步简化了网络模型,用户仅需通过控制层提供的应用接口对网络进行简单配置,就可自动完成沿路径转发设备的统一部署.因此,网络抽象思想解耦了路径依赖,成为数据控制分离且接口统一架构(即SDN)产生的决定因素.

此外,众多标准化组织已经加入到SDN相关标准的制订当中.专门负责订制SDN接口标准的著名组织是开放网络基金会(Open Networking Foundation,简称ONF)[14],该组织制订的OpenFlow协议业已成为SDN接口的主流标准,许多运营商和生产厂商根据该标准进行研发.互联网工程任务组(Internet Engineering Task Force,简称IETF)的ForCES工作组[15]、互联网研究专门工作组(Internet Research Task Force,简称IRTF)的SDNRG研究组[16]以及国际电信联盟远程通信标准化组织(ITU Telecommunication Standardization Sector,简称ITU-T)的多个工作组[17]同样针对SDN的新方法和新应用等展开研究.标准化组织的跟进,促使了SDN市场的快速发展.据悉,SDN市场已于2013年达到约2亿美元的产值,预计到2016年将达到20亿美元[18],市场需求确保SDN有足够的发展空间.由此可见,SDN具有广阔的发展前景和巨大的研究价值.

1.2 体系结构概述

针对不同的需求,许多组织提出了相应的SDN参考架构.SDN架构[19]最先由ONF组织提出,并已经成为学术界和产业界普遍认可的架构.除此之外,欧洲电信标准化组织(European Telecommunications Standards Institute,简称ETSI)提出的NFV架构[20]随之发展起来,该体系结构主要针对运营商网络,并得到了业界的支持.由各大设备厂商和软件公司共同提出了OpenDaylight[21],目的是为了具体实现SDN架构,以便用于实际部署.

ONF组织最初在白皮书中提到SDN体系结构[19],并于2013年底发布最新版本[22],其架构如图 1所示.SDN由下到上(或称由南向北)分为数据平面、控制平面和应用平面.数据平面与控制平面之间利用SDN控制数据平面接口(control-data-plane interface,简称CDPI)进行通信,CDPI具有统一的通信标准,目前主要采用OpenFlow协议[4].控制平面与应用平面之间由SDN北向接口(northbound interface,简称NBI)负责通信,NBI允许用户按实际需求定制开发.

Fig. 1 SDN architecture图 1 SDN体系结构

数据平面由交换机等网络元素组成,各网络元素之间由不同规则形成的SDN网络数据通路形成连接.控制平面包含逻辑中心的控制器,负责运行控制逻辑策略,维护着全网视图.控制器将全网视图抽象成网络服务,通过访问CDPI代理来调用相应的网络数据通路,并为运营商、科研人员及第三方等提供易用的NBI,方便这些人员订制私有化应用,实现对网络的逻辑管理.应用平面包含着各类基于SDN的网络应用,用户无需关心底层设备的技术细节,仅通过简单的编程就能实现新应用的快速部署.CDPI负责将转发规则从网络操作系统发送到网络设备,它要求能够匹配不同厂商和型号的设备,而并不影响控制层及以上的逻辑.NBI允许第三方开发个人网络管理软件和应用,为管理人员提供更多的选择.网络抽象特性允许用户可以根据需求选择不同的网络操作系统,而并不影响物理设备的正常运行.

NFV[20]是针对运营商网络出现的问题而提出的SDN解决方案.网络运营商的网络由专属设备来部署,随着各种新型网络服务的产生,这些专属设备功能变得繁杂,而管理这些繁杂的硬件设备造成运营成本及能耗的增加,从而导致运营商网络的发展遇到瓶颈.针对上述问题,NFV将传统网络设备的软件与硬件相分离,使网络功能更新独立于硬件设备.为此,NFV采用了资源虚拟化的方式,在硬件设备中建立一个网络虚拟层,负责将硬件资源虚拟化,形成虚拟计算资源、虚拟存储资源和虚拟网络资源等,运营商通过软件来管理这些虚拟资源.由于采用的是通用硬件设备,NFV降低了设备成本,减少了能耗,缩短了新网络服务的部署周期,从而适应网络运营商的发展需求.在接口设计方面,NFV既可以基于非OpenFlow协议,又能与OpenFlow协同工作,同时还支持ForCES[16]等多种传统接口标准化协议,以便适应网络运营商对设备的不同需求,并与ONF的SDN保持相对独立的发展.

OpenDaylight[21]的目标是通过SDN的开源开发,推进业界可部署方案具体实施,其架构由设备厂商提出并得到众多IT软件厂商的支持.考虑到兼容性问题,OpenDaylight继承了SDN架构形式,同时又结合了NFV的特点.架构共分为3个层次,分别是网络应用与业务流程(即应用层)、控制平台(即控制层)和物理与虚拟网络设备(即数据层).OpenDaylight的控制平台直接由自带的Java虚拟机实现.针对不同的网络任务,控制器自身携带了一系列可插入模块,并兼容第三方模块以增强SDN的功能.与ONF的SDN架构最大的不同在于:OpenDaylight控制器的南向接口除了支持OpenFlow协议之外,还支持NETCONF[23]等配置协议和BGP[24]等路由协议,并支持生产厂商的专有协议(如思科的OnePK协议[25]).为了能够处理不同的标准协议,OpenDaylight增加了服务抽象层SAL,它负责将不同的底层协议标准转换成OpenDaylight控制层所理解的请求服务,保持了底层协议的透明性,并提高了整体架构的可扩展性.

SDN,NFV和OpenDaylight的对比见表 1.由于NFV与ONF的SDN分别负责不同的网络,两种架构的协同工作能够获得更好的网络体验,将两者结合可以降低设备成本.通过利用通用交换机等设备和软件代替原有设备,使得设备的升级与网络应用的拓展相对独立.OpenDaylight具有开源性,因此,它可以兼容SDN,NFV以及未来与SDN并行的体系结构.总之,无论是哪个组织提出的SDN体系结构,实现的目标是一致的.SDN使得数据控制相分离的网络具有开放性和可编程性,科研人员及运营商可以通过PC机、手机、Web网页或未来可能出现的各种途径进行网络部署,而部署工作也仅是应用软件的简单开发或配置.可以预见:针对SDN并行架构的研究,是未来研究进展的重要趋势之一.

Table 1 Comparison of SDN,NFV and OpenDaylight 表 1 SDN,NFV和OpenDaylight的对比
1.3 开放式接口与协议设计

SDN中的接口具有开放性,以控制器为逻辑中心,南向负责与数据层通信,北向负责与应用层通信.此外,由于单一控制机制容易造成控制节点失效,严重影响性能,可采用多控制器方式[26],此时,多控制器之间将采用东西向通信方式.开放式接口的研究,必然进一步推动SDN的深入发展.

在这些开放式接口研究中,控制器南向接口作为数据与控制分离的核心被广泛研究,成为业界关注的焦点.由于控制层与数据层解耦合,使得针对这两层的改进相对独立,在层与层之间仅需提供标准南向接口即可.南向接口是SDN分层架构的关键元素,然而逻辑上,它既要保证数据层与控制层之间的正常通信,又要支持两层独立更新;物理上,设备生产厂商需要开发支持这种标准接口的设备,因为传统网络设备是不能在SDN网络之中运行的.因此,研发南向标准接口成为SDN基础研究中的重要内容之一.

许多组织着手制订南向标准接口.ONF提出的CDPI成为了主流南向接口,它采用OpenFlow[4]协议. OpenFlow是SDN中第一个广泛使用的数据控制层接口协议,得到学术界普遍关注[27, 28, 29],它将单一集成和封闭的网络设备成为灵活可控的通信设备.OpenFlow协议是基于流的概念来匹配规则的,因此,交换机需要维护一个流表(flow table)来支持OpenFlow,并按流表进行数据转发,而流表的建立、维护及下发均由控制器来完成.

为了便于设备生产厂商开发支持OpenFlow的设备,ONF开始提供OpenFlow协议标准[30].OpenFlow 1.0.0规定流表头为12元组(如源/目的IP地址、源/目的MAC地址等),在一定程度上满足了用户对SDN网络的需求.然而,1.0.0版本还不完善,如支持的规则和动作过少、仅支持单表、无关联动作的组合容易造成组合爆炸等问题.因此,OpenFlow 1.1.0增加了部分规则,并开始支持多级流表、群组表和动作集等功能.IPv6是下一代互联网的核心元素,因此从1.2版本开始,OpenFlow增加了对IPv6源/目的地址的支持.网络拥塞一直是传统互联网需要面临的问题之一,在SDN网络中也是如此,因此,从1.3版本开始支持流控机制.在1.4.0版本中,OpenFlow协议增加了流表删除和复制机制,并考虑了流表一致性问题.总的来说,OpenFlow支持的功能越来越全,机制也在不断地更新完善.然而,随着OpenFlow支持的功能不断增加,流表将容易产生负载过重的问题.如何支持不同粒度、任意组合的功能,是OpenFlow下一步发展的关键所在.此外,OpenFlow允许控制器利用流表指定网络的数据通路,但并未指定如何配置和管理转发设备环境,因此,ONF提出了OF-CONFIG协议[31].作为配置协议,OF-CONFIG扩展了NETCONF标准[23],采用XML配置交换机环境,填补了OpenFlow在配置方面的缺失.

针对南向接口,除了ONF提出的OpenFlow协议和OF-CONFIG协议外,IETF提出了ForCES协议[16],思科公司提出了OnePK协议[25].ForCES对网络设备内部结构重新定义,将转发元素(forwarding element,简称FE)和控制元素(control element,简称CE)分离,形成两个独立的逻辑实体,两个逻辑实体之间依靠ForCES协议通信.该协议工作在主从模式下,即,CE通过ForCES协议主动将指令下发给FE,FE被动接受这些指令,并通过硬件执行每数据包级的分组转发.OnePK则是思科公司针对SDN产品专门开发的接口协议,该协议可以运行在思科所研发的专属平台上,并支持开发者用C或Java编写的程序.OnePK除了支持专有的OnePK协议之外,还可支持OpenFlow协议等.典型的南向接口协议对比见表 2.

Table 2 Comparison of general south interface protocols 表 2 典型的南向接口协议的对比

除了南向接口相关研究之外,控制器北向接口及控制器间东西向接口同样是研究重点.北向接口负责控制层与各种业务应用之间的通信,应用层各项业务通过编程方式调用所需网络抽象资源,掌握全网信息,方便用户对网络配置和应用部署等业务的快速推进.然而,由于应用业务具有多样性,使得北向接口亦呈现多样性,开发难度较大.起初,SDN允许用户针对不同应用场景定制适合的北向接口标准.统一的北向接口标准将直接影响着各项应用业务的顺利开展.为了统一北向接口,各组织开始制订北向接口标准,如ONF的NBI接口标准和OpenDaylight的REST接口标准等.然而,这些标准仅对功能作了描述,而未详细说明实现方式.因此,如何实现统一的北向接口标准,成为业界下一步主要推动的工作.与南北向接口通信的方式不同,东西向接口负责控制器间的通信.由于单一控制器性能有限,无法满足大规模SDN网络部署,东西向接口标准的制订使控制器具有可扩展能力,并为负载均衡和性能提升等方面提供了技术保障.

2 数据层关键技术研究

在SDN中,数据层与控制层分离,交换机将繁重的控制策略部分交由控制器来负责,而它仅根据控制器下发的规则对数据包进行快速转发.为了避免交换机与控制器频繁交互,双方约定的规则是基于流的,而并非基于每个数据包的.SDN数据层的功能相对简单,相关技术研究主要集中在交换机和转发规则方面:首先是交换机设计研究,即设计可扩展的快速转发设备,它既可以灵活匹配规则,又能快速转发数据流;其次是转发规则的相关研究,例如规则失效后的一致性更新问题等.下面详细讨论数据层相关的研究成果.

2.1 交换机设计问题

SDN交换机位于数据层面,用来负责数据流的转发.通常可采用硬件和软件两种方式进行转发.对于硬件来说,具有速度快、成本低和功耗小等优点.一般来说,交换机芯片的处理速度比CPU处理速度快两个数量级,比网络处理器(network processor,简称NP)快一个数量级,并且这种差异将持续很长时间[32].在灵活性方面,硬件则远远低于CPU和NP等可编程器件.如何设计交换机,做到既保证硬件的转发速率,同时还能确保识别转发规则的灵活性,成为目前研究的热点问题.

利用硬件处理数据,可以保证转发效率,但亟需解决处理规则不够灵活的问题.为了使硬件能够灵活解决数据层的转发规则匹配严格和动作集元素数量太少等限制性问题,Bosshart等人[32]针对数据平面转发提出了RMT模型.该模型实现了一个可重新配置的匹配表,它允许在流水线(pipeline)阶段支持任意宽度和深度的流表.重新配置数据层涉及4个方面:① 允许随意替换或增加域定义;② 允许指定流表的数量、拓扑、宽度和深度,仅仅受限于芯片的整体资源(如芯片内存大小等);③ 允许创建新动作;④ 可以随意将数据包放到不同的队列中,并指定发送端口.RMT模型如图 2所示.从结构上看,理想的RMT模型是由解析器、多个逻辑匹配部件以及可配置输出队列组成.具体的可配置性体现在:通过修改解析器来增加域定义,修改逻辑匹配部件的匹配表来完成新域的匹配,修改逻辑匹配部件的动作集来实现新的动作,修改队列规则来产生新的队列.这样容易模拟网关、路由器和防火墙等设备,也能够使用多标记头或非标准的协议.所有更新操作是通过解析器来实现的,无需修改硬件,只需在芯片设计时留出可配置的接口即可,实现了硬件对数据的灵活处理.

Fig. 2 RMT model图 2 RMT模型

作为另一种利用硬件灵活处理技术,FlowAdapter[33]采用交换机分层的方式来实现高效、灵活的多表流水线业务.FlowAdapter交换机分为3层:最上层是可以通过更新来支持任何新协议的软件数据平面,底层是相对固定但转发效率高的硬件数据平面,位于中部的FlowAdapter层负责软件数据平面和硬件数据平面之间的通信.当控制器下发规则时,软件数据平面将存储这些规则,形成M个阶段的流表.由于这些规则相对灵活,不能全部由交换机直接转化成相应转发动作,而硬件数据平面可以实现规则的高速匹配转发.因此可利用中间层FlowAdapter将两个数据平面中的规则进行无缝转换,即,将相对灵活的M阶段的流表转换成能够被硬件所识别的N阶段的流表.为了达到转换目的,FlowAdapter首先检查软件数据平面的全部规则,然后根据完整的规则将M阶段的流表转换成1阶段流表,最后再将1阶段流表转换成N阶段流表发送给硬件数据平面.通过这种无缝转换,理论上解决了传统交换机硬件与控制器之间多表流水线技术不兼容的问题.另外,FlowAdapter相对控制器完全透明,对FlowAdapter交换机的更新不会影响控制器的正常运行.

与利用硬件设计交换机的观点不同,虽然软件处理的速度低于硬件,但是软件方式可以最大限度地提升规则处理的灵活性,同时又能避免由于硬件自身内存较小、流表大小受限[34]、无法有效处理突发流等问题,因而同样受到学术界的关注.利用交换机CPU[35]处理转发规则,可以避免硬件灵活性差的问题.由于CPU处理数据包的能力变得越来越强[36],商用交换机很自然地也会采用这种更强的CPU.这样,在软件处理转发速度与硬件差别变小的同时,灵活处理转发规则的能力得到提升.进一步地,还可以采用NP的处理方式[37].由于NP专门用来处理网络的各种任务,如数据包转发、路由查找和协议分析等,因此在网络处理方面,NP比CPU具有更高效的处理能力.无论采用CPU还是NP,应发挥处理方式灵活性的优势,同时尽量避免处理效率低而带来的影响.

此外,在数据平面中,哪些元素可以交给硬件处理,哪些元素可以交给软件处理,也是值得考虑的问题.例如,原本设计到硬件中的计数器功能并不合理[38],而应当放置到CPU中处理,这样既可以保证计数器的灵活性,又能节省硬件空间,降低复杂度,同时还能够避免硬件计数的限制.

2.2 转发规则相关研究

与传统网络类似,SDN中也会出现网络节点失效的问题,导致网络中的转发规则被迫改变,严重影响了网络的可靠性.此外,流量负载转移或网络维护等也会带来转发规则的变化.SDN允许管理人员自主更新相关规则,但采用较低抽象层次(low-level)的管理方式来更新规则容易出现失误[39],导致出现规则更新不一致的现象.即便没有出现失误,由于存在更新延迟问题,在更新过程中,转发路径上有些交换机已经拥有新规则,而另一些交换机还使用旧规则,仍然会造成规则更新不一致性的问题.

将配置细节进行抽象,使管理人员能够使用较高抽象层次(high-level)的管理方式统一更新,就可防止低层管理引起的不一致性问题.一般采用两阶段提交方式来更新规则[40]:第1阶段,当某个规则需要更新时,控制器询问每个交换机是否处理完对应旧规则的流,并对处理完毕的所有交换机进行规则更新;第2阶段,当所有交换机都更新完毕时,才完成更新,否则将取消该更新操作.为了能够使用两阶段提交方式更新规则,在预处理阶段,对数据包打上标签以标示新旧策略的版本号.在转发过程中,交换机将检查标签的版本,并按照对应版本的规则执行相应的转发动作.当数据包从出口交换机转发出去时,则去掉标签.然而,这种方式需要等待旧规则的数据包全部处理完毕才能处理新规则的数据包,这样会造成规则空间被占用进而产生较高的成本.增量式一致性更新算法[41]可以解决规则空间成本较高的问题,该算法将规则更新分成多轮进行,每一轮都采用二阶段提交方式更新一个子集,这样可以节省规则空间,达到更新时间与规则空间的折中.McGeer提出了基于OpenFlow的安全更新协议[42]来完善抽象层两阶段提交方式的安全性,该协议将无法识别新旧规则的报文发送至控制器,来保证流转发的正确性.此外,规则更新过程需要考虑性能问题.Ghorbani等人[43]研究了虚拟机场景下规则更新算法,该算法可以确保在更新过程中拥有足够的带宽,同时不会影响到其他流的正常转发.

由于OpenFlow无法主动增加未知协议,为保证新协议能在SDN中使用,OpenFlow只能将该协议更新到接口的规格说明书当中,并未真正做到协议无关.因此,如何做到协议无关转发,成为数据平面可扩展的重要研究方向之一.在数据平面建立与协议无关的流指令集(flow instruction set,简称FIS),可以做到协议无关的转发[44].协议无关的FIS抽象了数据平面,每个协议相关的规则会转化成FIS中协议无关的指令,并被数据平面硬件所识别,从而实现快速转发.协议无关的FIS使规则与转发设备无关,提高了数据平面的可扩展性,真正实现了控制平面与数据平面的全面分离.

3 控制层关键技术研究

控制器是控制层的核心组件,通过控制器,用户可以逻辑上集中控制交换机,实现数据的快速转发,便捷安全地管理网络,提升网络的整体性能.本节首先详细阐述了以NOX控制器[12]为基础的两种技术改进方法:一种是采用多线程的控制模式,另一种是通过增加分布式控制器数量,实现扁平式和层次式控制模式.然后介绍了主流接口语言的研究发展,实现控制语言抽象.最后,深入分析了控制器的一致性、可用性和容错性等特性.

3.1 控制器设计问题

控制器的基本功能是为科研人员提供可用的编程平台.最早且广泛使用的控制器平台是NOX[12],能够提供一系列基本接口.用户通过NOX可以对全局网络信息进行获取、控制与管理,并利用这些接口编写定制的网络应用.随着SDN网络规模的扩展,单一结构集中控制的控制器(如NOX)处理能力受到限制,扩展困难,遇到了性能瓶颈,因此仅能用于小型企业网或科研人员进行仿真等.网络中可采用两种方式扩展单一集中式控制器:一种是通过提高自身控制器处理能力的方式,另一种是采用多控制器的方式来提升整体控制器的处理能力.

控制器拥有全网信息,能够处理全网海量数据,因此需要具有较高的处理能力.NOX-MT[45]提升了NOX的性能,它是具有多线程处理功能的NOX控制器.NOX-MT并未改变NOX控制器的基本结构,而是利用传统的并行技术提升性能,使NOX用户可以快速更新至NOX-MT,且不会由于控制器平台的更替产生不一致性问题[46].另一种并行控制器为Maestro[47],它通过良好的并行处理架构,充分发挥了高性能服务器的多核并行处理能力,使其在网络规模较大情况下的性能明显优于NOX.

对于众多中等规模的网络来说,一般使用一个控制器即可完成相应的控制功能,不会对性能产生明显影响[48].然而对于大规模网络来说,仅依靠多线程处理方式将无法保证性能.一个较大规模的网络可分为若干个域,如图 3所示.若保持单一控制器集中控制的方式来处理交换机请求,则该控制器将与其他域的交换机之间存在较大延迟,影响网络处理性能,这一影响将随着网络规模的进一步扩大变得无法忍受.此外,单一集中控制存在单点失效问题.通过扩展控制器的数量可以解决上述问题,也就是将控制器物理分布在整个网络中,仅需保持逻辑中心控制特性即可[49].这样可使每个交换机都与较近的控制器进行交互,从而提升网络的整体性能.

Fig. 3 Single controller in SDN图 3 SDN中的单一控制器

分布式控制器一般可采用两类方式进行扩展[26],分别是扁平控制方式(如图 4所示)和层次控制方式(如图 5所示).对于扁平控制方式,所有控制器被放置在不相交的区域里,分别管理各自的网络.各控制器间的地位相等,并通过东西向接口进行通信.对于层次控制方式,控制器之间具有垂直管理的功能.也就是说,局部控制器负责各自的网络,全局控制器负责局部控制器,控制器之间的交互可通过全局控制器来完成.

Fig. 4 Flat controllers in SDN图 4 SDN中的扁平控制器

Fig. 5 Hierarchical controllers in SDN图 5 SDN中的层次控制器

扁平控制方式要求所有控制器都处于同一层次.虽然物理上各个控制器位于不同的区域,但逻辑上所有的控制器均作为全局控制器,掌握全网状态.当网络拓扑变化时,所有控制器将同步进行更新,而交换机仅需调整与控制器的地址映射即可,无需进行复杂的更新操作,因此,扁平分布式扩展对数据层的影响较小.Onix[50]作为首个SDN分布式控制器,支持扁平分布式控制器架构.它通过网络信息库(network information base,简称NIB)进行管理.每个控制器都有对应的NIB,通过保持NIB的一致性,实现控制器之间的同步更新.HyperFlow[51]允许网络运营商部署任意多个控制器,并将这些控制器分布在网络的各个角落.控制器之间保持着物理分离而逻辑集中的特点,因此仍然保持SDN集中控制的特点.HyperFlow通过注册和广播机制进行通信,并在某控制器失效时,通过手动配置的方式将失效控制器管理的交换机重新配置到新控制器上,保证了可用性.在扁平控制方式中,虽然每个控制器掌握全网状态,但只控制局部网络,造成了一定资源的浪费,增加了网络更新时控制器的整体负载.此外,在实际部署中,不同的域可能属于拥有不同经济实体的运营商,无法做到控制器在不同域之间的平等通信.

层次控制方式按照用途将控制器进行了分类.局部控制器相对靠近交换机,它负责本区域内包含的节点,仅掌握本区域的网络状态.例如,与临近交换机进行常规交互和下发高命中规则等.全局控制器负责全网信息的维护,可以完成需要全网信息的路由等操作.层次控制器交互存在两种方式:一种是局部控制器与全局控制器之间的交互,另一种是全局控制器之间的交互.对于不同运营商所属的域来说,仅需协商好全局控制器之间的信息交互方式即可.Kandoo[52]实现了层次分布式结构.当交换机转发报文时,首先询问较近的局部控制器.若该报文属于局部信息,局部控制器迅速做出回应.若局部控制器无法处理该报文,它将询问全局控制器,并将获取的信息下发给交换机.该方式避免了全局控制器的频繁交互,有效降低了流量负载.由于这种方式取决于局部控制器所处理信息的命中率,因此在局部应用较多的场景中具有较高的执行效率.

SDN网络操作系统应当具有实时运行所开发应用的能力,即,能够达到开发与执行的平衡.NOX采用Python或C++,使用Python时开发效率较高,执行效率较低;而使用C++时执行效率很高,开发效率却很低.于是,科研人员致力于开发通用的平台,尽可能地在开发与执行之间达到一个较好的平衡.Beacon[53]是一个基于Java的通用平台,它向用户提供了一系列相关的库与接口用于开发,并提供运行时模块化的功能,使其在保证性能的情况下具有了实时运行的能力,实现了开发与执行两者之间的平衡.操作系统将资源形成文件系统,文件具有层次结构,方便操作系统随时读取与调用.控制器所管理的资源也具有类似特征,能够使得用户和应用通过标准的文件I/O进行交互.yanc[54]控制器即采用了文件系统的方式处理资源,它把网络应用视为不同的进程,每个进程被分隔成不同的视图或分片(slice).在yanc中,无论物理交换机还是数据流参数都将形成文件,不同的应用则根据自身的需求调用不同的文件.此外,SDN控制器平台已经存在大量实际开发,包括Floodlight[55],POX[56]和Ryu[57]等.典型控制器的对比情况见表 3.

Table 3 Comparison of general controller platforms 表 3 典型控制器平台对比
3.2 接口语言

控制器提供了北向接口,方便用户配置网络.然而,当今的网络存在各式各样的应用,如流量监控、负载均衡、接入控制和路由等.传统的控制器平台(例如NOX[12])仅能提供低级配置接口,且使用像C++这种通用语言,抽象程度较低,造成网络配置成本并未大幅度降低.针对这种情况,科研人员致力于开发一种抽象的、高级配置语言.这些抽象语言能够统一北向接口,改善接口的性能,从而全面降低网络的配置成本.

耶鲁大学团队开发了一系列网络配置语言,旨在搭建具有优化性能的通用北向接口.Nettle[58]是描述性语言,采用了函数响应式编程(functional reactive programming,简称FRP)方式.FRP是基于事件响应的编程,符合控制器应对各种应用的实际响应情况.Nettle的目标是实现网络配置的可编程化,而可编程化的网络配置要求控制器性能足够高,因此,该团队又提出了McNettle[59],一种多核Nettle语言.McNettle并未改变描述性与FRP的特性,而是利用共享内存、多核处理的方式增强了用户开发体验.Procera[60]则进一步对语言抽象作了优化,采用高级的网络策略来应对各种应用.为了使控制器更好地发挥接口语言的性能,该团队提出了Maple[61],如图 6所示.Maple对接口语言作了进一步抽象,允许用户使用自定义抽象策略.为了能够高效地将抽象策略分解成一系列规则,并下发到相应的分布式交换机上,Maple不但采用了高效的多核调度器,最关键的是,它采用了跟踪运行时优化器(tracing runtime optimizer)来优化性能.该优化器一方面通过记录可重用的策略,将负载尽可能地转移到交换机来处理.另一方面,通过动态跟踪抽象策略与数据内容及环境的依赖性,使流表始终处于最新状态,从而确保抽象策略转成可用规则的效率.

Fig. 6 Maple system components图 6 Maple系统组件

康奈尔大学与普林斯顿大学联合研究团队首先提出了Frenetic[62],与Nettle等语言类似,它也具有描述性和FRP特性.两者主要有3点不同:一是抽象层次,由于Frenetic是建立在NOX之上的语言,因此比Nettle抽象层次要高;二是Frenetic有查询语言和实时系统,这是Nettle所不具备的;三是Frenetic基于数据包,而Nettle基于事件流.NetCore[63]增强了Frenetic的能力,包括增加通配符匹配处理模式、主动生成规则和通用的语法结构等.由于Frenetic和NetCore都采用模块并行组装方式,这要求每个模块(即服务,如接入控制等)都各自生成所需包的备份,造成一定的资源浪费.Pyretic[64]则采用了模块顺序组装方式,使得每个应用可以顺序处理,也有效地避免了潜在应用冲突发生的可能.为了增强这类接口语言的理论基础,2014年初,该团队提出利用Kleene代数理论作为检测的NetKAT[65]语言,它改进了NetCore语言特性,可以利用数学理论验证配置的正确性,避免了网络配置潜在的问题.上述各类语言的对比情况见表 4.

Table 4 Comparison of interface languages 表 4 接口语言的对比
3.3 控制层特性研究

控制层存在一致性、可用性和容错性等特性,而所提到的这3种特性的需求无法同时满足[67],达到三者之间的平衡,是今后的重要工作之一.多数情况下,科研人员是在一部分特性影响较小的前提下重点提升另一部分特性.因此,科研人员在对控制层特性研究中各有侧重.下面对控制层的一致性、可用性和容错性分别进行讨论.

1. 一致性

集中控制是SDN区别于其他网络架构的核心优势之一,通过集中控制,用户可以获取全局网络视图,并根据全网信息对网络进行统一设计与部署,理论上保证了网络配置的一致性问题.然而,分布式控制器仍然具有潜在的不一致性问题.由于不同控制器的设计对网络一致性要求有所不同,严格保证分布式状态全局统一的控制器,将无法保证网络性能;反之,如果控制器能够快速响应请求,下发策略,则无法保证全局状态一致性.性能无明显影响的情况下,保证状态一致性成为了SDN设计中的关键问题[49].

并发策略同样会导致一致性问题,可由控制层将策略形成规则,并按两阶段提交方式[40]解决.为了避免数据层过多的参与,控制层可直接通过并发策略组合的方式来解决[68],并可利用细粒度锁(fine-grained locking)确保组合策略无冲突发生.HFT[69]采用了层次策略方案,它将并发策略分解,组织成树的形式,树的每个节点都可独立形成转发规则.HFT首先对每个节点进行自定义冲突处理操作,这样,整个冲突处理过程就转化成利用自定义冲突处理规则逆向搜索树的过程,从而解决了并发策略一致性问题.

2. 可用性

规则备份可以提升网络的可用性.RuleBricks[70]针对规则备份提出一种高可用性方案.在RuleBricks中,不同的规则对应不同颜色的“砖块”,“砖块”的大小由通配符的地址空间大小决定,其中,最上层的“砖块”对应的规则是目前的活跃规则.如果因为网络节点失效导致某种颜色的“砖块”消失,则下面的备份“砖块”会显现出来成为新的活跃规则.通过对“砖块”的设定、选取和操作的优化,RuleBricks可以有效限制流的重分配和规则爆炸的问题.

控制器作为SDN的核心处理节点,需要处理来自交换机的大量请求,而过重的负载会影响SDN的可用性.利用分布式控制器可以平衡负载,提升SDN的整体性能.特别地,对于层次控制器(如Kandoo[52])来说,利用局部控制器承担交换机的多数请求,全局控制器则可以更好地为用户提供服务.然而,分布式控制器架构亦存在可用性问题.由于每个控制器需要处理不同的交换机,网络流量分布不均匀,导致某些控制器可用性降低.针对该问题,ElastiCon[71]采用负载窗口的方式来动态调整各控制器间的流量.ElastiCon周期性地检查负载窗口,当负载窗口的总负荷发生改变时,将动态扩充或压缩控制器池,以适应当前实际需求.如果负载超过控制器池最大值时,则需要另外增加新的控制器,以保证网络的可用性.

减少交换机的请求次数,可以提升控制层的可用性.DIFANE[72]架构旨在解决数据平面转发规则粒度过细和对集中控制依赖的问题.在DIFNAE中,对于SDN传统的流处理都交给了数据层,如交换机不再将每流的第1个数据包传到控制器等.控制器的任务仅是划分规则,并将规则主动下发到数据层面.因此,DIFANE可适应大规模的网络拓扑结构和处理更多的转发规则.DevoFlow[73]则按粒度将数据流分成长短流,并在转发器上建立一些特定规则,使数据层能够直接处理短流,仅有少量的长流才交由控制层处理.根据Zipf定律[74],长流数量远少于短流数量.因此,DevoFlow采用的策略可以最大程度地降低控制器负载,提升控制器的可用性.

3. 容错性

与传统的互联网类似,SDN同样面临着网络节点或链路失效的问题.然而,SDN控制器可以通过全网信息快速恢复失效节点,具有较强的容错能力.网络节点恢复收敛过程如图 7所示:① 当某台交换机失效时,其他交换机察觉出变化;② 交换机将变化情况通知控制器;③ 控制器根据所掌握的信息,计算出需要恢复的规则;④ 将更新发送给数据平面中受到影响的网络元素;⑤ 数据平面中受影响的元素分别更新流表信息.

Fig. 7 Convergence on a node or link failure图 7 失效节点或链路的收敛

从链路恢复过程可以看出:在SDN架构中,失效信息一般不是通过洪泛方式通知全网,而是直接发送给控制层,并由控制器来做恢复决策,因而不易出现路由振荡的现象.如果是交换机和控制器之间的链接失效,导致无法通信,则收敛过程相对困难.可以采用传统网络的IGP(如OSPF协议)通信,并通过洪泛方式恢复,也可以采用故障转移(failover)[50]方式,同样能够缓解链路失效收敛时间问题.通过在交换机上安装用于验证拓扑连接性的静态转发规则,可以更好地实现网络故障的快速收敛[75].

为了避免由于手动配置导致节点失效,控制层提供了一种高级网络容错语言FatTire[76].用户可以通过FatFire语言指定网络当前的容错度,并根据网络状况自主指定流路径.FatTire语言编译器具有网内快速恢复机制,可以将用户错误的网络配置迅速恢复回来,提升了控制层的容错性.

4SDN应用研究

随着SDN的快速发展,SDN已应用到各个网络场景中,从小型的企业网和校园网扩展到数据中心与广域网,从有线网扩展到无线网.无论应用在任何场景中,大多数应用都采用了SDN控制层与数据层分离的方式获取全局视图来管理自己的网络.

4.1 企业网与校园网

在企业网或校园网的部署应用多见于早期的SDN研究中[4,12,77,78],为SDN研究发展提供了可参考的依据.在之后的实际部署中,由于不同企业或校园对SDN的需求存在差异性,无法根据自身的特点进行部署.针对该问题,研究人员完善了SDN的功能,支持对企业网和校园网的个性管理.精灵架构[79]允许企业网根据各自需求自主增加新功能,该架构采用外包的形式进行,并且支持企业网增加终端主机、部署中间件、增加交换机和路由器等.Kim等人[80]进一步研究了利用SDN改善网络管理,更好地支持校园网的部署.网络部署一致性问题同样引起了关注,用户通过SDN管理网络时仍然会出现网络转发拓扑循环和无效配置等问题.OF.CPP[81]则利用ACID(数据库事务正确执行的四要素)思想较好地修复了这些问题,有利于企业网络统一部署.

第二代中国教育和科研计算机网(China Education and Research Network II,简称CERNET2)采用4over6技术将百所院校连接在一起,提供了IPv4应用和IPv6应用接入和互通互访等服务.4over6[82]描述了IPv4网络向IPv6网络过渡的技术,如图 8所示,它借鉴了SDN网络虚拟化的思想,将IPv4网络和IPv6网络从数据层分离出来.由于IPv4和IPv6传输数据的基本原理相同,因此数据层能够对IPv4和IPv6两者都提供传输服务,实现转发抽象.同时,还可分别为IPv4服务提供商和IPv6服务提供商提供更方便的管理机制,便于IPv4网络向IPv6网络的迁移,满足所有IPv6网络过渡的需求.

Fig. 8 4over6 virtualization architecture图 8 4over6虚拟化体系结构
4.2 数据中心与云

除了在企业网与校园网部署之外,数据中心由于设备繁杂且高度集中等特点,相关SDN部署同样面临着严峻的挑战.早期部署在数据中心的实例为基于NOX的SDN网络[83],随后,在数据中心的部署应用得到极大的发展[69, 84, 85, 86, 87, 88].其中,性能和节能是部署过程中重点考虑的两个方面.

数据中心成千上万的机器会需要很高的带宽,如何合理利用带宽、节省资源、提高性能,是数据中心的另一个重要问题.Cui等人[84]通过对每台路由器和服务器进行信息缓存,利用SDN掌握全网缓存信息,能够有效解决数据中心的数据传输冗余问题.在数据中心,每个路由器和服务器都可以进行信息缓存.当两台服务器第1次通信时,所在路径的路由器将信息缓存下来.当服务器再次发起相关通信时,为了获取最近距离的缓存,SDN根据全网信息给出最优缓存任务分配.此时,服务器无需到目的地址去获取信息,从而消除了数据传输冗余. Hedera[85]采用了OpenFlow交换机,通过中央控制器掌握数据中心的全局信息,方便控制器优化带宽,比等价多路径(equal-cost multipath routing,简称ECMP)技术可提升至4倍的带宽能力.DevoFlow[73]考虑避免数据中心交换机对控制器过多的干扰,将大多数流处理放到交换机上处理,从而提高了数据中心传输的整体性能. zUpdate[86]则利用SDN确保在数据中心几乎无任何性能影响的情况下更新设备.

节能一直是数据中心研究中不容忽视的问题.由于数据中心具有大规模互联网服务稳定性和高效性等特性,常以浪费能源为代价.然而通过关闭暂时没有流量的端口,仅能节省少量能耗,最有效的办法是通过SDN掌握全局信息能力,实时关闭暂未使用的设备,当有需要时再打开,将会节省约一半的能耗[87].利用率低同样会导致数据中心能耗较高.在数据中心,每个流在每个时间片通过独占路由的方式,可提高路由链路的利用率[88].利用SDN掌握全网信息,公平调度每个流,使路由链路得到充分利用,进而节省了数据中心的能量.

有了数据中心作保障,用户可以通过云网络方便进行网络管理.不过,基于云环境的网络拓扑是多变的,而通过SDN可以获取全局信息,实现云网络管理[89].IBM[90]针对云网络管理提出了云控制器和网络控制器结合的SDN架构.云控制器用来方便用户配置信息,管理物理资源,设置虚拟机和分配存储空间等.网络控制器则用来将云控制器收集的指令转换成SDN设备可识别的指令.为了能够完成两个控制器之间的交互,IBM提供了一种共享图算法库NetGraph.该库支持多种网络服务,包括广播、路由计算、监控、服务质量及安全隔离等.此外,SDN可以有效改善云性能,保证流量负载均衡[91,92].

4.3 广域网

广域网连接着众多数据中心,这些数据中心之间的高效连接与传输等流量工程问题,是众多大型互联网公司努力的目标[93].为了能够提供可靠的服务,应确保当任意链路或路由出现问题时仍能使网络高效运转.

传统的广域网以牺牲链路利用率为代价,使得广域网的平均利用率仅为30%~40%[94],繁忙时的链路利用率也仅为40%~60%[95].

为了提高利用率,Google公司搭建了基于SDN架构的B4系统[94].该系统利用SDN获取全局信息,并采用ECMP哈希技术来保证流量平衡,实现对每个私人应用的平等对待,确保每位用户的应用不会受到其他用户应用的影响.通过近些年实际的运行测试结果表明:该系统最高可达到几乎100%的资源使用率,长期使用率稳定在平均70%的水平上.此外,由于B4系统采用的是Google公司专用设备,保证提升利用率的效果达到最佳.

与B4系统基本原理类似,微软公司的SWAN系统[95]同样利用SDN体系结构实现数据中心间高效的利用率.它实现的手段是:当通过SDN全网信息观测到某条链路需求较低时,SWAN控制数据层的数据通路迅速切换至该链路来传输数据,从而保持所有链路长时间的高效利用率.SDN技术保障了SWAN能够进行全局观测以及流量工程的合理运用,确保资源利用率长期处于60%以上.相对于B4系统,SWAN系统采用的是传统设备,便于设备的更新与维护,更利于该系统的普及.

4.4 无线网络

SDN技术研究初期就开始部署在无线网络之中,目前已广泛应用在无线网络的各个方面.OpenRoads[96]利用OpenFlow和NOX在校园网搭建了无线SDN平台,该平台分别在WiFi热点和WiMAX基站增加OpenFlow设备,并使用NOX控制器与OpenFlow设备进行无线通信.Odin[97]则利用SDN技术在企业网上搭建无线局域网(wireless local area network,简称WLAN),将企业WLAN服务作为网络应用来处理,确保网络的可管可控特性. SDN同样可以简化设计和管理LTE网络.Li等人[98]采用转发设备上建立代理的方式来缓解控制器负载、降低响应时延等,从而方便用户使用LTE网络.OpenRadio[99]讨论了可编程的无线数据平面问题,它将无线网络分成处理平面(即数据层)和决策平面(即控制层),并设计了可编程的无线接口.通过OpenRadio,运营商仅需编写相应的数据转发规则,降低了对无线网络配置的复杂度.无线接入网(wireless access network,简称RAN)一般采用分布式算法来管理频谱(如2.4G和5G)和切入任务,设备规模比较大时,这样的工作变得十分复杂.SoftRAN[100]可利用SDN的全局信息快速、准确地协调基站RAN所管理的无线接入设备,合理分配频谱资源,降低传输能耗.

5 未来工作

SDN目前已经得到各方面的关注,不仅在学术界对SDN关键技术进行了深入研究,而且在产业界已经开始了大规模应用.SDN技术的出现带来了诸多机遇,同时也面临着更多的挑战.

(1) SDN可扩展性研究

可扩展性决定着SDN的进一步发展[101].OpenFlow协议成为SDN普遍使用的南向接口规范,然而OpenFlow协议并不成熟,版本仍在不断更新中[15].由于OpenFlow对于新应用支持力度不足,需要借助交换机的软硬件技术[32]增强支持能力,为接口抽象技术[44]和支持通用协议的相关技术[16,21,25]带来发展契机.然而,应用的差异性增加了通用北向接口设计的难度,需要考虑灵活性与性能的平衡[61].提供数学理论支持的抽象接口语言[65]成为了一种研究趋势.分布式控制器结构避免了单点失效的问题,提升了单一控制时网络的性能.然而,分布式控制器带来的同步[50,51]和热备份等相关问题还需要进一步加以探索.

(2) SDN规模部署与跨域通信

鉴于SDN的种种优势,大规模部署SDN网络势在必行.实现由传统网络向SDN网络的转换,可以通过增量部署的方式完成[102,103].大规模部署SDN,需要充分考虑网络可靠性、节点失效和流量工程等问题[94,95],以适应未来网络的发展需求.此外,大规模SDN网络还存在跨域通信问题,如果不同域属于不同的经济利益实体,SDN将无法准确获取对方域内的全部网络信息,从而导致SDN域间路由无法达到全局最优.因此,SDN跨域通信[104]将是亟待解决的问题之一.

(3) 传统网络与SDN共存问题研究

随着SDN的持续发展,传统网络将与SDN长期共存.为了使SDN设备与传统网络设备兼容,节约成本,大多数设备生产厂商选择在传统设备中嵌入SDN相关协议,这样造成传统网络设备更加臃肿.采用协议抽象技术[21]可确保各种协议安全、稳定地运行在统一模块中,从而可减轻设备负担,成为兼容性研究进展的趋势之一.

中间件(MiddleBox)在传统网络中扮演着重要角色,例如网络地址转换(network address translation,简称NAT)可以缓解IPv4地址危机问题、防火墙可以保证安全问题等.然而中间件种类繁多,且许多设备都被中间件屏蔽,无法灵活配置,造成SDN与传统网络无法兼容.建立标签机制,统一管理中间件,将逻辑中间件路由策略自动转换成所需的转发规则,以实现对存在中间件网络的高效管理[105, 106, 107, 108].

(4) SDN在数据中心的应用研究

SDN具有集中式控制、全网信息获取和网络功能虚拟化等特性,利用这些特性,可以解决数据中心出现的各种问题.例如在数据中心网络中,可以利用SDN通过全局网络信息消除数据传输冗余[84],也可利用SDN网络功能虚拟化特性达到数据流可靠性与灵活性的平衡[109].可以预见,SDN在数据中心提升性能和绿色节能[88]等方面仍然扮演着十分重要的角色.

(5) 借鉴SDN思想融合IPv6过渡机制

传统互联网面临着IPv4地址耗尽的问题,解决这个问题最有效的办法是全网使用IPv6地址.然而IPv4互联网规模大、服务质量高,短时间内难以实现全网IPv6.为了实现平滑过渡,IPv6过渡技术成为当前互联网的热点[110].现存的IPv6过渡机制种类繁多,适用场景局限.利用SDN掌握全局信息的能力来融合各种过渡机制,可充分提升过渡系统的灵活性,最终实现IPv6网络的快速平稳过渡[111,112].因此,SDN将成为IPv6过渡技术中可借鉴的指导思想之一.

(6) SDN与其他新型网络架构融合

SDN与其他新型网络架构融合,可以使两种架构形成互补,推动未来网络的进一步发展.例如,主动网络[8,9]具有可编程性,虽然并未得到实际应用,但是该结构允许执行环境(即控制层)直接执行代码,具有很强的灵活性.借鉴主动网络可执行代码的思想,SDN可编程的灵活性将得到进一步增强.信息中心网络(information-centric networking,简称ICN)[113]是另一个未来的互联网发展方向,它采用了信息驱动的方式.ICN中同样存在数据转发与控制信息耦合的问题.在ICN中利用SDN技术分离控制信息,融合两种技术优势,将成为未来的网络值得探讨的问题[114,115].

(7) SDN网络安全

传统的网络设备是封闭的,然而开放式接口的引入会产生新一轮的网络攻击形式,造成SDN的脆弱性.由控制器向交换机发送蠕虫病毒[116]、通过交换机向控制器进行DDos攻击[117]、非法用户恶意占用整个SDN网络带宽[118]等,都会导致SDN全方位瘫痪.安全的认证机制[119]和框架[120]、安全策略的制定(如OpenFlow协议的传输层安全TLS[30])等,将成为SDN安全发展的重要保证.

此外,SDN的研究促进了业界的变革.SDN网络虚拟化技术缩短了网络配置周期,显著提升了新协议和新设备的部署效率.SDN开放式的研究降低了生产成本,扩充了生产规模,为中小型设备商带来了拓展市场和扩大生存空间的机遇.SDN技术变革使得各运营商和设备商的利益被再一次划分,将造就又一批业界巨头的产生.SDN对传统网络设备市场占有率的冲击同样不容小觑,不具备SDN功能的传统路由器和交换机,其市场份额将被全面压缩,芯片厂商因此推出了具有SDN功能的芯片,在利益划分竞争中抢得先机.良好的SDN操作界面及易用的编程语言,加快了软件公司市场份额的竞争脚步.SDN还为网络公司各种应用业务提供了新的解决方案,使他们获得了拓展市场的良机.

6 结束语

SDN是当前网络领域最热门和最具发展前途的技术之一.作为新兴的技术,之所以能够得到长足发展,在于它具有传统网络无法比拟的优势:首先,数据控制解耦合使应用升级与设备更新换代相互独立,加快了新应用的快速部署;其次,网络抽象简化了网络模型,将运营商从繁杂的网络管理中解放出来,能够更加灵活地控制网络;最后,控制的逻辑中心化使用户和运营商等可以通过控制器获取全局网络信息,从而优化网络,提升网络性能.鉴于SDN巨大的发展潜力,学术界深入研究了数据层及控制层的关键技术,并将SDN成功地应用到企业网和数据中心等各个领域.然而,SDN要想成为下一代互联网主流技术还需要克服许多困难,包括SDN可扩展性、规则部署与跨域通信等关键性难题.因此,发挥SDN所具备的优势,尽量避免存在的风险,成为SDN未来发展的重要任务.只有这样,才能真正成为引领网络未来的互联网技术.

参考文献
[1] Cisco. Cisco Visual Networking Index: Forecast and Methodology, 2013-2018. 2013.
[2] Stanford University. Clean slate program. 2006. http://cleanslate.stanford.edu/
[3] McKeown N. Software-Defined metworking. In: Proc. of the INFOCOM Key Note. 2009. http://infocom2009.ieee-infocom.org/ technicalProgram.htm
[4] McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J. OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM CCR, 2008,38(2):69-74.
[5] MIT Technology Review. 10 breakthrough technologies, TR10: Software-defined networking. 2009. http://www2.technology review.com/article/412194/tr10-software-defined-networking/
[6] Jain R. Internet 3.0: Ten problems with current Internet architecture and solutions for the next generation. In: Proc. of the IEEE MILCOM. 2006. 1-9 .
[7] Nunes BAA, Mendonca M, Nguyen XN, Obraczka K, Turletti T. A survey of software-defined networking: Past, present, and future of programmable networks. IEEE Communications Surveys and Tutorials, 2014,16(3):1617-1634 .
[8] Tennenhouse DL, Wetherall DJ. Towards an active network architecture. In: Proc. of the IEEE DARPA Active Networks Conf. and Exposition. 2002. 2-15.
[9] Tennenhouse DL, Smith JM, Sincoskie WD, Wetherall D, Minden GJ. A survey of active network research. IEEE Communications Magazine, 1997,35(1):80-86 .
[10] Greenberg A, Hjalmtysson G, Maltz DA, Myers A, Rexford J, Xie G, Yan H, Zhan JB, Zhang H. A clean slate 4D approach to network control and management. ACM SIGCOMM CCR, 2005,35(5):41-54 .
[11] Yan H, Maltz DA, Ng TSE, Gogineni H, Zhang H, Cai Z. Tesseract: A 4D network control plane. In: Proc. of the USENIX NSDI. 2007. 369-382. https://www.usenix.org/legacy/event/nsdi07/tech/full_papers/yan/yan_html/
[12] Gude N, Koponen T, Pettit J, Pfaff B, Casado M, McKeown N, Shenker S. NOX: Towards an operating system for networks. ACM SIGCOMM CCR, 2008,38(3):105-110 .
[13] Shenker S. The future of networking, and the past of protocols. In: Proc. of the Open Networking Summit. 2011. http://www.opennetsummit.org/archives/apr12/site/talks/shenker-tue.pdf
[14] Open networking foundation. 2014. https://www.opennetworking.org/
[15] Doria A, Salim JH, Haas R, Khosravi H, Wang W, Dong L, Gopal R, Halpern J. Forwarding and control element separation (ForCES) protocol specification. IETF RFC 5810, 2010.
[16] Software-Defined networking research group (SDNRG). 2013. http://irtf.org/sdnrg
[17] Software-Defined networking (SDN). 2012. http://www.itu.int/en/ITU-T/sdn/Pages/default.aspx
[18] ONS. SDN: Transforming networking to accelerate business agility. 2013. http://www.opennetsummit.org/archives/mar14/site/why-sdn.html
[19] Open Networking Foundation. Software-Defined networking: The new norm for networks. ONF White Paper, 2012.
[20] ETSI. Network functions virtualisation. NFV White Paper, 2012.
[21] OpenDayLight. 2014. http://www.opendaylight.org/
[22] Open Networking Foundation. SDN architecture overview, version 1.0. 2013.
[23] Enns R, Bjorklund M, Schoenwaelder J, Bierman A. Network configuration protocol (NETCONF). IETF RFC 6241, 2011.
[24] Rekhter Y, Li T, Hares S. A border gateway protocol 4 (BGP-4). IETF RFC 4271, 2006.
[25] Cisco. Cisco’s one platform kit (onePK). 2014. http://www.cisco.com/en/US/prod/iosswrel/onepk.html
[26] Schmid S, Suomela J. Exploiting locality in distributed SDN control. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 121-126 .
[27] Lara A, Kolasani A, Ramamurthy B. Network innovation using openflow: A survey. IEEE Communications Surveys and Tutorials, 2013,16(1):493-512 .
[28] Suzuki K, Sonoda K, Tomizawa N, Yakuwa Y, Uchida T, Higuchi Y, Tonouchi T, Shiimonishi H. A survey on OpenFlow technologies. IEICE Trans. on Communications, 2014,97(2):375-386.
[29] Zuo QY, Chen M, Zhao GS, Xing CY, Zhang GM, Jiang PC. Research on OpenFlow-based SDN technologies. Ruan Jian Xue Bao/Journal of Software, 2013,24(5):1078-1097 (in Chinese with English abstract).http://www.jos.org.cn/1000-9825/4390.htm
[30] Open Networking Foundation. OpenFlow switch specification, version 1.4.0 (wire protocol 0x05). 2013.
[31] Open Networking Foundation. OF-CONFIG 1.2, OpenFlow management and configuration protocol. 2014.
[32] Bosshart P, Gibb G, Kim HS, Varghese G, McKeown N, Izzard M, Mujica F, Horowitz M. Forwarding metamorphosis: Fast programmable match-action processing in hardware for SDN. In: Proc. of the ACM SIGCOMM. 2013. 99-110 .
[33] Pan H, Guan HT, Liu JJ, Ding WF, Lin CY, Xie GG. The FlowAdapter: Enable flexible multi-table processing on legacy hardware. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 85-90. http://dl.acm.org/citation.cfm?id=2491209
[34] Cohen R, Lewin-Eytan L, Naor J, Raz D. On the effect of forwarding table size on SDN network utilization. In: Proc. of the IEEE INFOCOM. 2014.1734-1742 .
[35] Lu GH, Miao R, Xiong YQ, Guo CX. Using CPU as a traffic co-processing unit in commodity switches. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 31-36 .
[36] Dobrescu M, Egi N, Argyraki K, Chun BG, Fall K, Iannaccone G, Knies A, Manesh M, Ratnasamy S. RouteBricks: Exploiting parallelism to scale software routers. In: Proc. of the ACM SOSP. 2009. 15-28 .
[37] Pongrácz G, Molnár L, Kis ZL, Turáyi Z. Cheap silicon: Myth or reality? Picking the right data plane hardware for software defined networking. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 103-108. http://dl.acm.org/citation.cfm?id= 2491204
[38] Mogul JC, Congdon P. Hey, you darned counters!: Get off my ASIC!. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 25-30.http://dl.acm.org/citation.cfm?id=2342447
[39] Canini M, Venzano D, Peresini P, Kostić D, Rexford J. A NICE way to test OpenFlow applications. In: Proc. of the USENIX NSDI. 2012. https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final105.pdf
[40] Reitblatt M, Foster N, Rexford J, Schlesinger C, Walker D. Abstractions for network update. In: Proc. of the ACM SIGCOMM. 2012. 323-334 .
[41] Katta NP, Rexford J, Walker D. Incremental consistent updates. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013.49-54.
[42] McGeer R. A safe, efficient update protocol for openflow networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 61-66.
[43] Ghorbani S, Caesar M. Walk the line: Consistent network updates with bandwidth guarantees. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 67-72. http://dl.acm.org/citation.cfm?id=2342455
[44] Song H. Protocol-Oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 127-132. http://dl.acm.org/citation.cfm?id=2491190
[45] Tootoonchian A, Gorbunov S, Ganjali Y, Casado M, Sherwood R. On controller performance in software-defined networks. In: Proc. of the USENIX Hot-ICE. 2012. https://www.usenix.org/system/files/conference/hot-ice12/hotice12-final33_0.pdf
[46] Vanbever L, Reich J, Benson T, Foster N, Rexford J. HotSwap: Correct and efficient controller upgrades for software-defined networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 133-137. http://dl.acm.org/citation.cfm?id=2491194
[47] Cai Z, Cox AL, Ng TSE. Maestro: A system for scalable OpenFlow control. Technical Report, TR10-08, Rice University, 2010.
[48] Heller B, Sherwood R, McKeown N. The controller placement problem. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. ACM Press, 2012. 7-12.
[49] Levin D, Wundsam A, Heller B. Logically centralized? State distribution trade-offs in software defined networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 1-6 .
[50] Koponen T, Casado M, Gude N, Stribing J, Poutievski L, Zhu M, Ramanathan R, Iwata Y, Inoue H, Hama T, Shenker S. Onix: A distributed control platform for large-scale production networks. In: Proc. of the USENIX OSDI. 2010. http://static.usenix.org/events/osdi10/tech/full_papers/Koponen.pdf
[51] Tootoonchian A, Ganjali Y. HyperFlow: A distributed control plane for OpenFlow. In: Proc. of the USENIX INM Workshop on WREN. 2010. https://www.usenix.org/legacy/event/inmwren10/tech/full_papers/Tootoonchian.pdf
[52] Yeganeh SH, Ganjali Y. Kandoo: A framework for efficient and scalable offloading of control applications. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 19-24 .
[53] Erickson D. The beacon openflow controller. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 13-18. http://dl.acm.org/citation.cfm?id=2491189
[54] Monaco M, Michel O, Keller E. Applying operating system principles to SDN controller design. In: Proc. of the ACM Workshop on HotNets. 2013. 1-7 .
[55] Floodlight. 2014. http://www.projectfloodlight.org/floodlight/
[56] POX. 2014. http://www.noxrepo.org/pox/about-pox/
[57] Ryu. 2014. http://osrg.github.io/ryu/
[58] Voellmy A, Hudak P. Nettle: Taking the sting out of programming network routers. Springer PADL, 2011,6539:235-249 .
[59] Voellmy A, Wang J. Scalable software defined network controllers. In: Proc. of the ACM SIGCOMM Demonstration. 2012. 289-290 .
[60] Voellmy A, Kim H, Feamster N. Procera: A language for high-level reactive network control. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 43-48. http://dl.acm.org/citation.cfm?id=2342451
[61] Voellmy A, Wang J, Yang YR, Ford B, Hudak P. Maple: Simplifying SDN programming using algorithmic policies. In: Proc. of the ACM SIGCOMM. 2013. 87-98. http://dl.acm.org/citation.cfm?id=2486030
[62] Foster N, Harrison R, Freedman MJ, Monsanto C, Rexford J, Story A, Walker D. Frenetic: A network programming language. In: Proc. of the ACM SIGPLAN Symp. on ICFP. 2011. 279-291. http://dl.acm.org/citation.cfm?id=2034812
[63] Monsanto C, Foster N, Harrison R, Walker D. A compiler and run-time system for network programming languages. In: Proc. of the ACM SIGPLAN-SIGACT Symp. on POPL. 2012. 217-230 .
[64] Monsanto C, Reich J, Foster N, Rexford J, Walker D. Composing software-defined networks. In: Proc. of the USENIX NSDI. 2013. 1-13.https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final232.pdf
[65] Anderson CJ, Foster N, Guha A, Jeannin JB, Kozen D, Schlesinger C, Walker D. NetKAT: Semantic foundations for networks. In: Proc. of the ACM SIGPLAN-SIGACT Symp. on POPL. 2014. 113-126 .
[66] Hinrichs TL, Gude NS, Casado M, Mitchell JC, Shenker S. Practical declarative network management. In: Proc. of the ACM SIGCOMM Workshop on WREN. 2009. 1-10 .
[67] Panda A, Scott C, Ghodsi A, Koponen T, Shenker S. CAP for networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 91-96.
[68] Canini M, Kuznetsov P, Levin D, Schmid S. Software transactional networking: Concurrent and consistent policy composition. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 1-6 .
[69] Ferguson AD, Guha A, Liang C, Fonseca R, Krishnamurithi S. Hierarchical policies for software defined networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 37-42. http://dl.acm.org/citation.cfm?id=2342450
[70] Williams D, Jamjoom H. Cementing high availability in OpenFlow with RuleBricks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 139-144 .
[71] Dixit A, Hao F, Mukherjee S, Lakshman TV, Kompella R. Towards an elastic distributed sdn controller. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 7-12 .
[72] Yu M, Rexford J, Freedman MJ, Wang J. Scalable flow-based networking with DIFANE. In: Proc. of the ACM SIGCOMM. 2010. 351-362 .
[73] Curtis AR, Mogul JC, Tourrilhes J, Yalagandula P, Sharma P, Banerjee S. DevoFlow: Scaling flow management for high- performance networks. In: Proc. of the ACM SIGCOMM. 2011. 254-265 .
[74] Sarrar N, Uhlig S, Feldmann A, Sherwood R, Huang X. Leveraging Zipf’s law for traffic offloading. ACM SIGCOMM CCR, 2012,42(1):16-22.
[75] Kozat UC, Liang G, Kökten K. On diagnosis of forwarding plane via static forwarding rules in software defined networks. In: Proc. of the IEEE INFOCOM. 2014. 1716-1724 .
[76] Reitblatt M, Canini M, Guha A, Foster N. FatTire: Declarative fault tolerance for software-defined networks . In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 109-114 .
[77] Casado M, Freedman MJ, Pettit J, Luo JY, McKeown N, Shenker S. Ethane: Taking control of the enterprise. In: Proc. of the ACM SIGCOMM. 2007. 1-12 .
[78] Nayak A, Reimers A, Feamster N, Clark R. Resonance: Dynamic access control for enterprise networks. In: Proc. of the ACM SIGCOMM Workshop on WREN. 2009. 11-18 .
[79] Gibb G, Zeng H, McKeown N. Outsourcing network functionality. In: Proc. of the ACM SIGCOMM HotSDN. 2012. 73-78 .
[80] Kim H, Feamster N. Improving network management with software defined networking. IEEE Communications Magazine, 2013, 51(2):114-119 .
[81] Perešíni P, Kuźniar M, Vasić N, Canini M, Kostić D. OF.CPP: Consistent packet processing for OpenFlow. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 97-102 .
[82] Cui Y, Wu P, Xu MW, Wu JP, Lee YL, Durand A, Metz C. 4over6: Network layer virtualization for IPv4-IPv6 coexistence. IEEE Network, 2012,26(5):44-48 .
[83] Tavakoli A, Casado M, Koponen T, Shenker S. Applying NOX to the datacenter. In: Proc. of the ACM SIGCOMM Workshop on HotNets. 2009. http://www.cs.duke.edu/courses/current/compsci590.4/838-CloudPapers/hotnets2009-final103.pdf
[84] Cui Y, Xiao SH, Liao CP, Stojmenovic I, Li MM. Data centers as software defined networks: Traffic redundancy elimination with wireless cards at routers. IEEE JSAC, 2013,31(12):2658-2672 .
[85] Al-Fares M, Radhakrishnan S, Raghavan B, Huang N, Vahdat A. Hedera: Dynamic flow scheduling for data center networks. In: Proc. of the USENIX NSDI. 2010. https://www.usenix.org/legacy/event/nsdi10/tech/full_papers/al-fares.pdf
[86] Liu HH, Wu X, Zhang M, Yuan LH, Wattenhofer R, Maltz DA. zUpdate: Updating data center networks with zero loss. In: Proc. of the ACM SIGCOMM. 2013. 411-422 .
[87] Heller B, Seetharaman S, Mahadevan P, Yiakoumis Y, Sharma P, Banerjee S, McKeown N. ElasticTree: Saving energy in data center networks. In: Proc. of the USENIX NSDI. 2010. https://www.usenix.org/event/nsdi10/tech/full_papers/heller.pdf
[88] Li D, Shang Y, Chen C. Software defined green data center network with exclusive routing. In: Proc. of the IEEE INFOCOM. 2014. 1743-1751 .
[89] Banikazemi M, Olshefski D, Shaikh A, Tracey J, Wang GH. Meridian: An SDN platform for cloud network services. IEEE Communications Magazine, 2013,51(2):120-127 .
[90] Raghavendra R, Lobo J, Lee KW. Dynamic graph query primitives for sdn-based cloudnetwork management. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 97-102 .
[91] Wang Y, Zhang YP, Singh V, Lumezanu C, Jiang GF. NetFuse: Short-Circuiting traffic surges in the cloud. In: Proc. of the IEEE ICC. 2013.3514-3518 .
[92] Patel P, Bansal D, Yuan LH, Murthy A, Greenberg A, Maltz DA, Kern R, Kumar H, Zikos M, Wu HY, Kim C, Karri N. Ananta: Cloud scale load balancing. In: Proc. of the ACM SIGCOMM. 2013. 207-218. http://dl.acm.org/citation.cfm?id=2486026
[93] Google. Inter-Datacenter WAN with centralized TE using SDN and OpenFlow. ONS, 2012.
[94] Jain S, Kumar A, Mandal S, Ong J, Poutievski L, Singh A, Venkata S, Wanderer J, Zhou J, Zhou M, Zolia J, Hölzle U, Stuart S, Vahdat A. B4: Experience with a globally-deployed software defined WAN. In: Proc. of the ACM SIGCOMM. 2013. 3-14 .
[95] Hong CY, Kandula S, Mahajan R, Zhang M, Gill V, Nanduri M, Wattenhofer R. Achieving high utilization with software-driven WAN. In: Proc. of the ACM SIGCOMM. 2013. 15-26 .
[96] Yap KK, Sherwood R, Kobayashi M, Huang TY, Chan M, Handigol N, McKeown N, Parulkar G. Blueprint for introducing innovation into wireless mobile networks. In: Proc. of the ACM SIGCOMM Workshop on VISA. 2010. 25-32.
[97] Suresh L, Schulz-Zander J, Merz R, Feldmann A, Vazao T. Towards programmable enterprise WLANs with Odin. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 115-120. http://dl.acm.org/citation.cfm?id=2342465
[98] Li LE, Mao ZM, Rexford J. Toward software-defined cellular networks. In: Proc. of the IEEE EWSDN. 2012. 7-12 .
[99] Bansal M, Mehlman J, Katti S, Levis P. Openradio: A programmable wireless dataplane. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 109-114 .
[100] Gudipati A, Perry D, Li LE, Katti S. SoftRAN: Software defined radio access network. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 25-30 .
[101] Yeganeh SH, Tootoonchian A, Ganjali Y. On scalability of software-defined networking. IEEE Communications Magazine, 2013, 51(2):136-141 .
[102] Levin D, Canini M, Schmid S, Feldmann A. Incremental SDN deployment in enterprise networks. In: Proc. of the ACM SIGCOMM Demonstration. 2013. 473-474 .
[103] Lin P, Hart J, Krishnaswamy U, Murakami T, Kobayashi M, Al-Shabibi A, Wang KC, Bi J. Seamless interworking of SDN and IP. In: Proc. of the ACM SIGCOMM Demonstration. 2013. 475-476. http://dl.acm.org/citation.cfm?id=2491703
[104] Bennesby R, Fonseca P, Mota E, Passito A. An inter-AS routing component for software-defined networks. In: Proc. of the IEEE NOMS. 2012. 138-145 .
[105] Martins J, Ahmed M, Raiciu C, Huicj F. Enabling fast, dynamic network processing with ClickOS. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 67-72 .
[106] Sekar V, Egi N, Ratnasamy S, Reiter MK, Shi GY. Design and implementation of a consolidated middlebox architecture. In: Proc. of the USENIX NSDI. 2012. https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final96.pdf
[107] Qazi ZA, Tu CC, Chiang L, Miao R, Sekar V, Yu M. SIMPLE-Fying middlebox policy enforcement using SDN. In: Proc. of the ACM SIGCOMM. 2013. 27-38. http://dl.acm.org/citation.cfm?id=2486022
[108] Fayazbakhsh SK, Sekar V, Yu M, Mogul JC. FlowTags: Enforcing network-wide policies in the presence of dynamic middlebox actions. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 19-24. http://dl.acm.org/citation.cfm?id=2491203
[109] Crisan D, Birke R, Cressier G, Minkenberg C, Gusat M. Got loss? Get zOVN!. In: Proc. of the ACM SIGCOMM. 2013. 423-434 .
[110] Wu P, Cui Y, Wu JP, Liu JC, Metz C. Transition from IPv4 to IPv6: A state-of-the-art survey. IEEE Communications Surveys and Tutorial, 2013,15(3):1407-1424 .
[111] Xia W, Tsou T, Lopez DR, Sun Q, Lu F, Xie HY. A software defined approach to unified IPv6 transition. In: Proc. of the ACM SIGCOMM Poster. 2013. 547-548 .
[112] Cui Y, Chen Y. Unified IPv6 transition framework with flow-based forwarding. IETF draft, 2014.
[113] Jacobson V, Smetters DK, Thornton JD, Palss MF, Briggs NH, Braynard RL. Networking named content. In: Proc. of the ACM CoNEXT. 2009. 1-12. http://dl.acm.org/citation.cfm?id=1658941
[114] Syrivelis D, Parisis G, Trossen D, Flegkas P, Sourlas V, Korakis T, Tassiulas L. Pursuing a software defined information-centric network. In: Proc. of the IEEE EWSDN. 2012. 103-108 .
[115] Veltri L, Morabito G, Salsano S, Blefari-Melazzi N, Detti A. Supporting information-centric functionality in software defined networks. In: Proc. of the IEEE ICC. 2012. 6645-6650 .
[116] Kreutz D, Ramos F, Verissimo P. Towards secure and dependable software-defined networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2013. 55-60 .
[117] Shin S, Yegneswaran V, Porras P, Gu GF. AVANT-GUARD: Scalable and vigilant switch flow management in software-defined networks. In: Proc. of the ACM SIGSAC Conf. on CCS. 2013. 413-424. http://dl.acm.org/citation.cfm?id=2516684
[118] Ferguson AD, Guha A, Liang C, Fonseca R, Krishnamurthi S. Participatory networking: An API for application control of SDNs. In: Proc. of the ACM SIGCOMM. 2013. 327-338 .
[119] Porras P, Shin S, Yegneswaran V, Fong M, Tyson M, Gu GF. A security enforcement kernel for OpenFlow networks. In: Proc. of the ACM SIGCOMM Workshop on HotSDN. 2012. 121-126 .
[120] Shin S, Porras P, Yegneswaran V, Fong M, Gu GF, Tyson M. Fresco: Modular composable security services for software-defined networks. In: Proc. of the ISOC NDSS. 2013. http://www.csl.sri.com/users/vinod/papers/fresco.pdf
[29] 左青云,陈鸣,赵广松,邢长友,张国敏,蒋培成.基于OpenFlow的SDN技术研究.软件学报,2013,24(5):1078-1097. http://www.jos. org.cn/1000-9825/4390.htm