基于OpenFlow的SDN技术研究.pptVIP

软件学报

JournalofSoftware,2013;摘要;1SDN研究背景:逻辑控制和数据转发分离;2基于OpenFlow的SDN关键组件及架构;2.2控制器;;3基于OpenFlow的SDN面临的问题和解决思路;;;;3.2.2DevoFlow

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

规则复制方式在流表项中“操作”字段上增加了CLONE标志,标志清零,则匹配按正常情况处理,由硬件TCAM实现;如标志被置位,则由软件实现建立精确匹配的微流.同时也减少了TCAM资源的消耗.

局部操作方式包括多路径支持和快速重路由，提供多个可能的输出端口、指定多条备用路径.

DevoFlow功能需要通过修改OpenFlow交换机的流表结构和硬件架构来实现,实际上增加了数据平面的部分控制功能,同样降低了实际部署过程的通用性.;3.2.3HyperFlow

通过减小控制器的处理开销,无法从根源上解决单点性能瓶颈问题.多控制器管控的分布式控制平面的设计思想是未来基于OpenFlow的SDN面向较大规模网络部署的必经之路.

HyperFlow是基于为广域网设计的分布式文件系统WheelFS而设计的,网络事件在不同控制器之间以文件的更新形式来实现.

从实现和测试的性能来看,在保证控制带宽和限定网络延迟的情况下,HyperFlow能够处理的网络事件小于1000次/秒,性能还不够高..对于网络状态事件频繁网络,或对于数据中心或较大规模网络,HyperFlow有可能面临性能瓶颈.;3.2.4Onix

针对控制平面在可扩展性、可靠性和通用性等方面的不足,Onix[31]提出了一整套面向大规模网络的分布式SDN部署方案.

网络信息库(networkinformationbase,简称NIB)用于维护网络全局的状态,Onix的设计关键就在于维护NIB的分发机制,从而保证整个网络状态信息的一致性.;;3.2.5Devolvedcontroller

HyperFlow和Onix并未针对控制器如何分区提出具体的分区算法.鉴于多路径区域划分问题在图论中是NP难问题,Devolvedcontroller[36]针对多控制器管控区域划分问题提出了两种启发式算法:路径-分区算法(path-partitionapproach)和分区-路径算法(partition-path)

这两种启发式算法都降低了实际分区算法的复杂度.从分区结果来看,分区-路径算法使得每个控制器监控的链路更少,从而减小了控制器开销;但路径-分区算法不需要考虑每个控制器已经划分的链路,因此通常可以得到最短路径.;3.2.6小结

从上述解决方案来看,目前,基于OpenFlow的SDN可扩展性研究的主要思路有如下两点:

(1)修改OpenFlow交换机的处理流程或硬件架构,或者给OpenFlow交换机增加部分控制功能,从而减少控制器和OpenFlow交换机之间的信息交互,分担控制器的处理开销,提高控制器的可扩展性能.(纵向扩展)

(2)多控制器的分布式管控平面,通过分域管理网络,控制器之间实现基本的状态分发过程.(横向扩展),是SDN可扩展性研究的主流方向,适用于数据中心、广域网等规模较大的网络.;;;3.4运作模式和演进趋势

以学术界为技术依托,并注重产业界的推广和应用的运作模式,是基于OpenFlow的SDN技术取得快速发展的根本原因.

SDN在要求逻辑控制与数据转发分离的前提下,数据平面应当维持尽量简单的转发功能.然而,为了增加数据平面转发功能的向后兼容性,OpenFlow标准不断扩充转发平面匹配字段,这进一步增加了未来OpenFlow交换机的硬件设计成本,在一定程度上也增加了控制平面维护的复杂度,不利于OpenFlow的未来演进发展.

在OpenFlow标准的不断演进中,是维持简单的硬件结构还是在OpenFlow硬件中继续增加更多的功能,需要学术界和产业界的共同关注.文献[43]考虑到目前数据平面的设计复杂趋势,提出了一种新的概念:网络结构;4基于OpenFlow的SDN应用;5总结与展望;此课件下载可自行编辑修改，供参考！

感谢您的支持，我们努力做得更好！