OpenFlow协议中如何提高交换机流表的匹配成功率

写在前面

这段时间一直在研究如何提高流表空间的利用率。一直没能想到好的idea。有一篇文献中比较了现有研究中提到的手段，在这里记录一下都有哪些类型的手段以及这些手段存在的不足。这些手段不仅局限于如何提高流表空间的利用率，更把范围拓展至如何提高交换机流表的匹配成功率。

背景

  • 软件定义网络(Software Defined Network，SDN)作为一种新的架构，利用分层的思想将控制平面和数据平面分离，为网络的部署和配置提供了极大的灵活性和可扩展性。
  • 然而当前的SDN网络只能对L2～L4层的信息进行识别，控制器在制定流表项的timeout值时，将所有的数据流同等对待，导致交换机中流表的匹配成功率只有不到20%，极大地增加了控制器的负担，降低了网络的整体性能。

解决手段

  • 增加流表的容量

    • 思路： 通过在交换机中增加缓存的方式，来存放因为hard_timeout时间到达而被删除的频繁匹配的流表项，以此来提高流表的匹配率。
    • 不足： 本质上只是增加了流表的容量，这种方式显然不能跟上SDN发展的速度；同时流表项在缓存中的匹配速率相比TCAM，性能要差很多。
    • 相关文献： 《Flow table management scheme applying an LRU caching algorithm》,ICTC,2014
  • 控制器中增加一个缓存模块
    • 思路： 通过增加的缓存模块来记录流表项的到期时间，将流表项被再次安装的时间和到期时间的差值作为流表项的更新依据。
    • 不足： 这种方式对因为idle_timeout超时导致的流表频繁更新存在只增不减的弊端。
    • 相关文献： 《Intelligent timeout master：dynamic timeout for SDN—based data centers》,IFIP/IEEE,2015
  • 预测无用的流表项
    • 思路： 通过预测的方式，提前将最近一段时间内不会被匹配的流表项删除，预留流表空间给即将到来的数据流。
    • 不足： 这种方式不可避免的会出现误判的情况，可能导致有用的流表项被删除，而真正无用的方式却占据流表空间。但是如果能够完善预测的机制，这种方法仍然是一个理想的idea。
    • 相关文献： 《FlowMaster：early eviction of dead flow on SDN switche》,the 15th International Conference on Distributed Computing and Networking,2014
      《A dynamic timeout control algorithmin software defined networks》,IJFCC,2014
  • 将流表的工作方式类比为排队系统
    • 思路： 将流表模型化为状态依赖的排队模型，并借助排队论定量地分析了hard_timeout对流截断次数和阻塞概率的影响。
    • 不足： 基于hard_timeout超时机制的模型，灵活性较差，对于网络中数据传输时间参差不齐的数据包，不能很好地满足传输需求。
    • 相关文献： 《AHTM：achieving efficient flow table utilization in software defined networks》,the 2014 IEEE Global Communications Conference,2014
  • 考虑控制器的处理能力
    • 思路： 以上提到的方法都没有将控制器的处理能力作为动态修改timeout
      值的制约因素。可以将控制器单位时问内能够处理的
      packet-in请求数作为约束条件，以满足该条件的最小idle_timeout值作为最终结果，从而实现满足控制器处理能力情况
      下，最大限度地提高流表匹配率的目的。
    • 不足： 该过程假设所有数据流都具有相同分布参数，没有考虑不同数据流类型间的特征差异。
    • 相关文献： 《Effective idle_timeout value for instant messaging in software defined network》,the 2015 IEEE International Conference on Communication Workshop,2015
  • SDN网络中增加数据流类型感知技术
    • 这个技术不太理解，需要进一步阅读。
    • 相关文献： 《SDN-based application—Aware networking on the example of YouTube video》,2013 Second European Workshop on Software Defined Networks,2013
      《Application—Awareness in SDN》, the ACM SIGCOMM 2013 conference on SIGCOMM,2013
  • 将流表的工作方式类比为排队系统
    • 思路： 将流表模型化为状态依赖的排队模型，并借助排队论定量地分析了hard_timeout对流截断次数和阻塞概率的影响。
    • 不足： 基于hard_timeout超时机制的模型，灵活性较差，对于网络中数据传输时间参差不齐的数据包，不能很好地满足传输需求。
    • 相关文献： 《AHTM：achieving efficient flow table utilization in software defined networks》,the 2014 IEEE Global Communications Conference,2014
  • 综合利用数据流类型信息和网络资源使用情况
    • 思路：
      在L2~L4层网络信息的基础上，增加数据流特征信息区分音频流、视频流和普通文本流等数据流类型，从而为不同流类型数据包的流数据包表项制定不同的timeout值，能够在满足控制器处理能力的情况下，最大限度地利用流表资源，从而提高流表的匹配率
    • 不足： 仅仅将数据流分为三大类,没有将数据流进行更细的划分，从而对流表项的更新实现更细粒度的控制。
    • 相关文献： 《Intelligent update method for flow table in switch through analyzing data flow characteristics》,IJCA,2016

总结

  • 目前我看到的针对流表的更新问题相关的文献，主要是分成两种类型：

    • 寻找流表的匹配规律，来动态的更新timeout值，从而提高流表的匹配率。
    • 提前移除无效的流表项，无论是通过预测的方式还是数据包本身可以明确的判断这个流即将关闭连接。
    • 综合利用数据流类型信息和网络资源使用情况来更新流表。

原文地址：https://www.cnblogs.com/multhree/p/9858826.html

时间： 2024-11-03 21:06:46

OpenFlow协议中如何提高交换机流表的匹配成功率的相关文章

OVS中arp响应的流表的实现

总结: 1.br-int 流表总体是按照Normal 的方式,即常规的交换机的转发方式进行转发.而br-tun 交换机则主要按照流表的方式进行转发. 2.一般情况下,VM发出的ARP请求,会在该VM的所有邻居进行广播发送和查找,大量浪费带宽.当neutron开启了l2 pop后(二次注入功能), 计算节点会学习别的主机发送的免费ARP, 从而在本地存在ARP表项. 3.当本地的VM发出ARP请求时,br-tun交换机会优先查找本地的ARP表项,从而对报文进行ARP应答. 这样的话,就不用发出AR

ovs源码阅读--流表查询原理

segmentfault对应博文:https://segmentfault.com/a/1190000016112493 背景 在ovs交换机中,报文的处理流程可以划分为一下三个步骤:协议解析,表项查找和动作执行,其中最耗时的步骤在于表项查找,往往一个流表中有数目巨大的表项,如何根据数据报文的信息快速的查找到对应的流表项是ovs交换机的一个重要的功能. 在openflow协议中,支持多级流表的形式,可以类比于将一个复杂的功能进行打散,分解成过个小的功能,实现一个流水线的功能,具体见下图: 上图中

OpenFlow协议（OVS）

白皮书(版本): 功能(OpenFlow半年升级一次) FlowTable流表:由很多个流表项组成,每个流表项就是一个转发规则.进入交换机的数据包通过查询流表来获得转发的目的端口.流表项由头域.计数器和操作组成:其中头域是个十元组,是流表项的标识:计数器用来计算流表项的统计数据:操作标明了与该流表项匹配的数据包应该执行的操作. Secure Channel:安全通道是连接OpenFlow交换机到控制器的接口.控制器通过这个接口控制和管理交换机,同时控制器接收来自交换机的事件并向交换机发送数据包.

openflow流表项中有关ip掩码的匹配的问题(控制器为ryu)

一.写在前面 唉,被分配到sdn安全方向,顶不住,顶不住,感觉搞不出来什么有搞头的东西.可若是让我水水的应付,我想我也是做不到的,世上无难事只怕有心人.好了,进入正题,本次要讨论的时一个比较细节的东西,在流表项中的有关ip掩码的问题.对了,本文适合于,有一定基础的openflow使用者,一点点就行. 二.问题描述 若不是机缘巧合,我甚至完全不会注意到这个问题,为什么,咱来看一个平时实验环境中最为常见的流表项长啥样,如图1                                      

Openflow流表应用测试--逻辑隔离

1.搭建拓扑 搭建了三层的二叉树结构网络,开启SimpleSwitch3.py无法完成pingall联通测试,于是将拓扑结构更改为简单的line,四个交换机(OF13)连成一线,每个交换机下挂两个主机,依次h1--h8 s1 = net.addSwitch('s1', cls=OVSKernelSwitch, protocols='OpenFlow13', mac='00:00:00:00:00:11')    s2 = net.addSwitch('s2', cls=OVSKernelSwit

OpenFlow协议标准演进过程

OpenFlow是一种新型网络协议,起源于斯坦福大学的Clean Slate项目组.OpenFlow提出的出发点是由于研究人员无法改变现有网络设备进行创新网络架构和协议的研究和实验,而这些新的网络创新思想恰恰需要在实际的网络上才能更好地验证.斯坦福大学因此提出了控制转发分离架构,将控制逻辑从网络设备中分离出来,交给中央控制器集中统一控制,实现网络业务的灵活部署,并且他们设计了OpenFlow协议作为控制器与交换机通讯的标准接口.近年OpenFlow已经引起了网络设备商和网络管理员的广泛关注,使用

Floodlight下发流表过程分析

转载请注明出处:http://blog.csdn.net/vonzhoufz/article/details/32166445 当一个packet到达openflow交换机,会进行流表的匹配,如果没有找到相应的流表项,就会发送一个packet_in消息 到达SDN controller端,控制器根据一定的路由算法决策后,会向该路径上的所有交换机下发流表(也就是发送FLOW_MOD消息,里面有对应的action).这里要知道的是在SDN的环境下,控制器具有全局拓扑信息,每当有链路状态改变时就会跟新

SDNLAB技术分享（四）：利用ODL下发流表创建VxLAN网络

邓晓涛,当前就职于江苏省未来网络创新研究院,是CDN团队的一名研发人员,主要从事SDN相关的研发相关工作.曾就职于三星电子于先行解决方案研发组任高级工程师.思科系统于云协作应用技术部(CCATG)任工程师.-----------------------------------------------------------------------------------------------------[分享正文]今天想跟大家分享如何通过ODL控制器下发流表来创建VxLAN网络.ODL作为当前

Floodlight中的临时流表

运行Floodlight,在Mininet中新建一个拓扑之后,并未添加相关的流表项,但是主机之间却可以相互通信.执行pingall操作,任意两个主机之间都能通.相当于没有任何路由表的路由器,它是怎么让这些网络中的主机通信的呢? 原因在于Floodlight默认启用了Forwarding模块.说这个模块之前,首先说说Floodlight 中流表的两种添加方式:主动式和反应式. 官网上的文档是这么说的:http://docs.projectfloodlight.org/display/floodli