论文投稿_医学论文投稿_核心期刊,职称论文投稿发表_论文部落

　　(4)运作模式和演进趋势问题.SDN技术颠覆了网络设备的设计理念,带来了新的市场需求,同时也对传统的网络设备制造商提出了挑战.同时,OpenFlow自身设计标准的不稳定性和转发设备硬件的复杂化趋势也为OpenFlow的演进趋势带来了不确定性.

　　根据上面提到的这些技术问题和需求,下面分别就当前的热点难点问题和相关的研究思路进行总结.

　　3.1SDN转发平面的设计问题

　　OpenFlow交换机作为目前SDN转发平面的实现方式,已被广为接受.由于OpenFlow交换机采用流表结构处理数据分组,因此特定的应用有可能导致交换机流表迅速膨胀,从而影响OpenFlow交换机的性能.从目前实际部署来看,基于NetFPGA的OpenFlow交换机在性能上可以满足校园内的流量需求,但在实现上,当通配符查询耗尽NetFPGA硬件资源后,OpenFlow交换机将以线性查找的软件方式对流表进行匹配查找.这种方式在网络规模增大、细粒度流表需求增加的网络环境下将产生性能瓶颈.

　　这样的性能瓶颈同样会发生在商用硬件OpenFlow交换机上,其主要原因在于OpenFlow转发抽象对实际硬件资源的过度消耗.2008年,OpenFlow规约0.8.9版只支持最初的十元组,随后几年中,0.9版增加了VLAN优先级,1.0版增加了IP服务类型,1.1版增加了元数据(metadata)、MPLS标签和MPLS流量类别这3个字段,1.2版和1.3版则列出了需要实现的13个字段和可选实现的众多字段,前13个字段里包含IPv6字段.可以看出,为了实现功能的扩展,流表项的匹配长度一直在增加.路由器通常利用TCAM来检索路由器转发表,从而获得下一跳地址.传统的转发表匹配字段长度一般以IPv4的32位为主,而OpenFlow规约1.0版里的十二元组长度为250比特左右,OpenFlow1.1版里则长达356比特.在增加了IPv6之后,流表项将更长.这种不断扩充的转发平面抽象,将极大地增加硬件成本.OpenFlow1.1版提出了多级流表和流水线结构,通过分域多级流表查询来压缩流表空间,在一定程度上减少OpenFlow交换机中TCAM资源的消耗,从而给报文的匹配操作增加了足够的灵活性.但需要看到,实际的流表硬件资源开销将与具体的流表设计有关,需要根据实际的转发需求设计跳转算法,优化内部流表查找过程.这超出了传统交换芯片的数据转发处理过程,将导致匹配时延的增加,也将增加OpenFlow交换机硬件设计的复杂度.

　　另一方面,控制平面需要知晓每个OpenFlow交换机的流水线结构,这需要控制平面进行相应的协议扩展.

　　然而,OpenFlow规约标准还在不断更新,更多的扩展功能将添加到OpenFlow标准当中.由于目前尚没有一个成熟统一的标准发布,这也导致不同版本OpenFlow交换机的流表结构不尽相同.随着不同版本的OpenFlow交换机逐渐投入使用,控制平面需要维护异构的OpenFlow交换机流表结构,这无疑将增加控制平面的维护成本和复杂性.这也是未来OpenFlow交换机设计需要考虑的问题.

　　3.2控制平面的可扩展性

　　制约SDN控制平面可扩展性的主要原因有以下几点:

　　(1)流的细粒度处理需求使得控制器需要响应更多的流请求事件.虽然控制器可以通过主动决策机制提前将控制逻辑部署到数据转发单元,减少数据平面和控制器之间的处理开销,但控制逻辑的变化通常是动态的,尤其是当网络拓扑改变或者存在移动结点时.在OpenFlow网络中,提前安装流表项也将使大量流表空间无法释放,浪费资源,而实际上大部分流的持续时间是很短的.

　　(2)接入控制、负载均衡、资源迁移等新型应用需求逐渐增加到控制平面当中,控制器需要对日趋复杂的管控功能进行有效的整合,这进一步增加了控制平面的处理开销.

　　(3)传统分布式网络设备仅根据局部的路由信息来实现路由转发,而控制平面需要维护全局的网络状态信息,这也使得控制平面的可扩展性不仅需要考虑性能的需求,而且要考虑网络状态的一致性.

　　(4)在网络规模增大、数据平面转发设备数量增多的环境下,单控制器设备可能难以满足性能需求.

　　OpenFlow最初的研究出发点是面向校园网或企业网的创新需求,但随着基于OpenFlow的SDN应用范围逐渐扩大,控制平面的可扩展性已经成为当前研究热点,下面分别介绍当前针对控制平面可扩展性的相关研究.

　　3.2.1DIFANE

　　尽管可以通过提前在OpenFlow交换机中安装流表来减小控制器负载,但真实网络通常是按需安装流表,需要控制器进行实时响应,而这无疑将增加控制器的处理开销.

　　针对当前基于流的网络对控制器依赖过重的实际场景,DIFANE结合了主动和被动两种安装流表的方式将流量保持在数据平面,从而减小控制器负载.DIFANE首先在OpenFlow交换机中选出权威交换机(authorityswitch),每个权威交换机管理一定区域内的OpenFlow交换机.控制器主动将分区规则安装到所有的OpenFlow交换机上,并根据全局网络信息主动在权威交换机上安装权威规则.当普通交换机产生新的数据流时,它根据自身的分区规则直接和自己分区内的权威交换机进行通信.由于权威交换机已提前部署了权威规则,因而可以向普通交换机安装缓存规则,同时,直接将请求数据转发给目的地而无须再返回给源交换机,从而去掉了传统流请求建立过程中数据包经过控制器的往返时延,也减少了控制器需要实时处理的控制流,如图6所示.在每个交换机内部,由于存在多种不同的规则,因此通过优先级进行先后处理.缓存规则的优先级最高,因为它直接管理数据的转发;权威交换机中的权威规则优先级次之,它控制自己域内的转发规则;分区规则优先级最低,仅在前面两种规则都不存在时才将数据包转发给域内的权威交换机.

　　在DIFANE系统中,由于权威交换机能够管理普通交换机的流建立请求,因此,控制器仅需要管理整个网络的区域划分和权威交换机的流触发规则.DIFANE的区域划分根据流空间(flowspace)定义,而流空间则根据具体的流表项来划分,一般由7个字段组成(源和目的IP地址、MAC地址、端口号,协议),形成七维流空间.二维流空间(F1,F2)为例,F1和F2分别代表源IP地址和目的IP地址,范围为0~15,即(F1=F2=[0,15]).那么,规则R2表示所有源IP地址为1、目的IP地址为0~7的数据包.控制器将整个网络划分为4个区域.具体的划分规则将根据实际区域的规则类型和范围来决定.

　　DIFANE中的分区规则和权威交换机的权威规则一般仅需在网络发生变化时进行处理,因此不需要频繁地更新,从而减轻了控制器负载.实际上,DIFANE并未完全将逻辑控制功能分配给权威交换机.它巧妙地利用流表1086JournalofSoftware软件学报Vol.24,No.5,May2013项的优先级特点来区分不同的规则,从而将实时安装流表项的开销分担给了权威交换机.然而,这种实现方式需要权威交换机具备规则安装功能,而传统的OpenFlow交换机无法实现,因此降低了实际部署过程的通用性.

　　3.2.2DevoFlow

　　Andrew等人考虑到当前的OpenFlow交换机流建立过程和统计信息收集过程将会消耗大量数据平面和控制平面之间的带宽,无法满足高性能网络的性能需求,提出了DevoFlow的设计方案.DevoFlow采取了两种方式来减小OpenFlow交换机和控制器的信息交互:规则复制和局部操作.

　　规则复制方式在包含通配符的流表项中“操作”字段上增加了CLONE标志,如果该标志清零,则匹配该流表项的报文按正常情况处理;如果该标志被置位,则直接根据匹配报文建立精确匹配的微流,从而细化每一条微流的统计信息.由于带通配符的流表项一般由硬件TCAM实现,而精确匹配的流表项由软件实现,因而同时也减少了TCAM资源的消耗.在这种方式下,OpenFlow交换机只需提前安装带有通配符的流表项,即可大量减少同控制器的报文交互,同时节省硬件资源开销.

　　局部操作方式包括多路径支持和快速重路由.多路径支持是指为OpenFlow交换机中可复制的通配符流表项提供多个可能的输出端口,DevoFlow根据概率分布将报文输出到特定端口中,而不是采用传统的等价多路径路由方式(ECMP).快速重路由给OpenFlow交换机指定了1条到多条备用路径,从而在链路失效时立即转用备用路径,而不是转发给控制器.快速重路由可通过安装不同优先级的流表来实现,但是需要在链路失败时将高优先级的流表项删除或者进行覆盖.

　　针对统计信息收集过程的开销,DevoFlow采用3种方法来提高统计信息收集效率:采样、触发和报告、近似统计.采样方法将统计信息按照一定的样本概率转发给控制器;触发和报告通过设置阈值,在统计信息满足阈值条件时将统计信息发给控制器;近似统计则只将流量最大的k条流的统计信息发给控制器.通常情况下,这k条流包含了80%~99%的数据流.

　　DevoFlow设计方案的初衷与DIFANE类似,都是为了减小数据平面和控制平面的数据交互,从而减小控制平面负载.DevoFlow考虑了流建立请求和获取统计信息的双重开销,因而直接在本地减小请求报文的数量;DIFANE则将流建立请求的开销转交给权威交换机.前者的侧重点是从源头减少开销,后者的侧重点是分担开销.然而,DevoFlow目前在硬件上尚未实际部署,其功能需要通过修改OpenFlow交换机的流表结构和硬件架构来实现,实际上增加了数据平面的部分控制功能,同样降低了实际部署过程的通用性.

　　3.2.3HyperFlow

　　通过减小控制器的处理开销,无法从根源上解决单点性能瓶颈问题.多控制器管控的分布式控制平面的设计思想是未来基于OpenFlow的SDN面向较大规模网络部署的必经之路.HyperFlow通过部署多台控制器来管理OpenFlow交换机,在每台控制器能够同步全网络视图的同时,只需要管理特定区域中的OpenFlow交换机.

　　整个OpenFlow网络仅有1台控制器,因此跨域的服务请求将产生额外的时延,同时对控制器性能造成影响;右图在每个域内都部署1台~多台控制器,控制器之间通过消息的发布-订阅模式来来传输网络事件.在HyperFlow中,每个控制器将订阅数据信道、控制信道和自身信道.域内的网络和应用程序事件将发布给数据信道,针对特定控制器的事件将分别发送给该控制器信道.另外,每台控制器必须将自身的网络状态信息定期发布给到控制信道,以利于控制器的发现和故障检测.实际上,HyperFlow是基于为广域网设计的分布式文件系统WheelFS而设计的,网络事件在不同控制器之间以文件的更新形式来实现.

　　HyperFlow通过NOX上的应用程序方式实现,因此实现过程简单,只需对NOX进行少量修改.从实现和测试的性能来看,在保证控制带宽和限定网络延迟的情况下,HyperFlow能够处理的网络事件小于1000次/秒,性能还不够高.另一方面,全网络视图的更新将与网络状态信息发布的周期时间和传输时延相关,这由WheelFS的实现机制决定.因此,这种实现方式适用于网络状态事件更新不频繁、对网络状态一致性要求不高的网络.对于网络状态事件频繁更新的网络,或者对于数据中心或较大规模网络,HyperFlow有可能面临性能瓶颈.

　　3.2.4Onix

　　针对控制平面在可扩展性、可靠性和通用性等方面的不足,Onix提出了一整套面向大规模网络的分布式SDN部署方案.Onix网络架构主要由物理网络基础设施、网络连接基础设施、Onix和网络控制逻辑这4部分组成,如图9所示.物理网络基础设施允许Onix读写网络状态;网络连接基础设施提供Onix和物理网络基础设施之间的通信连接;Onix采用分布式架构向上层控制逻辑提供网络状态的编程接口;网络控制逻辑则通过Onix提供的API来决策网络行为.网络信息库(networkinformationbase,简称NIB)用于维护网络全局的状态,Onix的设计关键就在于维护NIB的分发机制,从而保证整个网络状态信息的一致性.

　　(1)分区.和HyperFlow一样,随着网络规模的增大,数据转发平面必须由不同的控制器进行分区管理.Onix通过不同的实例管理每个域,并根据NIB来配置数据平面.

　　(2)聚合.整个Onix网络将形成一个分层的拓扑结构,每个Onix实例需要维护本分区的路由决策,分区间的路由决策则由Onix实例构成的集群共同决策.在网络规模增大、网络事件更新频繁的情况下,顶层的控制逻辑将无法完全匹配网络事件的更新速度.为此,Onix实例需要知道本域内的拓扑情况,而将其余的Onix实例管理的网络看作是一个聚合的逻辑结点.