MathJax.Hub.Config({tex2jax: {inlineMath: [['$','$'], ['\\(','\\)']]}}); function MyAutoRun() {    var topp=$(window).height()/2; if($(window).height()>450){ jQuery(".outline_switch_td").css({ position : "fixed", top:topp+"px" }); }  }    window.onload=MyAutoRun; $(window).resize(function(){ var bodyw=$win.width(); var _leftPaneInner_width = jQuery(".rich_html_content #leftPaneInner").width(); var _main_article_body = jQuery(".rich_html_content #main_article_body").width(); var rightw=bodyw-_leftPaneInner_width-_main_article_body-25;   var topp=$(window).height()/2; if(rightw<0||$(window).height()<455){ $("#nav-article-page").hide(); $(".outline_switch_td").hide(); }else{ $("#nav-article-page").show(); $(".outline_switch_td").show(); var topp=$(window).height()/2; jQuery(".outline_switch_td").css({ position : "fixed", top:topp+"px" }); } }); 基于软件定义网络的流量工程
  软件学报  2016, Vol. 27 Issue (2): 394-417   PDF    
基于软件定义网络的流量工程
周桐庆 , 蔡志平, 夏竟, 徐明    
国防科学技术大学 计算机学院, 湖南 长沙 410073
摘要: 作为一种新型网络架构,软件定义网络(software defined network,简称SDN)将网络的数据层和控制层分离,通过集中化控制和提供开放控制接口,简化网络管理,支持网络服务的动态应用程序控制.流量工程通过对网络流量的分析、预测和管理,实现网络性能的优化.在SDN中开展流量工程,可以为网络测量和管理提供实时集中的网络视图,灵活、抽象的控制方式以及高效、可扩展的维护策略,具有突出的研究意义.对基于SDN的流量工程相关工作进行综述.分别从测量的方法、应用和部署角度出发,对SDN中流量测量的基本框架、基于测量的正确态检测以及测量资源的管理进行概述.分析传统网络流量调度方案的问题,介绍SDN中数据流量和控制流量调度的主要方法.从数据层和控制层两个方面概述SDN中故障恢复方法.最后,总结并展望未来工作.
关键词: 软件定义网络    流量工程    流量测量    流量调度    网络故障恢复    
Traffic Engineering for Software Defined Networks
ZHOU Tong-Qing , CAI Zhi-Ping, XIA Jing, XU Ming    
School of Computer, National University of Defense Technology, Changsha 410073, China
Abstract: Software defined network (SDN) is an emerging network paradigm that proposes to decouple the control and data forwarding plane. Leveraging the centralized control ability and open programming interfaces SDN provides, network management can be dramatically simplified, and network services can be dynamically controlled by applications. Traffic engineering (TE) is a category of mechanisms that promises to optimize network performance through analyzing, predicting and regulating data flow in network. The unique features of SDN provide TE with unified and real-time global network view, flexible control manner and better policy for scalable traffic management, exhibiting profound research significance. This paper surveys the state-of-art works on TE for SDN. In terms of the methods, application and deployment of measurement, works on traffic measurement architecture, network invariant detection and measurement resource management with SDN are reviewed. The problems in traditional network traffic management are analyzed, and SDN-based data traffic management methods for efficient load balance and control traffic management methods for centralized bottleneck relief are presented. Moreover, network failure resilience technologies in SDN are described. Finally, the technological approaches are summarized and future research issues are discussed.
Key words: software defined network    traffic engineering    traffic measurement    traffic management    network failure recovery    

近年来,随着互联网规模的不断扩大,接入网络的设备数目和种类不断增多,传统网络在管理难度、可扩展性以及实验研究等方面的局限逐渐凸显出来[1],具体体现在:研究者很难在大规模网络环境中进行实验研究的验证;网管人员无法有效地根据自身的应用需求进行网络的配置和优化;设备厂商不能快速地进行研发和部署,以满足客户需求[2].

作为一种新型的网络架构,SDN(software defined network)基于网络抽象的思想,将网络中的控制层和数据层分离开来,提供对分布式网络的集中管理和动态维护能力,从而有效解决传统IP网络在维护、扩展和实验创新上的弊端.如图1所示,SDN网络主要包含应用、控制和数据这3个层面:控制层将网络各节点的控制功能从逻辑上集中;应用层利用控制层提供的可编程接口实现各种网络应用;数据层负责进行数据流的转发. OpenFlow[3]是控制层和转发层之间通信的标准接口,状态、数据以及控制信息通过这一接口实时地传递.

Fig.1 SDN architecture 图1 SDN结构

图1所示,流量工程是SDN网络中的一类典型应用.流量工程是网络管理者优化网络性能和流量传输的一系列重要方法,主要内容包括对网络中的数据流进行动态的分析、预测和管理,其相应技术广泛地应用在公共电话交换网、局域网、广域网和互联网中.在网络快速发展和网络应用不断出现的新形势下,基于传统网络技术的流量工程具有局限性,具体可从服务的使用者和提供者两个角度加以概括:

1) 服务质量与可扩展性方面:网络应尽可能地满足不同应用的传输需求,而且能够针对各个应用对延迟等性能指标的不同要求提供不同优先级的服务.例如,不断增多的多媒体应用对于端到端延迟、抖动以及丢包率等服务质量参数都提出更高的要求[4].

2) 网络资源利用率和容错方面:云计算的发展使得大规模数据中心的需求愈发明显,网络管理过程中应更有效地利用网络资源,以降低成本并提高系统的总体性能[4].与此同时,网络设备的不断增多使得网络中出现故障的概率不断变大,需要流量工程为网络提供足够的容错和快速恢复能力.

SDN为集中和高效的网络管理提供新的思路和途径,为流量工程的开展提供全局的网络视野、实时的状态信息和清晰的网络流模式,易于实现及时、准确的测量和动态灵活的调度.另一方面,传统网络的流量工程技术能否与SDN有效地兼容尚不明确[5],因此,开展基于SDN的流量工程研究是极有理论意义和应用价值的.

本文针对现阶段SDN中流量工程相关工作进行介绍和分析.第1节首先介绍基于SDN的流量工程的概念和内容,并分析存在的挑战.在此基础上,分别利用第2节~第4节对流量工程中的流量测量、流量管理和故障恢复这3个方面的工作进行详细阐述.最后,第5节对全文进行总结,并对未来工作提出展望.

1 SDN 中流量工程概述 1.1 流量工程定义

流量工程,或称流量管理,指的是针对网络性能进行优化的一系列方法,即针对网络中数据流的行为进行动态的分析预测和有目的的管理.图2给出一个使用流量工程进行路由优化的例子,两个用户流由节点A流向节点C,在图2(a)中,使用最短路径路由(OSPF),导致链路AC拥塞;在图2(b)中,利用链路ABBC分摊AC间的流量,减轻或消除链路AC的拥塞状况.可见,流量工程可以有效地改善网络性能.

Fig.2 A example of using traffic engineering for routing optimization 图2 使用流量工程进行路由优化的一个例子

针对不同的网络类型,流量工程技术不断发展以满足不同的需求.在20世纪80年代的ATM网络中,流量工程技术主要用来解决拥塞控制问题[6];90年代末,IP网络迅猛发展,流量工程被用来在IP网络中进行路由优化以均衡路径上的流量,并为应用提供服务保证[7];针对IP网络中优化路由的限制,研究者进一步提出通过标签而非IP头部进行转发决策的多协议标签交换技术(MPLS)[8],实现更有效的流量管理.但是,MPLS控制层的实现和管理过于复杂,SDN的提出则恰好有效地解决了这一问题.

SDN的出现引起了学术界和产业界的广泛重视.例如,Google期望通过使用SDN将网络资源的利用率提升20~30%,同时降低网络的延迟和丢包[2].相对于传统方式,SDN为流量工程的开展提供了更好的基础:首先,提供集中的全局视图,控制器能够实时得到全局的网络状态、拓扑信息和应用需求信息;其次,提供可编程的数据层接口,操作者可以根据当前状态对网络资源进行动态重分配;此外,多个设备厂商的交换机使用统一的编程接口,可以提供充分的开放性[9, 10].总结起来,基于SDN开展流量工程的优势可概括如下:

1) 在流量的测量方面,可以灵活地部署可扩展的全局测量任务,实时地收集网络状态信息,对流量进行准确的集中式监控和统计分析.

2) 在流量的管理方面,可以综合考虑网络状态和网络应用需求,以流为单位进行动态、灵活、细粒度的流量调度,实现网络中流量的负载均衡.

3) 在网络的资源利用和维护方面,支持对包括带宽、存储等资源的动态分配,实现有效而合理的资源利用.基于集中的网络状态反馈,可以透明地进行故障的应对和处理.

1.2 基于SDN的流量工程研究内容

流量工程相关工作可以从不同的角度进行划分[4].在研究基于SDN的流量工程时,本文按照功能将其分为流量测量、流量管理和故障恢复3个部分,如图3所示.

Fig.3 Main research contents of traffic engineering in SDN 图3 SDN网络中流量工程的主要内容

1) 流量测量

流量测量是对一个特定网络中流量的规模、特征进行测量的过程,是有效实现网络管理的基础.一般说来,网络管理的预算至少占整个信息技术行业预算的80%,而流量测量承担的任务至少占网络管理工作的一半(另一部分是控制),这是因为明确发生什么要比决定如何处理更为关键和困难.现有的许多SDN框架使用传统的IP架构的流量测量方案,部署复杂,硬件资源开销较大,而在控制器上实现复杂的监控和分析逻辑会引入额外的处理延迟.所以,基于SDN的流量测量方法应该综合考虑复杂性、开销和准确性这3个方面的因素.测量的目的在于获取流量特征,捕获网络的异常.如何利用流量测量进行有效的网络正确态检测,也是该方向的重要内容.最后,流量测量过程中的硬件资源调度问题也是文中关注的一个研究点.

2) 流量调度

流量调度通过对网络中流量的控制和管理实现负载均衡,获得在延迟、吞吐率和带宽利用率等性能指标上更好的表现.利用SDN集中的网络视图和动态的规则配置能力,可以对网络流量进行灵活的调度.所以,如何结合流量特征、网络状态和应用需求进行流量的路由转发,实现网络负载的有效均衡,是基于SDN的数据流调度研究工作中的重点.另一方面,SDN网络中流的默认管理操作为[11]:首先,如果一个流与交换机流表中的任何规则都不匹配,其首个报文将由交换机送至SDN控制器;控制器在接收到报文后,计算对应流在网络中的转发路径;控制器向转发路径上的各个交换机安装更新规则,交换机相应地更新自身的流表;流的后续报文以及其他的所有能够与该规则匹配的流按照此规则在数据层进行转发,不再需要控制器的介入.然而,如果在同一阶段,大量需要进行规则更新或安装的流到达交换机,会带来控制器南向接口路径的拥塞;另一方面,控制器需要为这些流计算新的规则,会引起额外的延迟.所以,需要为SDN的控制层流量设计合理调度机制:在保证数据层流量有效调度的基础上,降低集中控制引入的延迟和管理开销.

3) 故障恢复

可靠性是当前云计算和数据中心网络中很关键的一项性能.如果网络组件(控制器、交换机、链路等)出现故障,SDN需要提供透明、快速的故障恢复.在OpenFlow1.1中,针对链路和节点的故障提出一个快速故障恢复机制.该机制允许在当前规则之外指明一条备份的路径,交换机可以在不引起控制器介入的情况下使用备用路径继续转发.尽管SDN为故障的检测和恢复提供集中的视图,由于控制器需要计算新的转发策略并更新所有受影响的交换机,在SDN中实现快速恢复依然具有挑战性.所以,此类研究工作的关注点是:在存储和流表空间限制条件下,设计延迟低的故障恢复机制.此外,SDN集中控制器结构存在潜在的单点失效问题,需要设计可用性保证机制来应对控制器故障.

以上3个部分构成网络管理的一个闭环,底层的测量工作负责监控流量,将网络信息反馈给调度模块进行决策和具体的流量控制,故障恢复作为与调度并行的模块利用实时监测信息进行故障的发现、补救和及时处理.在接下来的3节中,将分别对流量工程中的流量测量、流量调度和故障恢复这3个方面的技术进行综述.

2 基于SDN的流量测量

流量工程的开展依赖于对网络流量准确实时测量,而云端、数据中心中涌现的多种类、大规模网络应用为测量任务的有效运行提出了挑战.基于SDN的流量测量的研究工作主要围绕如何支持、设计和部署灵活、准确、可扩展的测量任务,为相关应用提供有效状态信息.相关工作可做如下分类:

1) 从流量测量的实现角度,设计抽象通用的测量框架.OpenFlow为集中分配任务和监控提供良好的接口,然而,传统IP网络中的测量方法为控制器带来流量压力,所以需要设计面向SDN的灵活、通用的测量方法.

2) 从流量测量的应用角度,设计准确、及时的网络正确态检测方法,应对路由配置和规则兼容性方面可能存在的问题.

3) 从流量测量的开销控制角度,设计有效的资源管理方案.在网络设备中,用于测量工作的计算、存储资源有限,所以需要对其进行合理的利用和有效的管理.

本节首先对网络流量测量的传统方法进行简述,然后介绍和分析基于SDN的流量测量框架、正确态检测方法和资源分配管理方案.

2.1 流量测量框架

流量测量主要可以分为主动和被动两类方法:主动测量需要额外的探测流量,被动测量通过采样的方式对流经测量设备的流量进行监控.许多SDN测量系统使用传统IP网络中基于包采样的流量监控方法,利用网络中交换机随机地抓取流经本地的包进行信息统计.其中,应用最为普遍的就是思科的NetFlow[12].NetFlow规定使用5元组标识一个流,交换机维护一个流缓存记录每个流的信息,同时对到达的流的头部与本地缓存中的表项进行比较:如果匹配,则更新该流对应条目的包计数以及比特计数;否则,在缓存中为新的流增设一个条目.另一个流采样方法是InMon的sFlow[13].sFlow以一定比例在路由的每个入口处进行包采样,进而将采样数据包头与时间戳等原信息封装之后发送给中心收集者.JFlow[14]是一个专用的采样测量方案,思路基本与NetFlow一致.大规模网络的测量与信息收集增加中心控制器的负担与开销,因此,以上方法应用于SDN网络中效率较低.

针对传统测量方案的诸多局限,SDN中流量测量方法的研究主要围绕如何设计通用的测量框架、如何有效地汇总数据层流信息以及如何进行网络参数估计这3个方面的工作.表1总结了相关研究工作.下面分别展开分析.

Table 1 Traffic measurement methods in SDN 表1 SDN中流量测量方法
2.1.1 网络流信息的采集

交换机利用自身资源进行网络中流信息的收集和记录,控制器对收集的信息进行汇总、分析,为流量调度提供参考.折中考虑信息汇总的准确性和开销,研究者提出两类信息采集方法:主动式[15, 16]和被动式[17, 18, 19].其中,被动式又包括基于事件触发[15, 18]和基于时序触发[19]两种.具体来说,如下所示.

(1) 主动式信息采集

作为SDN的南向接口协议,OpenFlow支持控制器对交换机发起主动查询获取流信息.利用这个特性,文献[15]提出OpenTM,一个针对SDN的TM(traffic matrix,流量矩阵)估计系统——TM表示的是网络中一个源节点和目标节点对(OD对)之间的流量大小,对TM的准确评估,是负载均衡、异常检测、路由配置等网络操作和任务的基础.OpenTM对网络中 所有活跃的流进行探测,根据控制器中的路由信息和流的转发路径信息,提出多种有选择性的路由节点询问方法,从而获得准确的流量大小评估和数据包计数信息,并通过将一个OD对的所有流累加起来更新TM.

文章指出,流量测量的准确性与测量过程中使用询问消息所引入的测量开销之间存在一个权衡关系,即越准确的测量结果,意味着越大的测量开销.文中方法的缺点在于:控制器主动地进行周期询问带来开销;而另一方面,主观地选择一部分交换机进行询问,会损失测量的准确性.

围绕着测量开销与测量时效性和准确性之间的权衡,文献[16]对直接探测和被动采样测量进行折中,提出一种灵活的主动式信息采集方法Payless.在该方案中,控制器使用动态频率的询问方式进行统计数据的请求,而不是OpenTM中的使用的固定询问频率.此外,针对多个同时超时的流的询问,提出使用批处理的方式进行合并优化,使得询问的开销进一步降低.实验中,使用链路利用率(瞬时的吞吐率)和开销(单位时间的询问消息数目)对方案进行评价.分析发现:相对于固定频率方案中13.3个/s的询问开销,Payless引入的询问开销为6.6个/s.总的来看,Payless通过引入可观的测量开销,提高测量的准确率.

(2) 被动式信息采集

主动式流量测量在保证准确性的同时,不可避免地引入测量开销,降低带宽利用率.相比之下,被动式测量使用时间或事件触发机制,由交换机自主地向控制器反馈所采集的流量信息.

文献[17]提出一种被动测量方案FlowSense,利用SDN中的控制流进行流量变化的实时监测.基于流的网络监控要求能够准确、及时地探测,同时要求测量任务带来对网络尽可能小的开销.FlowSense利用OpenFlow协议中规定的南向消息接口的异步消息PacketIn和FlowRemoved(前者表示一个新的流的到达,后者表示一个流的结束)进行数据层中流状态变化的监控,进而计算交换机之间链路的利用率.文中采用由两个OpenFlow交换机和一个控制器构成的一个简单测试环境对方案进行验证,结果表明:相对于OpenTM所采用的询问方式,FlowSense有更高的准确性,没有引入任何额外流量开销;同时,可以在10s之内完成几乎全部的链路利用率评估.然而,采取这种基于特定消息的被动监控方式,使得方法只能在几个离散时间点进行速率的估计,对于一个持续时间较长的流,无疑降低了获取流信息的时效性.

文献[18]中提出的方法MicroTE使用机组中的服务器进行流状态监测和被动式的流信息统计,并在流状态发生显著变化时触发一次信息的汇总行为,根据流的平均流量值和瞬时流量值之间的偏差大小决定其是否趋于平稳可预测[20],进而由控制器集中的制定路由转发决策.

在文献[19]中,IBM提出一种利用协议信息改进sFlow的被动式流量测量方案OpenSample.文中指出:使用包采样的sFlow[13]技术在测量的准确性上受到采样率的限制,而在提高准确率的两种直接方法中,提高采样概率会增加网络设备CPU的负担,降低采样间隔与方案设计的低延迟的初衷相违背.OpenSample基于一个观测统计的事实——数据中心的流量中99%都是TCP流[21],提出通过计算同一个流中相邻两个采样包中TCP头部的序号差,进一步除以sFlow采样数据中自带的对应采样时间戳的差值,从而得到TCP流在该测量窗口中的准确速率值.实际过程如图4所示,其中,SiTi分别表示测量获得两个流在时间点i上的TCP序号,t是采样的时间,两个流的速率可以分别表示为(S2-S1)/(t3-t1)和(T2-T1)/(t4-t2).通过被动测量以及引入协议相关信息,该方案有效地提高了准确率并降低了延迟.OpenSample在监控时将任何具有超过两个样本的TCP流视作一个elephant流,而elephant流是流量工程所关注的重点,也是DDoS等安全检测的关键,所以,OpenSample相对于MicroTE[18]等方法而言,能够对更多的流进行测量、优化与管理.

Fig.4 Throughput estimation based on TCP-specific information in OpenSample[19] 图4 OpenSample中利用TCP特定信息进行吞吐率评估[19]
2.1.2 网络参数评估方法

网络延迟、带宽和丢包率等是网络管理和网络服务质量保障所需的重要性能指标.文献[22]提出的OpenNetMon给出几种网络参数的测量方法.它被设计为POX控制器的一个模块,可以支持细粒度的流量工程.模块以自适应的频率询问交换机获取流信息,同时保证获得准确的测量结果和最小化交换机CPU的开销. OpenNetMon持续地对所监控网络的吞吐率、丢包率和延迟进行测量.具体来说,如下所示.

1) 测量吞吐率时,仅对路径的最后一个交换机进行自适应频率的询问,数据层的计数器返回采样间隔T中各个流的包数目S,通过计算S/T得到路径上一个流的吞吐率.

2) 计算丢包率时,分别询问一个路径的第1个交换机和最后一个交换机,获得两者计数器的统计数据,用测量周期中第1个计数器的增量减去最后一个计数器的增量,除以时间就是该阶段以两个交换机为端点路径的丢包率.

3) 计算延迟时,OpenNetMon向路由的数据层注入探测报文,探测报文通过路径、节点和控制器与路径两个端路由之间的链路,最后再次返回控制器,利用这个延迟减去控制器和交换机之间的通信延迟,即获得所探测路径的通信延迟.

FlowSense[17]在SDN基础上增加监控模块,通过解析控制器接收的消息,动态分析流量变化情况.例如,控制器在收到对应于某一个流的FlowRemoved消息之后,利用统计得到的流的大小值除以对应流在网络中存在的时间,即可得到流的吞吐率信息.

总的来看,传统的网络测量可以位于OSI的各个层次,即,各个层次都对应着可以反映网络情况的参数.其中,应用层和网络层是两个比较普遍的选择;而一般的参数评估都采取网络层测量,使用路由器或交换机进行监测.然而,网络层获得的测量数据都是针对设备端口计数器而言的(如SNMP中,通过周期性的询问交换机可以获得每个端口的计数信息),不能针对单独的应用流进行测量.OpenFlow支持针对每一个流进行数据统计,从而决定端到端网络的性能.另一方面,已有的测量技术都基于额外的硬件或软件配置的支持,开展测量任务需要较大的开销.SDN将传统的分布式控制逻辑进行集中,无需额外的配置与硬件开销,即可高效地完成测量工作.

2.1.3 通用流量测量框架

表1所示,面向不同的应用需求和测量目标,研究者提出了多种基于SDN的流量测量方法.为了有效地支持多种测量任务和应用程序,设计一个通用的测量框架是有必要的.

文献[16]中提出的PayLess是一个基于询问的、低成本的流量测量框架.PayLess框架位于OpenFlow控制器的北向接口上,并为应用提供RESTful风格的接口.具体来说,测量框架负责解析应用发出的请求级的任务,将其解析为对部分交换机的询问规划,同时负责将反馈到控制器中的统计信息进行汇总.所以,Payless为应用维护一个抽象网络信息视图,为多种网络应用提供一个良定义的编程接口——应用以JSON格式将任务下达,并支持将用户自定义的构件加入到测量框架中.

文献[23]提出一个通用的、抽象的测量框架OpenSketch,使用一种类似于OpenFlow中自定义转发的软件定义方法进行流量测量.文中指出:基于流的测量存在计数器开销和准确率的问题,且无法满足不同用户的需求;另一方面,基于sketch的方法针对用户定制,然而任务与设备的耦合度太高,不同任务对硬件有不同要求,所以很难将多个任务的解决方法部署到同一硬件设备中.为了充分权衡通用性和效率,OpenSketch提出将测量的控制和数据层进行分离:数据层设计为一个可动态配置的3阶段流水线,每一个阶段都使用商用交换机组建构成.如图5所示,第1阶段提供多种哈希算法,将数据包映射为少量的测量数据,第2阶段利用TCAM(ternary content addressable memory)进行规则存储和通配符式的匹配,第3阶段通过SRAM提供灵活的计数.通过这种流水线的设计,OpenSketch将多种测量算法抽象成若干通用的步骤;另一方面,在控制层中提供一个测量任务库,根据用户或应用的选择调整数据层流水线的各个环节,支持更多种询问类型,使得用户可以在商用交换机组件上应用新的测量算法.需要注意的是,OpenSketch的实现需要对交换机的部分硬件进行重新设计,这是网络运营商不愿意选择的.

Fig.5 OpenSketch architecture[23] 图5 OpenSketch的框架[23]
2.2 网络正确态检测

网络正确态是指在对数据进行转发的过程中,网络所表现出的正确的行为和状态,如数据包不会陷入路由环路.数据在网络中的转发依赖于各类网络设备所提供的多种功能,过程复杂且容易受到潜在的配置错误、软件缺陷等问题的影响,导致包括循环路由在内的各种错误.SDN简化网络应用,但是软件自身具有的复杂性导致错误依然难以避免.此外,SDN支持多个应用对同一个物理网络的流量进行共享的配置,导致配置规则存在冲突的可能,影响网络性能.因此,对SDN的正确态检测与规则验证是测量工作中的重要部分,目前的研究主要集中在设计、运用不同的检测方法进行正确态的测量.

2.2.1 模型检测方法

通过设计维护一个问题搜索模型,模型检测法对网络应用、配置规则中潜在的破坏正确态的问题进行检测.文献[24]提出一个结合模型检查和符号化执行(程序中有变量符号)的网络正确态验证工具NICE,目的是找出OpenFlow应用中的错误(举例来说,控制器响应新到达网络的流,产生一条规则,此时,如果多余的包也到达则可能超出程序的预期,引起应用的错误),维护网络应用的可靠性.NICE将OpenFlow程序、网络状态和一个正确态作为输入,利用模型检查对状态空间进行搜索,验证各个状态下的正确性,最后输出破坏正确态报告.通过使用NICE,OpenFlow程序可以对路由循环、空洞等问题进行检查.在实现方面,NICE采用Python语言,以无缝地支持OpenFlow控制程序.

2.2.2 静态检测方法

静态检测的方法将收集的网络状态形式化,分析判断其是否破坏指定的正确态.文献[25]指出:在已有的正确态检测工作中,分析过程对控制器下发的配置文件进行检查,无法分析路由软件中的问题,且很难应付不同厂商的多种设备配置语言.文中提出:可以将诊断过程尽可能地靠近网络的数据层次,更直接地观察网络行为,从而发现配置生效之前无法发现的问题,并支持对多种协议和语言环境的统一分析.

根据以上分析,文献[25]提出Anteater——一个基于数据层静态分析的正确态检查工具.它的主要工作流程是:首先,将网络的连接状态和交换机中的转发信息(FIB)转化为布尔表达式然后将3类正确态——无环路由、网络连通性、规则的一致性表达成SAT问题;其次,选择一个待检查的正确态,与转化为布尔表达式的网络状态与转发配置一起带入SAT求解器中进行分析.如果存在一个破坏正常态的配置规则,Anteater则会构造一个特殊报文来触发所对应的问题.在实际场景的测试中,Anteater成功地在所部署的校园网中发现了23个网络问题.

2.2.3 实时检测方法

实时地对流转发规则进行检测,对于发现规则冲突、维护正确转发状态是非常重要的.文献[26]提出VeriFlow——一个面向SDN网络进行实时检查和调试的工具.在设计中,将VeriFlow插入在SDN的控制层和数据层之间,实现对配置到网络中每一条规则的监控和检查,更新的预先检查使得冲突可以提前被发现并发出及时的警告.在更新和删除规则时,VeriFlow通过3个步骤实现对规则的快速验证:首先,将网络中的包分类为一个对等类(经历相同的规则-动作的包)集合,并以对等类为原子单位进行对规则的验证;然后,为每一个对等类建立转发图;最后,设计一种检测算法,将更新规则与对应的对等类转发图作为输入(NICE和Anteater将网络状态和一个待检查的正确态作为输入),通过深度优先的方式遍历所有受更新影响的对等类中的路径,从而判断一次规则的更新是否会产生网络异常.实验结果显示,使用VeriFlow,可以在数百微秒的时间开销内完成对网络正确态的检查.

2.3 测量资源的管理

如前文所述,流量信息的采集和汇总是流量测量的两个重要部分,信息采集过程中,需要来自数据层的硬件支持——TCAM(存储对流进行监控的规则).然而,现有交换机的片上资源往往是有限的;此外,网络应用有同时进行多个流量监控任务的需求,而不是在一段时间内仅支持一个测量任务.所以,如何合理地调度分配硬件资源、提供准确而有效的流量测量是十分重要的.

2.3.1 测量信息的存储调度

针对资源有限和多任务需求,文献[27]提出DREAM——一种自适应的硬件资源分配调度方案,可以有效权衡测量的准确性和资源开销.方案依赖两个观察:

1) 流量测量任务的准确性依赖于分配给任务的资源量(TCAM数).随着分配给任务的资源数目的增加,会出现一个收益递减点,在该点之后,增加资源量对任务准确性的提升能力变小.换言之,提升相同幅度的准确性所需要增加的资源更多.

2) 测量任务所需要的资源数目随着时间和所关心的流的大小在不断变化,所以可以对各个探测任务进行时间和空间上资源(TCAM)分配的复用.

图6所示,DREAM框架主要包括3个层次:

Fig.6 DREAM architecture[27] 图6 DREAM框架[27]

· 最上层的是用户层,负责生成一个测量任务,包括任务类型、具体的流量阈值和精确度要求等,并作为实时检测结果汇总的终点.

· 中间层次是运行于SDN控制层上的DREAM算法.它负责接收来自用户的任务并创建对应的任务对象,通过SDN的控制接口将抽象任务部署到多个交换机中.部署过程就是在交换机中请求TCAM资源,并将测量逻辑存储在TCAM中完成实时的测量.根据实时反馈的流量监测情况,算法对测量的准确性进行评估,调整为各个任务分配的资源,进行多个任务之间的资源复用;另一方面,根据当前所有任务可以达到的准确性情况,决定是否接受一个新任务.

· 最底层是SDN网络.控制层进行集中控制和动态配置,转发设备为测量提供存储资源,并反馈实时流计数的结果.

2.3.2 流量计数的优化

文献[28]指出,交换机中的集成电路使用的硬件计数器缺乏灵活性,占用较大空间且无法有效开展新的测量方法.针对这一问题,文中提出利用软件自定义的思想改进ASIC(application specific integrated circuit)的设计,将传统的ASIC内部硬件计数改为利用基于CPU+DRAM的软件自定义计数(SDC).

SDC是一个软件自定义的计数方案.文献[28]中指出:一个“聪明控制器,愚蠢交换机”的SDN模型过于极端,尤其是在交换机中搭载高性能嵌入式CPU成本越来越低的情况下,所以提出利用交换机本地的CPU降低ASIC的复杂性.SDC的计数流程为:ASIC利用触发的方式将小容量流信息记录缓冲中的信息通过总线发送给ASIC外部的通用CPU,C PU对信息流进行处理并利用DRAM保存流计数,控制器访问CPU而不是ASIC来获得统计信息.SDC的收益可分为3个方面:首先,增加处理计数器相关信息的灵活性;其次,降低控制器获取计数器信息的开销;最后,由于将计数部件移除,所以节省ASIC宝贵的空间,并降低复杂性.利用这些优势,SDC为灵活的测量提供更有效的硬件资源支持.文献[29]对该方案进行了硬件实现.

3 基于SDN的流量调度

随着数据中心基础设施的不断扩展以及网络技术的不断变化,新兴网络应用越来越依赖有效的网络管理,以提供高可用性、高质量、低成本的服务.SDN不仅为快速的实验创新提供了一个合适的平台,而且改变了管理网络的方式——取代以往对网络“片”式的管理.SDN通过集中控制器进行面向全局的策略部署,同时,动态地收集网络状态.此外,SDN提供对网络事件更快反应的能力,从而降低网络管理的延迟.

网络管理旨在维护网络可用性和提高网络性能,对网络流量的合理调度(路由优化),是有效分配网络资源,提升网络性能和服务质量的重要途径.数据中心网络中源和目的节点之间存在多条路径,为流量调度提供空间. 在SDN中,控制器维护的全局视图反映网络中各路径的使用情况,流量可以据此进行动态的转发以实现负载的均衡;另一方面,对流量转发规则的实时安装与更新增加集中控制器的压力,也带来相应的处理延迟,所以,SDN中的流量调度可以分为对数据层流量的调度和控制层内部流量的调度,前者主要利用SDN的集中控制功能改进传统网络中的流量调度方法,后者主要围绕如何缓解SDN中集中控制器带来的流量调度瓶颈问题.

3.1 数据层流量调度

合理的网络流量调度可以提高链路的利用率,避免网络拥塞,为应用提供有效的带宽支持,满足用户的需求.传统IP网络中使用最短路径路由(如OSPF)进行链路间负载的分配,交换机之间通过交换静态的链路权重计算出转发的最短路径.然而,基于权重的路由策略不能将流量分配到多个后续路径上,无法有效地进行负载均衡.ECMP(equal-cost multi-path)通过对数据包头部进行哈希运算,对数据流进行转发路径的映射,使用类似于ECMP的调度方案可以将到达一个节点的流“分散”到后续的多条可用路径上[30].然而,此类方案根据局部信息进行流量的调度,往往会造成网络中某链路或节点的拥塞.

SDN使用集中控制器计算流量转发规则,实现路径之间的负载均衡.与以往流量调度工作相比的主要优势为:转发决策是集中式而不是分布式制定,能够有效地结合多个可选链路的占用率和流量的大小特征.按照调度的分配实体,可将基于SDN的数据层流量调度工作分为路径和服务流量的负载均衡两大类,进一步可将前者分为基于elephant流(超过一定大小且持续时间长的流)识别的调度、面向QoS的调度以及其他算法,具体如图7所示.本节将对该分类中的调度工作进行逐一介绍.

Fig.7 Classifications for traffic management schemes in data plane based on SDN 图7 基于SDN的数据层流量调度方案分类
3.1.1 基于elephant流识别的流量调度

(1) 基于ECMP改进的流量调度

在ECMP路由中,拥有相同IP的流会沿着相同后续路径进行转发,可能导致多个elephant流映射到同一路径上,从而引起负载的不均衡和链路吞吐量的浪费[31, 32].图8中给出一个示例,图中到达聚合交换机的流A和流B被映射到同一后续路径,造成聚合交换机处的流长时间排队,而另一后续路径却没有任何转发流量.没有合理参考当前链路的利用率和流的大小,是引起大量数据包拥塞到一个端口、造成传输延迟长的主要原因.直接的解决方法是:从包级别(ECMP中是流级别)进行ECMP的流量切分,虽然极大地增加了负载之间的均衡性,却加重了TCP流中报文的重排序问题,引起TCP发送窗口的不必要缩减[33].下面介绍基于SDN的ECMP改进方案.此类方案的主要思路是识别elephant流,进而利用控制器为其选择合适的路径.

Fig.8 A case that multi-elephant flows are mapped to the same path in ECMP[31] 图8 ECMP将多个大流量映射到同一路径的一个案例[31]

文献[31]提出的Hedera是一个可扩展的、动态的流量管理系统.它面向数据中心的多级路由结构,提出通过自适应的调度流以有效利用网络资源,实现等分带宽(穿过网络截面的最大传输率)的最大化.文中指出:为了有效利用数据中心服务器之间的多条路径,需要及时地探测并管理elephant流(含大量数据的流).基于这个出发点,Hedera开展包含3个基本步骤的调度策略:首先,在边界交换机(端服务器的出口路由)中对大流量数据流进行探测,在默认情况下,Hedera使用ECMP进行流转发;同时,通过向交换机周期性地询问(实现中为5s)收集流信息,如果流的速率超过特定的阈值(实现中指定为100Mbps),则标记为elephant流;进一步来说,系统对判断为elephant的流的带宽需求进行 估计,结合后续路径的负载情况,动态地为其计算合理的转发路径.

在文献[31]中,为elephant流计算转发路径的算法是开放的(可以由用户自己定义).文中分别尝试全局首次适应算法(global first fit)和模拟退火算法(simulated annealing),并对两者进行比较.以全局首次适应算法为例,已知elephant流的带宽需求D,全局首次适应算法线性地搜索所有可选路径,将遍历过程中发现的空闲容量可以满足D的首个路径作为转发路径,进而在构成该路径的各个链路中进行容量的预留.最后,将转发策略(规则-动作)更新至路径上的各个交换机中.

文献[31]通过实验指出,Hedera可以达到最优带宽利用率的96%;同时,相对于静态的调度方法,有效地管理elephant流使得网络总体吞吐量增加超过100%.

文献[34]提出的Mahout引入端服务器检测降低流量管理的开销,它同样提出通过优化对elephant流的管理提高路径带宽的利用率.首先,文中指出,Hedera方案中的elephant流探测方法利用的是基于网络内部的探测,往往引入较长的探测延迟、较高的交换机探测资源开销、较大的控制报文开销或处理开销.所以,Mahout提出使用端服务器而不是转发设备进行elephant流的探测,实现高效、低开销的流量管理.在Mahout的实现中,每个端服务器操作系统中抽象出一个shim层,shim层负责通过本地的套接字缓冲监视该服务器产生的流,当缓冲超过指定阈值时,则将对应流判定为elephant流,然后对该流的后续数据包进行标记.Mahout控制器通过高、低两个优先级设置流表,缺损情况下,数据包匹配低优先级规则,交换机利用ECMP对其进行转发;标记为elephant流的数据包会匹配高优先级规则,交换机会将其发送至控制器,控制器进行最优路由的计算,并更新交换机中对应流的转发规则.

对于elephant流的管理,Mahout采用离线首次适应算法(offline increasing first fit)遍历所有可选路径,并利用如下公式计算所有路径的拥塞度:

congest=(f.rate+path.load)/path.bw (1)

其中,f表示流,f.rate表示其速率,path表示一个可选路径,path.load表示路径上的背景负载,path.bw表示路径的带宽,congest表示评估的拥塞度.算法选择拥塞度最小的路径作为最优的路由.

Mahout方案的优势在于:对elephant流的测量过程不消耗交换机的CPU和存储资源,不产生集中的带宽开销;此外,将对elephant流的判断放在端节点中,使得数据只会缓冲在应用层而非堆积在网络层设备中.实验结果表明:Mahout能够有效地增加网络中路径带宽的利用率;同时,相对于询问测量方式,能够降低检测elephant流的延迟.

(2) 基于通配符的流量调度

OpenFlow协议规定:交换机将未匹配流的第1个数据包发送至控制器,控制器通过计算将一个新的匹配规则安装到交换机中,流量依赖规则进行转发路径的映射.大量流的到达以及流量信息收集的开销,使得集中的控制器成为瓶颈.为了降低数据层向控制层传输的数据量,支持高性能的网络需求,文献[35, 36]中提出使用基于通配符的规则同时匹配多个流,避免控制器频繁地介入(由于此类方案的目的是减少控制流量,所以一并归入后文的表2进行总结和对比).

文献[35]中提出DevoFlow——一种资源节约的、可扩展的流量调度方案.它对OpenFlow模型进行修改,提出仅将必要的流从数据层转发至控制层,从而放松集中化控制引入的交互开销.具体来说,DevoFlow提出控制器应该在发现一个流为elephant流后对其进行重路由,而不是将所有到达网络的流都视为一个潜在的elephant流,以避免由此带来的控制延迟和开销.文中设计了一个基于通配符的多路径匹配规则,在初始情况下,交换机使用这一规则进行流的转发;同时,引入一种流量信息统计的方法识别elephant流,被识别的流需要控制器的介入进行最小拥塞路径的重路由.仿真结果显示:较之以往的需求,DevoFlow平均少使用10~53倍的流表项和10~42倍的控制信息.

与DevoFlow[35]类似,文献[36]提出的DIFANE是一个基于通配符的、高效率的流量调度方案.DIFANE的核心思路可以概括为两个方面:首先,控制器将规则以最小划分的方式分发给一部分称为授权子集的交换机;其次,交换机在数据层中处理所有的包,如果流无法与入口路由本地的规则匹配,则将其封装、重定向到合适的授权路由,授权路由对包进行处理并反馈规则.整个管理过程涉及3种通配规则:常规转发规则、定期更新的授权路由规则和重定向规则.在实现方面,文献[36]中提出的方案易于使用商用交换机实现,且仅需要少量的软件扩展,因为所需要的数据层功能都可以由通配符规则来表示.

3.1.2 面向QoS的流量调度

在网络中,大量的实时业务流对传输过程中的延迟、丢包敏感[37],所以,合理地调度网络资源,为实时业务提供QoS保证是流量工程的一项重要工作.SDN网络提供的控制接口支持灵活的流量调度策略制定,以充分兼顾不同网络应用的需求,并缓解网络中交叉节点或链路上的拥塞.

文献[38]提出了OpenQoS方案,为多媒体的传输分发提供QoS保证.基于多媒体业务流的数据包头部与其他流中包头部的不同,OpenQoS利用OpenFlow配置匹配规则将流量分为多媒体流和数据流两组.针对多媒体流,OpenQoS结合后续路径在延迟和丢包两方面的表现为其选择一条QoS路径,其他数据流保持在最短路径上.该方案仅对多媒体流的调度进行优化,没有考虑多个有QoS需求的业务流同时进行调度的场景.

UCLA大学的Mario的研究小组提出一个SDN网络中基于集中式流量调度的QoS增强框架[37, 39].该方案考虑的具体问题是:在一个有交叉节点或链路的网络中,如何为多个应用的业务流量选择合适的路径,在满足流量的QoS需求的条件下,分配到每个路径中各个链路上的流量大小不会超过链路的容量.文献[37, 39]中提出的框架包含6个关键组件:网络拓扑映射模块和网络状态收集模块负责监控数据层,动态地捕获拓扑的更新和收集网络参数,最后生成网络中各路径的权值图;路径选择模块结合业务流量的需求和权值图为不同应用选择合适的后续路径;动态路径配置模块在QoS管理模块的指导下,在合适的时机将新的路由规则更新到数据层;作为框架的核心模块,路径选择模块利用文中提出的MCFCSP(multi-commodity flow and constrained shortest path)模型进行调度决策,模型考虑在网络G=(N,A)中为业务流量集合K建立转发策略,模型的目标函数为

$\min :\sum\limits_{(i,j) \in A} {\sum\limits_{k \in K} {{c_{ij}}x_{ij}^k} } $ (2)

其中,表示业务k转发至链路(i,j)上的流量大小,而公式(3)表示链路(i,j)的开销:

cij=adij+bpij,∀(i,j)$\in $A (3)

其中,dijpij分别表示网络状态收集模块通过实时测量获得的链路的延迟大小和丢包率统计值.

结合模型给出的关于参数和变量的限制,可以对这一NP完全问题进行求解(文献[37, 39]中指出,该方案适用于规模较小的网络),获得全局的调度策略.文中基于Mininet平台对方案进行验证,实验结果显示,该方案可以在链路出现拥塞时,为包括视频和文件传输在内的业务流量提供高于设定阈值的带宽资源,满足实时业务的QoS需求.

3.1.3 其他流量调度算法

OpenFlow协议的出现,为权衡数据中心网络中与日俱增的业务流量带来的压力提供途径.然而,文献[40]中指出,在已有的基于OpenFlow的协议中,仅仅在流初始化时利用全局信息为其建立一条静态路由规则,流在传输过程中网络的配置可能发生变化,导致规则不适用,网络性能受到影响.针对以上问题,文中提出一种路径上的负载均衡路由算法LABERIO,LABERIO利用如下公式决定是否进行重调度:

${\delta ^*} < \delta (t) = \frac{{\sum\limits_1^N {{{[{{\overline {load} }_{i,j}}(t) - loa{d_{i,j}}(t)]}^2}} }}{N}$ (4)

其中,loadi,j(t)表示链路(i,j)上的负载;d(t)给出所有链路负载的方差,该值与网络的稳定性成反比,当其超过给定的阈值d时,说明有必要进行转发规则的重计算.调度算法的核心是,将网络中最拥塞的链路上占据最大带宽的流量调度到其他后续路径上.具体来说,通过对最拥塞链路(i,j)上各个业务流的负载占总体的比例进行排序,进而选择以i为起点、j为终点的所有路径中开销最小的,将排序出的最大流通过该路径转发.

文献[41]中提出一种基于模糊评估模型指导负载平衡决策的流量调度方案.该方案的执行分为初始模式和周期模式两个阶段:

· 初始模式下,文中利用经典的Floyd算法为网络中的两点(s,e)计算出最短的K条路径,目的是在进行动态选择时可以提高效率.

· 当网络中有业务流之后,方案进入周期模式,周期性地执行路径的模糊评估方法.方法首先获取K条路径的跳数h、传输的包计数p、关键交换机的字节计数b以及关键端口的转发速率r几类特征,经过转换之后,得到各条路径的影响向量Ri=(r1,r2,r3,r4),从而构成模糊关系矩阵R=(R1,…,Rk);最后,利用一个给定的权值行向量WR求积,得到各路径的评分向量S,选择评分最高的路径作为最短路径,分配给对应业务流.

3.1.4 服务请求流量调度

在现今的网络服务中,往往采用多个功能对等的服务器提供服务,服务请求首先到达一个负载均衡器,均衡器通过预定义的策略将请求分发至不同服务器,使得服务器的处理压力得到分摊.然而,现有的均衡器存在价格昂贵、单点时效问题,而且均衡器的调度逻辑固定,无法有效地进行调度策略的更新和优化.基于OpenFlow的控制器可以动态地收集服务器的负载情况,为解决传统负载均衡器存在的问题提供一种可行的方案.

由斯坦福大学提出的Plug-n-Serve方案(现在更名为Aster*x)是一个基于OpenFlow进行Web流量负载均衡的应用[42],它的目标是降低服务请求的响应时间,即,通过合理选择网络路径和服务器降低发起请求到收到回复的时间.方案的主要逻辑架构如图9所示,Aster*x通过OpenFlow控制器监视网络和服务器状态.其中,控制器主要由流量管理者、网络管理者和主机管理者这3个部件构成.其中,网络管理者以探测的形式对路径的占用率进行实时的评估,同时发现意外的拓扑变化;主机管理者监视系统中每个服务器的运行状态和负载情况;网络和主机管理者将收集的网络拥塞信息和服务器负载信息报告给流量管理者,流量管理者使用LOBUS算法进行请求流量的调度,最小化请求的延迟.

Fig.9 Main control logic of Aster*x[42] 图9 Aster*x的主要控制逻辑[42]

文献[43]提出为每个到达的服务请求计算、安装一个转发规则会产生大量的流规则,并造成控制器的处理拥塞,所以提出基于OpenFlow的服务负载均衡器应该利用通配符规则将服务请求进行聚合处理,避免流表的膨胀,降低控制器的压力.一般情况下,负载均衡器扮演一个NAT服务器的角色,收到请求之后,将流的目的地址改写为某个服务器的IP地址,交由该服务器进行处理,每个服务器有单独的IP和一个标志其预期应处理总体请求比重的权值.文献[43]针对的是需要预先安装在交换机中的部分规则,在原有调度算法生成的以单个请求为单位转发规则的基础上,将多个IP前缀匹配的转发规则聚合成一个含有通配符的规则,有效地控制转发规则个数.

3.2 控制层流量调度

SDN的集中化控制器需要处理从数据层转发来的大量数据包,构成处理过程的瓶颈,面临缺乏扩展性在内的一系列问题[44].文献[45]指出:一个典型的NOX平台(首个OpenFlow控制器,使用最为广泛)每秒可以对30K个流进行初始化,平均每个流占用10ms.然而,这个延迟水平无法满足SDN应用场景的需求,尤其对于大规模的数据中心.为了提升处理效率,一个直观的策略就是在控制层面引入多个控制器,从而将流量合理地分配到不同控制器上,有效地缓解单点压力.围绕这一思路,控制层流量调度的主要工作为:协调部署多个控制器以缓解集中控制的处理压力,降低延迟开销,并维护充分的可扩展性.表2对控制层调度方案进行总结.具体来说,如下 所示:

Table 2 Methods and models in traffic management表2 流量调度方法及模型

(1) 逻辑集中物理分布式控制器结构

逻辑集中的分布式控制器结构可以有效缓解集中控制的压力,同时,利用逻辑上的抽象保留原有的控制器南向接口.文献[44]提出的HyperFlow是一个基于事件的分布式OpenFlow网络控制平台,它利用分布式的控制器结构对网络进行逻辑上集中的控制,从而在解决扩展性问题的同时保留集中控制的优势.在该文献提出的设计方案中,HyperFlow规定:每一个交换机使用OpenFlow协议与它邻近的控制器通信(临近指的是具有最小的通信开销);另一方面,多个控制器之间采用事件传播系统进行同步,维护一个共享的、一致的网络视图.

(2) 物理分布式控制器结构

与逻辑集中的结构相比,直接利用物理分布的控制器结构同样可以缓解流量对集中控制器的冲击.文献[46]提出的Onix是一个运行在1个或多个服务器上的分布式控制平台,Onix的核心是一个通用的网络控制接口,运行在多个控制服务器上的应用可以通过接口读取和修改网络中任何设备,从而保持设备和应用的一致性. Onix将收集的网络状态保存在一个称为NIB的数据结构中,控制器通过复制和分发NIB共享全局的视图.值得一提的是,Google的B4项目使用的就是Onix控制平台.

与Onix类似,文献[47]提出的BALANCEFLOW是一个基于OpenFlow网络的控制器负载平衡框架.文章指出:发送给控制层的请求流应该被动态地分配给多个控制器,一个控制器上过载的流应该自动地被转移到另一个控制器中,以维持最大的控制器利用率.不同于HyperFlow中在交换机级别进行控制器分配,文献[47]提出在流级别进行分配.该方案在OpenFlow协议基础上扩展一个X动作,该动作将流转发至X对应的控制器.控制器提前或实时地将含有X动作的流表项安装到交换机中,这就为需要转发到控制层流量提供被灵活调度的能力.同时,BALANCEFLOW在设计中引入一个超级控制器,用于分析其他控制器周期性推送的流请求信息,如果发现流量不均衡,则进行集中式的流量重调度,并将修改的X规则发送至对应控制器,进一步更新到数据层.

(3) 层次分布式控制器结构

层次化分布式控制器结构尝试将部分控制功能移至引入的本地控制器,以解决集中控制器南向接口的拥塞问题.文献[48]中提出的Kandoo利用层次化的控制器部署方法缓解控制集中化的扩展性问题以及控制请求对控制器的压力.文中指出:将流量控制在数据层需要对交换机进行修改,且牺牲一定的全局视野.所以提出层次化的分布式控制器结构,保持集中控制的优势,也避免对交换机的修改.Kandoo框架中包含两类控制器——本地控制器和逻辑上集中的根控制器:本地控制器以一对多的形式管理交换机,处理依赖于本地信息的应 用——一部分如链路层发现协议的应用仅需要交换机本地操作;而根控制器则用于支持需要全局信息的应用,并通过本地控制器更新规则.

3.3 流量调度的虚拟化

SDN为网络应用提供统一编程接口,应用通过接口对数据流进行管理、对网络资源实行调配,通过虚拟化技术可以实现网络流量和资源实体在多个应用之间的高效共享.

作为一种典型的流量虚拟化调度方案,FlowVisor[49]是一个基于OpenFlow的、插入在交换机和控制器之间的虚拟化层,也可理解为一个逻辑分布的控制器或一个资源代理,目的是取得与计算机虚拟化相同的效果. FlowVisor的结构如图10(a)所示,该层次针对带宽、拓扑、流量、CPU以及转发表这5个方面的资源进行虚拟化,将总的网络流量分片之后,交由多个控制逻辑管理,每个控制器面向一个客户自定义的策略,仅针对对应的流量分片进行操作.通过这种方式,FlowVisor允许多种网络配置以不相交的方式运行于多种硬件上,向上为用户提供独立的自定义和优化能力,向下抽象覆盖多种速率、介质的网络形式.

Fig.10 Architecture of FlowVisor and hypervisor[49, 50] 图10 FlowVisor和hypervisor结构[49, 50]

上述的传统方式将网络中的流量分成多个不相交的“片”,每个应用只能选择一个“片”进行操作和调度.虽然提供多用户共享网络的能力,然而多个用户的应用无法同时生效作用于同一个分片上.文献[50]指出,未来SDN网络中的超级管理器应该允许将多个应用的策略同时映射到一个流上.所以提出并设计了一种复合式的管理器以简化网络管理,支持不同平台、不同语言同时对流量进行处理.图10(b)中展示位于控制器和应用之间的复合式超级管理器的逻辑效果.最上面一层是进行负载均衡、路由和测量功能的3个应用,3个应用产生OF规则并送至超级管理器,并由它判断规则之间是否可以并行(+),还是需要串行(>>),然后,将规则安装到网络中的交换机上.

通过设计超级管理器实现对网络的虚拟化管理过程中,最大的挑战和主要的研究工作是如何为多个用户应用提供正确、有效和实时的规则更新算法.

4 基于SDN的故障恢复

故障管理是面向数据中心以及企业级网络的通信服务的基本功能.有效的故障管理需要及时响应网络组件的故障,对可用的网络资源进行重分配,以保证服务的可用性.在传统的IP/MPLS网络架构中,通过传输层和网络层的分布式协议进行故障恢复,协议提前针对可能的故障(如节点失效)计算资源分配方案,在出现故障之后,利用消息机制激活备份的分配方案[51].

SDN将网络流量的控制和转发逻辑解耦,提供传统分布式网络结构所不具备的可编程性,但也造成传统故障恢复机制在实施过程中缺乏灵活性和效率,具体的问题可概括为:

1) 由集中的控制器负责响应失效事件,增加失效处理的延迟和通信的开销.实现快速的故障恢复(文献[52]中给出的量化指标为50ms)是有挑战的,因为检测到错误之后,控制器必须计算一个新的路由,并将恢复规则更新到所有受影响的交换机中.

2) 集中控制器本身存在单点失效的隐患,控制功能的故障将进一步导致转发功能非正常运行.

所以,SDN中故障恢复相关的研究工作可以分为数据层的故障恢复和控制层的故障恢复两个方面.

4.1 数据层故障恢复

在传统网络中,针对网络设备和链路的故障恢复机制可分为两类[51]:

1) 非预留型.在此类方案中,用来替代故障路径的备份路径可以是提前或动态计算分配的,但是相应的链路资源没有预留.当路径故障出现之后,需要一个特殊信号来通知建立恢复路径.

2) 预留型.用于故障恢复的路径是提前计算并预留好的,即工作路径和备份路径对应的规则是同时计算和安装的,所以在发生错误时不需要触发额外的信号.

不难看出,非预留型方案采用的是实时应激性恢复策略,而预留型方案是前瞻性策略.两类机制在SDN中都得到运用:

· 一方面,文献[53, 54]中使用非预留型策略,在控制器收到链路故障的通知(OpenFlow协议中的PortStatus消息)之后,会先确定受到影响的路径的列表,然后使用OSPF算法为受影响路径计算恢复路径,最后将新的表项安装到交换机.对于既处在故障路径上也处在恢复路径上的交换机,需要对流表进行修改,否则删除或添加相应的表项.

· 另一方面,文献[55, 56]中采用预计算和预留恢复路径的策略,控制器将计算得到的预留路径与正常路径一同安装在交换机中.容易看出,SDN中采用非预留策略的缺点在于:网络需要在出现故障时引入控制器,并且修改流表,增加故障恢复的延迟;另外,预留策略通过牺牲部分存储开销,降低故障恢复延迟和恢复过程的通信开销.

所以,对于重视无故障连续运行的大规模SDN系统,更倾向于使用预留方案进行有效的故障恢复.

文献[53, 54, 55, 56]的研究工作为SDN网络提供了基本的故障恢复功能,在此基础上,针对如何进一步提升故障恢复的速率、如何降低访问集中式控制器的开销以及如何将故障管理逻辑从SDN应用中解耦,展开了一系列相关研究.

(1) 降低故障恢复延迟

通过降低生效延迟和控制更新延迟,可以实现更快速的故障恢复,生效延迟指的是恢复路径等待原表项超时的时间.文献[53]提出通过直接删除失效链路的表项,再添加更新的表项,从而降低生效延迟.另一方面,鉴于更新延迟应该尽可能地小、提高故障恢复的效率、避免不必要的转发浪费带宽资源,文献[57]提出在交换机之间传递简单的链路失效消息,缩短受影响交换机获悉失效的时间;同时,不引入控制器进行全网络的泛洪.然而,这种方法存在可扩展性上的限制.

文献[58]中提出使用BFD(双向转发探测协议)算法进行链路和路径故障的发现.BFD算法使用控制和回复消息监视链路的状态,为每个链路建立BFD会话,从而降低探测消息的复杂度(每条链路单个会话),同时降低故障发现的间隔(使用缩减的会话RTT).实验结果表明,当选择的BFD传输间隔为15ms时,方案可获得的平均故障恢复时间为42.1ms;当传输间隔降低为1ms时,恢复延迟降低到3.4ms,达到电信级别网络50ms的要求.

(2) 降低访问控制器开销

SDN将网络的控制逻辑集中到控制层,提供灵活的全局视图和动态配置能力.然而,网络事件的处理需要控制器频繁的介入,增加处理延迟,对于延迟敏感的故障管理影响明显.如何将故障管理的逻辑下移至数据层,成为有效进行网络故障管理的关键.

文献[58]中将BFD算法逻辑加入到OpenFlow(版本1.1)提供的组表功能中,一个组表对应一系列转发动作.基于组表可以有效地进行故障恢复:首先,将主路径及故障恢复路径合并到一个组表中;然后增加一个默认规 则——在没有合适的备选路径情况下,将流从进入端口回溯至上游交换机.这个动作将一直迭代,直至当前交换机具备有效备选路径.在运行过程中,交换机中的BFD组件负责监视与其对应链路的存活状态,控制故障恢复组表选择合适的动作(转发或回溯).所有动作的配置由控制器预先定义,发生链路或节点故障之后,数据层内部进行流的重路由或回溯到上游节点,无需额外的控制器访问.

类似地,文献[59]也提出使用组表进行故障恢复规则的管理,同时指出,通过预先将备选路径规则安装至交换机增加存储开销.文中创新地提出将多个转发端口相同的备选路径对应的规则进行合并,使用通配符形成一个规则以减小存储压力.

文献[59]中提出在数据层中利用OpenState进行包级别的事件响应,在发生链路失效之后,快速地将流重定向到可用的路径上.OpenState扩展对OpenFlow数据层的抽象,其中,交换机可以根据状态进行流规则的匹配,状态由状态机根据包级别事件的触发而转化.基于OpenState的故障管理流程为:当下行链路上的交换机节点探测到链路失效后,对缓冲中的数据包加标志,并将其转发至上行链路的节点;具有标志的数据包流到达可以重路由的节点Nr之后,触发该交换机的状态转换,进一步将流通过预计算安装的迂回路径进行转发;Nr对后续到达的流加标志,并使用迂回路径转发;标志的流通过合并交换机Nm重新回到主路径之后,标志会被去掉.通过状态转化指导转发规则,方案降低频繁访问远程控制器的开销.

(3) 应用中故障管理逻辑的解耦

文献[59]中指出,SDN中使用控制器进行故障恢复策略的集中制定,而对于当今的主流控制器(POX,Floodlight等),所有运行在其上的控制器应用中都需要包含单独的故障处理逻辑,增加程序代码编写的难度和潜在的错误数目.针对以上问题,文中提出,当AFRO运行时系统进行故障的自动恢复,以简化应用程序的设计和编写.AFRO提供两种运行模式:记录模式和恢复模式.

· 网络正常运行时系统处于记录模式,对所有PacketIn消息进行记录,并通过保存FlowMod和FlowRem信息记录所有安装的规则.

· 当探测到故障时,系统切换至恢复模式.该模式包含两个步骤:a) 系统模拟故障发生之后的网络拓扑,并将记录模式下保存的故障发生之前的消息作为输入反馈至模拟的系统,重放得到正确的转发逻辑; b) 系统将当前故障网络的状态迁移至正确的网络状态,分别将不一致的规则安装至交换机中,并对控制器的状态进行转化.

通过以上过程,AFRO成功地将故障恢复逻辑从应用程序中解耦,并保证故障管理的正确性.

4.2 控制层故障恢复

分布式的结构为容错性提供了良好的基础,而SDN将控制功能从传统网络中抽象出来形成一个集中化的层次,带来网络维护的收益,同时也潜在地增大了故障的影响.所以,为了保证控制层的可靠性,必须有效地解决控制器单点故障的问题.最直观、有效的解决方法就是进行双控制器备份[60].备份控制器可以在主控制器故障之后继续提供服务.在SDN中,实现双控制器备份主要需要解决控制器之间的同步与部署两个方面的问题.

(1) 双控制器之间的同步

OpenFlow提供设置配置多个备份控制器的机制,但没有提供任何协同机制,所以需要协同机制保持主控制器和备份控制器之间的一致性,降低切换的代价[61].

针对主、备份控制器之间的同步操作,文献[61]设计了CPRecovery组件,用于支持双控制器备份机制,CPRecovery可以独立地运行在多个网络操作系统之上,具有较好的可扩展性.文中设计的备份机制包括两个运行阶段——复制阶段和恢复阶段,分别对应主控制器正常和故障两种情形.

1) 复制阶段.系统运行于复制阶段时,主控制器负责处理来自数据层的控制请求,如果控制器维护的流表中不包含对应流的表项,则需要计算一个新的流表项,并通过CPRecovery发送消息将其同步到备份控制器,同时,使用消息确认机制确保同步成功.如果控制请求发送到备份控制器,那么CPRecovery会将备份控制器标识为主控制器.

2) 恢复阶段.NOX的处理故障以及控制与交换机的链路失效都会触发系统进入恢复阶段,其中,链路的失效是通过交换机周期性地发送控制器探测报文来捕获的,如果控制器在一定时间内未对探测报文进行响应,则认为当前的主控制器无法连接.当处于恢复阶段时,交换机向备份控制器发起请求,备份控制器的状态转化为主控制器,接管网络并不断地尝试与原控制器通信.该方案的缺点在于增加控制器响应交换机请求的延迟,因为需要确保同步操作的完成.

(2) 备份控制器的部署

备份控制器部署围绕的研究问题为:在引入尽可能小的维护开销和同步延迟的条件下,实际在何处部署、部署多少备份控制器可以保证足够的可靠性[62].具体来说,应该明确控制器数目对可靠性的影响以及可靠性与加入备份引入的延迟之间如何权衡.

文献[62]对控制器的部署位置问题进行了讨论,文中假设控制器与数据层之间通过in-band的形式进行交互,即控制路径是基于交换机之间的物理链路.部署位置问题可以形式化为:针对于一个网络拓扑G=〈E,V〉(其中,V表示交换机节点,E表示节点间的链路),设备和链路的失效概率相同,如果有K个控制器,那么在|V|个可选的位置中应如何进行放置,以最大化总体的可靠性,即降低控制链路失效的比率.文中提出了随机放置、模拟退火和贪婪法等算法对问题进行求解,通过实验分析指出,模拟退火算法可以输出可靠性最高的部署方案.

文献[62, 63]中详细分析了控制器部署的数目对延迟和可靠性的影响,即两者之间的相互权衡.通过在OS2E和Rocketful拓扑上的实验分析,文献[62]指出:增加控制器的数目可以分摊控制请求的压力,降低控制请求的响应延迟,但却由于在控制层与数据层之间引入更多的通信链路而造成链路失效概率的上升,降低总体的可靠性.另一方面,文献[63]提出一种(3+1)的控制器配置方案,即3个用于负载均衡的主控制器配合1个备份控制器提供控制层功能.文中通过实验指出,10ms的控制器延迟可以满足具有8~200个节点的网络.并且提出,一个合适的控制器数目应该位于区间[0.035n,0.117n]之间,其中,n是网络节点的个数.

5 总结与展望 5.1 总 结

SDN具有集中控制、控制管理分离以及开放接口等特点,为有效地网络管理、网络负载均衡和安全分析工作提供基础支持.在此基础上,流量工程技术能够充分利用SDN的特性,更好地发挥SDN在应用层面的优势.

开展流量工程的目标是利用实时、动态的网络信息对网络进行监控、维护和管理.总结来看,SDN中流量工程的研究主要包括以下3个方面:

1) 流量的动态测量分析、准确的测量,是流量工程相关服务的基础.

流量测量的主要工作为收集流量统计信息,分析网络流量的特征,发现特殊流量(如elephant流)和不合理的配置.文献[15, 18, 19]以采样或计数器的方式统计流量信息,使用控制器主动询问或被动接收的方式收集交换机中存储的统计结果,各种方法围绕测量开销和准确性展开权衡.文献[24, 25, 26, 64, 65]提出了若干网络正确态进行检查的方案,对规则配置进行静态或动态的监控和评估,以避免循环路由等问题的产生.此外,测量的过程应合理地利用有限的网络资源,交换机的片上空间有限,流表的存储单元(TCAM)成本高且数目少,应当在保证测量正确性的基础上尽量减少TCAM的占用.文献[27, 28, 29]的设计方法研究如何在保证测量准确性的基础上降低硬件资源的开销.

2) 流量的管理调度,是流量工程提高网络性能的一个重要途径.

管理的目标是实现网络路径或者服务器之间的负载均衡,提高链路利用率,增加网络的总吞吐量(或对等带宽)和提供QoS保证.数据中心的流量具有突发和动态的特点,合理调度大数据量流量,可以明显改善网络的性能.文献[31, 34, 35, 36]在交换机或端服务器中设置阈值检测elephant流,进而结合网络状态,利用集中控制器为elephant流计算并更新转发策略.利用SDN集中的流量管理能力,可以为业务流提供QoS保证.文献[37, 38, 39]在制定转发策略时考虑QoS需求,从而设计了面向QoS的实时业务流调度算法.另一方面,采用分布式或层次化的控制器结构,可以缓解SDN中控制请求和信息汇总的瓶颈问题.文献[44, 46, 47, 48]提出了在控制器架构基础上设计控制流量的管理方法,多个控制器采取就近、集中调度、层次化响应等策略对控制请求流量进行管理和调度.最后,将流量虚拟化为多个分片,可以支持应用对流量的灵活管理.文献[49, 50]采用完全分离和组合的方式对操作分片之后的网络流量进行调度管理.

3) 网络中错误及故障的恢复,用于保证SDN可用性和可靠性.

软件和硬件问题导致的故障是不可避免的,针对数据层的设备或链路出现的故障,可以采用传统的预留或非预留两类恢复机制保证网络在未受影响的路径和设备上继续运作[53, 54, 55].在此基础上,利用包括BFD在内的数据层技术降低恢复的延迟,利用组表等技术缓解集中控制器在恢复过程中引入的开销[58, 59, 66].另一方面,使用备份控制器可以应对集中控制器单点故障,利用交换机与控制器间的心跳消息发现故障,从而切换主、备份控制器角色,是进行控制器间有效同步协作的一种可选方案.文献[62, 63]对多控制器结构的部署以及可靠性和延迟之间的权衡进行了讨论.

5.2 展 望

作为一种新兴的网络架构,SDN是当前网络领域最具发展前景的技术之一,备受业界和研究界的关注[67, 68].在网络顶级会议SIGCOMM关于SDN的workshop——HotSDN中,涉及流量管理、流量测量、资源调度、状态更新等流量工程技术的文章比例的一个粗略统计见表3.

Table 3 Statics for traffic engineering related papers in HotSDN表3 HotSDN中流量工程文章统计

围绕SDN的流量工程的研究项目也有许多,如Google开展的B4[69]、Microsoft提出的SWAN架构[67]以及华为技术有限公司提出的ADMCF-SNOS系统[68]等.以B4为例,SDN被用来改造Google数据中心之间互联的G-Scale网络.该网络的链路成本很高,链路的利用率却只有30%左右.B4采用有效的流量管理方法实现链路的负载均衡,增加网络稳定性和简化网络管理,经过改造的大部分链路的利用率可以达到100%.

最后,基于SDN的流量工程在以下几个方面有待进一步改进或深入研究.

(1) 快速且资源节约的故障恢复

在针对数据层的可靠性维护机制中,采用路径预留法进行故障恢复可以保证短延迟和控制器与路由器之间通信的低开销.然而,将备份路径转发规则提前保存在数据层的交换机中会增加存储资源的开销;同时,预留方法属于静态范畴,转发路径是提前计算的,缺乏对动态网络状态的适应性,而对规则的动态更新还需要额外的操作对备份规则进行相同的更新.因此,如何进一步优化故障恢复方法,以保证在快速的前提下有效利用交换机中的存储资源,并通过引入尽可能少的控制-数据层交互开销,进行预定义备份规则的动态更新,值得深入研究.

(2) 多控制器结构

控制器是SDN的核心,集中化的设计在可扩展性、可靠性和处理能力上限制了网络的总体能力.采用多控制器结构可以缓解集中控制器的瓶颈问题,然而,究竟需要部署多少控制器,控制器之间如何协同分工,仍是需要进一步探究的问题.另一方面,SDN的北向接口上“百花齐放”,为了满足自身应用和利益需求,不同生产商提供自己的商业或开源控制器,如何维护和协调多种控制器共存的场景,使得同一控制域中控制器能够正确同步、而不同控制域之间的控制信息能够有效交互,需要进一步加以探讨.文献[70]提出:通过观察控制请求总量维护一个弹性的控制器池,并将控制请求无缝地在多个控制器间迁移,通过协调分工实现负载均衡.这是一种可以借鉴的思路,但仍有待更多的深入研究.

(3) 流量调度对传输协议效率的影响

开展对网络流量的有效调度,尤其是对elephant流而言,可以实现网络路径间负载的均衡,提高网络总体吞吐量.数据中心中TCP流量占主要成分,而流量的多路径传输会导致目标服务器处出现数据包的乱序到达.TCP协议会根据滑动窗口协议限制发送端的窗口,进而影响发送端的数据吞吐率.所以,流量调度对传输协议效率的影响值得深入的分析和研究.

(4) 基于测量的软件定义安全

网络流量的测量以及网络正确状态的检查工作应该与安全问题充分结合.SDN采用的集中控制为安全策略的制定和部署提供良好支持,克服传统分布式网络结构的动态、不可控性对维护一个安全网络的影响.传统的安全问题在SDN中仍然存在,如以消耗网络带宽和处理能力为目标的Dos和DDos攻击.现有的静态阈值流量测量方式缺乏灵活性,限制了进一步分析发现异常流量的能力.基于SDN的流量测量的过程是测量和分析的回环控制形式,测量为分析提供统计数据,分析结合网络拓扑和实时采集的网络参数信息动态地对测量的配置进行修改.这种自适应的方式可以更有效地应对复杂的网络环境,更快速地发现网络中的流量、拓扑异常,并从全局的角度制定安全措施.另一方面,OpenFlow提供的可编程能力为不同需求的服务自定义网络安全策略提供充分、灵活的支持.所以,利用SDN提供的细粒度、实时测量结果指导安全应用,实现软件定义安全,是一个有意义的研究课题.同时,SDN集中控制的结构使得控制器成为安全的薄弱环节,在实际部署中,如何通过测量分析对异常请求流量的模式进行有效的甄别,也具有重要的实际意义.

(5) 基于SDN的新型网络中的流量工程

SDN所具有的将数据转发与控制逻辑分离的特性,可以促进网络技术的创新和新型网络的发展.例如,用户中心网络(user-provided network,简称UPN)是一种依赖于用户之间共享可用的网络接入资源提升无线接入能力的新兴网络架构,文献[71]提出使用将SDN架构与UPN结合,利用SDN集中控制的优势实现对底层终端-终端、终端-接入点(无线AP或基站)之间转发路径可用性、利用率情况的监测,并基于实时的测量信息指导应用流量的转发.在以上过程中,有效地利用流量工程技术,可以对数据流量进行合理、动态的调度.包括D2D、移动群感知在内的新型网络中,都存在将控制和转发逻辑解耦,通过集中网络视图制定决策,实现数据流合理调度的需求.所以,如何在基于SDN框架的新型网络中开展有效的流量工程,对于发挥SDN优势、驱动技术发展十分重要.

参考文献
[1] Zhang CK, Cui Y, Tang HY, Wu JP. State-of-the-Art survey on software-defined networking (SDN). Ruan Jian Xue Bao/Journal of Software, 2015,26(1):62-81 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/4701.htm .[doi: 10.13328/j.cnki.jos.004701]
[2] Open networking summit 2012. 2012. http://opennetsummit.org/archives/apr12/site/why.html
[3] McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J. OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 2008,38(2):69-74. [doi: 10.1145/1355734.1355746]
[4] Awduche D, Chiu A, Elwalid A, Widjaja I, Xiao XP. Overview and Principles of Internet Traffic Engineering. IETF RFC 3272, 2002.
[5] Akyildiz IF, Lee A, Wang P, Chou W. A roadmap for traffic engineering in software defined networks. Computer Network, 2014, 71(2):1-30. .[doi: 10.1016/j.comnet.2014.06.002]
[6] Bae JJ, Suda T. Survey of traffic control schemes and protocols in atm networks. Proc. of the IEEE, 1991,79(2):170-189. [doi: 10. 1109/5.64405]
[7] Wang N, Ho K, Pavlou G, Howarth M. An overview of routing optimization for internet traffic engineering. 4483669]IEEE Communications Surveys & Tutorials, 2008,10(1):36-56. [doi: 10.1109/COMST.2008.
[8] Awduche DO, Agogbua J. Requirements for Traffic Engineering over MPLS. RFC 2702, 1999.
[9] Zuo QY, Chen M, Zhao GS, Xing CY, Zhang GM, Jiang PC. 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 .[doi: 10.3724/SP.J. 1001.2013.04390]
[10] Bi J. SDN architecture and future network architecture innovation environment. Telecommunications Science, 2013,29(8):6-15 (in Chinese with English abstract). .[doi: 10.3969/j.issn.1000-0801.2013.08.002]
[11] The Openflow Switch. 2014. http://www.opennetworking.org
[12] NetFlow. 2004. http://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html
[13] sflow. 2004. http://www.sflow.org/sFlowOverview.pdf
[14] Myers AC. Jflow: Practical mostly-static information flow control. In: Proc. of the 26th ACM SIGPLAN-SIGACT Symp. on Principles of Programming Languages. ACM Press, 1999. 228-241. .[doi: 10.1145/292540.292561]
[15] Tootoonchian A, Ghobadi M, Ganjali Y. OpenTM: Traffic matrix estimator for openflow networks. In: Proc. of the Passive and Active Measurement. Berlin Heidelberg: Springer-Verlag, 2010. 201-210. .[doi: 10.1007/978-3-642-12334-4_21]
[16] Chowdhury SR, Bari MF, Ahmed R, Boutaba R. PayLess: A low cost network monitoring framework for software defined networks. In: Proc. of the IEEE Network Operations & Management Symp. Washington: IEEE Computer Society Press, 2014. 1-9. .[doi: 10. 1109/NOMS.2014.6838227]
[17] Yu C, Lumezanu C, Zhang Y, Singh V, Jiang G, Madhyastha HV. Flowsense: Monitoring network utilization with zero measurement cost. In: Proc. of the Passive and Active Measurement. Berlin Heidelberg: Springer-Verlag, 2013. 31-41. .[doi: 10. 1007/978-3-642-36516-4_4]
[18] Benson T, Anand A, Akella A, Zhang M. Microte: Fine grained traffic engineering for data centers. In: Proc. of the 7th Conf. on Emerging Networking Experiments and Technologies. New York: ACM Press, 2011. 8-29. .[doi: 10.1145/2079296.207 9304]
[19] Suh J, Kwon T, Dixon C, Felter W, Carter J. Opensample: A low-latency, sampling-based measurement platform for SDN. In: Proc. of the IEEE Int'l Conf. on Distributed Computing Systems. Washington: IEEE Computer Society Press, 2014. 228-237. .[doi: 10. 1109/ICDCS.2014.31]
[20] Benson T, Akella A, Maltz D. Network traffic characteristics of data centers in thewild. In: Proc. of the IMC. New York: ACM Press, 2010. 267-280. .[doi: 10.1145/1879141.1879175]
[21] Alizadeh M, Greenberg A, Maltz DA, Padhye J, Patel P, Prabhakar B, Sengupta S, Sridharan M. Data center TCP (DCTCP). In: Proc. of the SIGCOMM. New York: ACM Press, 2010. 63-74. .[doi: 10.1145/1851182.1851192]
[22] van Adrichem NLM, Doerr C, Kuipers FA. Opennetmon: Network monitoring in openflow software-defined networks. In: Proc. of the 2014 IEEE Network Operations and Management Symp. (NOMS). Washington: IEEE Computer Society Press, 2014. 1-8. .[doi: 10.1109/NOMS.2014.6838228]
[23] Yu M, Jose L, Miao R. Software defined traffic measurement with opensketch. In: Proc. of the 10th USENIX Symp. on Net-Worked Systems Design and Implementation (NSDI 2013). Berkeley: USENIX, 2013.29-42.
[24] Canini M, Venzano D, Peresini P, Kostic D, Rexford J. A nice way to test openflow applications. In: Proc. of the NSDI. Berkeley: USENIX, 2012. 127-140.
[25] Mai H, Khurshid A, Agarwal R, Caesar M, Godfrey P, King ST. Debugging the data plane with anteater. ACM SIGCOMM Computer Communication Review, 2011,41(4):290-301. [doi: 10.1145/2043164.2018470]
[26] Khurshid A, Zhou W, Caesar M, Godfrey P. Veriflow: Verifying network-wide invariants in real time. ACM SIGCOMM Computer Communication Review, 2012,42(4):467-472. [doi: 10.1145/2377677.2377766]
[27] Moshref M, Yu M, Govindan R, Vahdat A. DREAM: Dynamic resource allocation for software-defined measurement. In: Proc. of the SIGCOMM. New York: ACM Press, 2014. 419-430. .[doi: 10.1145/2619239.2626291]
[28] Mogul JC, Congdon P. Hey, you darned counters! Get off my ASIC! In: Proc. of the 1st Workshop on Hot Topics in Software Defined Networks. New York: ACM Press, 2012. 25-30. .[doi: 10.1145/2342441.2342447]
[29] Zhao T, Li T, Han B, Sun Z, Huang J. Design of software defined hardware counters for SDN. In: Proc. of the 20th Int'l Workshop on Local & Metropolitan Area Networks (LANMAN). Washington: IEEE Computer Society Press, 2014. 1-6. .[doi: 10.1109/LAN MAN.2014.7028635]
[30] Hopps CE. Analysis of an equal-cost multi-path algorithm. 2000.http://tools.ietf.org/html/rfc2992
[31] Al-Fares M, Radhakrishnan S, Raghavan B, Huang N, Vahdat A. Hedera: Dynamic flow scheduling for data center networks. In: Proc. of the NSDI, Vol.10. Berkeley: USENIX, 2010.19-33.
[32] Dixit AA, Prakash P, Hu YC, Kompella RR. On the impact of packet spraying in data center networks. In: Proc. of the IEEE INFOCOM. Washington: IEEE Computer Society Press, 2013. 2130-2138. .[doi: 10.1109/INFCOM.2013.6567015]
[33] Chiesa M, Kindler G, Schapira M. Traffic engineering with equal-cost-multipath: An algorithmic perspective. In: Proc. of the IEEE INFOCOM. Washington: IEEE Computer Society Press, 2014. 1590-1598. .[doi: 10.1109/INFOCOM.2014.6848095]
[34] Curtis AR, Kim W, Yalagandula P. Mahout: Low-Overhead datacenter traffic management using end-host-based elephant detection. In: Proc. of the 2011 IEEE INFOCOM. Washington: IEEE Computer Society Press, 2011. 1629-1637. .[doi: 10.1109/INFCOM. 2011.5934956]
[35] Curtis AR, Mogul JC, Tourrilhes J, Yalagandula P, Sharma P, Banerjee S. Devoflow: Scaling flow management for high-performance networks. ACM SIGCOMM Computer Communication Review, 2011,41(4):254-265. [doi: 10.1145/2043164.20184 66]
[36] Yu M, Rexford J, Freedman MJ, Wang J. Scalable flow-based networking with difane. ACM SIGCOMM Computer Communication Review, 2011,41(4):351-362. .[doi: 10.1145/1851182.1851224]
[37] Ongaro F, Cerqueira E, Foschini L, Corradi A, Gerla M. Enhancing the quality level support for real-time multimedia applications in software-defined networks. In: Proc. of the 2015 Int'l Conf. on Computing, Networking and Communications (ICNC). Washington: IEEE Computer Society Press, 2015. 505-509. .[doi: 10.1109/ICCNC.2015.7069395]
[38] Egilmez HE, Dane ST, Bagci KT, Tekalp AM. OpenQoS: An OpenFlow controller design for multimedia delivery with end-to-end quality of service over software-defined networks. In: Proc. of the Signal & Information Processing Association Annual Summit and Conf. (APSIPA ASC). Washington: IEEE Computer Society Press, 2012.1-8.
[39] Ongaro F, Corradi A, Gerla M, Cerqueira E, Foschini L. Enhancing quality of service in software-defined networks [MS. Thesis]. Bologna: UNIBO, 2014.
[40] Long H, Shen Y, Guo M, Tang F. LABERIO: Dynamic load-balanced routing in OpenFlow-enabled networks. In: Proc. of the 27th Int'l Conf. on Advanced Information Networking and Applications (AINA). Washington: IEEE Computer Society Press, 2013. 290-297. .[doi: 10.1109/AINA.2013.7]
[41] Li J, Chang X, Ren Y, Zhang Z, Wang G. An effective path load balancing mechanism based on SDN. In: Proc. of the 13th Int'l Conf. on Trust, Security and Privacy in Computing and Communications (TrustCom). Washington: IEEE Computer Society Press, 2014. 527-533. .[doi: 10.110 9/TrustCom.2014.67]
[42] Handigol N, Seetharaman S, Flajslik M, McKeown N, Johari R. Plug-n-Serve: Load-Balancing Web traffic using OpenFlow. In: Proc. of the Demo at ACM SIGCOMM. Barcelona: ACM Press, 2009.
[43] Wang R, Butnariu D, Rexford J. OpenFlow-Based server load balancing gone wild. In: Proc. of the Workshop on Hot-ICE. Washington: IEEE Computer Society Press, 2011.12-18.
[44] Tootoonchian A, Ganjali Y. Hyperflow: A distributed control plane for openflow. In: Proc. of the 2010 Internet Network Man-Agement Conf. on Research on Enterprise Networking. San Jose: USENIX Association, 2010.
[45] Tavakoli A, Casado M, Koponen T, Shenker S. Applying nox to the datacenter. In: Proc. of the HotNets. New York: ACM Press, 2009.
[46] Koponen T, Casado M, Gude N, Stribling 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 OSDI, Vol.10. Vancouver: USENIX Association, 2010.1-6.
[47] Hu Y, Wang W, Gong X, Que X, Cheng S. Balanceflow: Con-Troller load balancing for openflow networks. In: Proc. of the 2nd Int'l Conf. on Cloud Computing and Intelligent Systems (CCIS), Vol.2. Washington: IEEE Computer Society Press, 2012. 780-785. .[doi: 10.1109/CCIS.2012.6664282]
[48] Yeganeh SH, Ganjali Y. Kandoo: A framework for efficient and scalable offloading of control applications. In: Proc. of the 1st Workshop on Hot topics in Software Defined Networks. New York: ACM Press, 2012. 19-24. .[doi: 10.1145/2342441.2342446]
[49] Sherwood R, Gibb G, Yap KK, Appenzeller G, Casado M, McKeown N, Parulkar G. Can the production network be the testbed? In: Proc. of the 9th USENIX Conf. on Operating Systems Design and Implementation (OSDI). Vancouver: USENIX Association, 2010.
[50] Jin X, Rexford J, Walker D. Incremental update for a compositional SDN hypervisor. In: Proc. of the 3rd Workshop on Hot Topics in Software Defined Networking. New York: ACM Press, 2014. 187-192. .[doi: 10.1145/2620728.2620731]
[51] Vasseur JP, Pickavet M, Demeester P. Network Recovery: Protection and Restoration of Optical, SONET-SDH, IP and MPLS. Elsevier, 2004.
[52] Niven-Jenkins B, Brungard D, Betts M, Spreche N. Requirements of an MPLS Transport Profile. RFC 5654, 2009.
[53] Sharma S, Staessens D, Colle D, Pickavet M, Demeester P. Enabling fast failure recovery in OpenFlow networks. In: Proc. of the 8th Int'l Workshop on the Design of Reliable Communication Networks (DRCN). Washington: IEEE Computer Society Press, 2011. 164-171. .[doi: 10.1109/DRCN. 2011.6076899]
[54] Staessens D, Sharma S, Colle D, Pickavet M, Demeester P. Software defined networking: Meeting carrier grade requirements. In: Proc. of the 18th IEEE Workshop on Local & Metropolitan Area Networks (LANMAN). Washington: IEEE Computer Society Press, 2011. 1-6. .[doi: 10.1109/LAN MAN.2011.6076935]
[55] Sharma S, Staessens D, Colle D, Pickavet M, Demeester P. Openflow: Meeting carrier-grade recovery requirements. In: Proc. of the Computer Communications. Elsevier, 2012. 656-665. .[doi: 10.1016/j.comcom.2012.09.011]
[56] Sgambelluri A, Giorgetti A, Cugini F, Paolucci F, Castoldi P. Openflow-Based segment protection in ethernet networks. IEEE/OSA Journal of Optical Communications and Networking, 2013,5(9):1066-1075. [doi: 10.1364/JOCN.5.001066]
[57] Desai M, Nandagopal T. Coping with link failures in centralized control plane architectures. In: Proc. of the 2nd Int'l Conf. on Communication Systems and Networks (COMSNETS). Washington: IEEE Computer Society Press, 2010. 1-10. .[doi: 10.1109/ COMSNETS.2010.5431977]
[58] Van Adrichem NLM, Van Asten BJ, Kuipers F. Fast recovery in software-defined networks. In: Proc. of the 3rd European Workshop on Software Defined Networks (EWSDN). Washington: IEEE Computer Society Press, 2014. 61-66. .[doi: 10.1109/EWSDN.2014.13]
[59] Capone A, Cascone C, Nguyen AQT, Sansò B. Detour planning for fast and reliable failure recovery in SDN with OpenState. arXiv: 1411.7711, 2014. .[doi: 10.1109/DRCN.2015.7148981]
[60] Budhiraja N, Marzullo K, Schneider FB, Toueg S. The primary-backup approach. Distributed Systems, 1993,2:199-216.
[61] Fonseca P, Bennesby R, Mota E, Passito A. A replication component for resilient openflow-based networking. In: Proc. of the Network Operations and Management Symp. (NOMS). Washington: IEEE Computer Society Press, 2012. 933-939. .[doi: 10.1109/ NOMS.2012.6212011]
[62] Hu YN, Wang WD, Gong XY, Que XR, Cheng SD. Reliability-Aware controller placement for software-defined networks. In: Proc. of the 2013 IFIP/IEEE Int'l Symp. on Integrated Network Management (IM 2013). Washington: IEEE Computer Society Press, 2013.672-675.
[63] Heller B, Sherwood R, McKeown N. The controller placement problem. In: Proc. of the 1st Workshop on Hot Topics in Software Defined Networks. New York: ACM Press, 2012. 7-12. .[doi: 10.1145/2342441.2342444]
[64] Al-Shaer E, Al-Haj S. Flowchecker: Configuration analysis and verification of federated openflow infrastructures. In: Proc. of the 3rd ACM Workshop on Assurable and Usable Security Configuration. New York: ACM Press, 2010. 37-44. .[doi: 10.1145/1866898. 1866905]
[65] Al-Shaer E, Alsaleh MN. ConfigChecker: A tool for comprehensive security configuration analytics. In: Proc. of the 4th Symp. on Configuration Analytics and Automation (SAFECONFIG). Washington: IEEE Computer Society Press, 2011. 1-2. .[doi: 10.1109/SafeConfig.2011.6111667]
[66] Thorat P, Raza SM, Nguyen DT, Im G, Choo H, Kim DS. Optimized self-healing framework for software defined networks. In: Proc. of the 9th Int'l Conf. on Ubiquitous Information Management and Communication. New York: ACM Press, 2015. 1-6. .[doi: 10.1145/27011 26.2701235]
[67] 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 SIGCOMM. New York: ACM Press, 2013. 15-26. .[doi: 10.1145/2486001.2486012]
[68] Luo M, Zeng Y, Li J. An adaptive multi-path computation framework for centrally controlled networks. In: Proc. of the Computer Networks. Elsevier, 2015. 30–44. .[doi: 10.1016/j.comnet.2015.02.004]
[69] Jain S, Kumar A, Mandal S, Ong J, Poutievski L, Singh A, Venkata S, Wanderer J, Zhou J, Zhu M, Zolla J, Hölzle U, Stuart S, Vahdat A. B4: Experience with a globally-deployed software defined WAN. ACM SIGCOMM Computer Communication Review, 2013,43(4):3-14. .[doi: 10.1145/2534169.2486019]
[70] Dixit A, Hao F, Mukherjee S, Lakshman TV, Kompella R. Towards an elastic distributed SDN controller. ACM SIGCOMM Computer Communication Review, 2013,43(4):7-12. .[doi: 10.1145/2534169.2491193]
[71] Syrivelis D, Iosifidis G, Delimbasis D, Chounos K, Korakis T, Tassiulas L. Bits and coins: Supporting collaborative consumption of mobile Internet. In: Proc. of the IEEE INFOCOM. Washington: IEEE Computer Society Press, 2015. .[doi: 10.1109/INFOCOM. 2015.7218600]
[72] 张朝昆,崔勇,唐翯祎,吴建平.软件定义网络(SDN)研究进展.软件学报,2015,26(1):62−81.http://www.jos.org.cn/1000-9825/4701.htm [doi: 10.13328/j.cnki.jos.004701]
[73] 左青云,陈鸣,赵广松,邢长友,张国敏,蒋培成.基于OpenFlow 的SDN 技术.软件学报,2013,24(5):1078−1097. http://www.jos.org.cn/1000-9825/4390.htm .[doi: 10.3724/SP.J.1001.2013.04390]
[74] 毕军.SDN 体系结构与未来网络体系结构创新环境.电信科学,2013,29(8):6−15. .[doi: 10.3969/j.issn.1000-0801.2013.08.002]