22

OpenFlow协议超时机制简介

 5 years ago
source link: https://www.sdnlab.com/22563.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

作者简介: 陈俞辛,福州大学数计学院2016级计算机科学与技术本科生,目前研究方向为软件定义网络SDN,邮箱multhree @163.com。
陈翔,福州大学数计学院2015级计算机科学与技术(实验班)本科生,对软件定义网络SDN,特别是对P4语言感兴趣。邮箱[email protected]

一、背景

为支持大规模的SDN网络,OpenFlow交换机需要存储大量的流表项来处理接收到的流量。然而,受限于交换机TCAM内存容量,流表所能存储的流表项数目是有限的;同时,由于TCAM十分耗能且昂贵,为适应大规模流量场景而增加TCAM容量以容纳更多的流表项是不现实的。

OpenFlow协议通过超时机制来缓解交换机流表容量有限的问题。该机制让流表项只在一段时间内生效,并自动清理掉旧的、失效的流表项,腾出流表容量,以添加新的流表项。OpenFlow协议的流表项超时机制的核心是有效时间(timeout),用户可以为每条流表项指定一个有效时间,在控制器向交换机下发流表项时设定。如果某条流表项存在的时间或未被匹配到的时间超过预设定的有效时间,OpenFlow交换机会主动移除该流表项。

有效时间又分为硬超时(hard timeout)和空闲超时(idle timeout)。

  • 空闲超时(idle timeout),流表项的idle_timeout字段非0。在空闲超时这段时间内,如果没有任何数据报匹配到该流表项,则交换机会主动将该流表项从流表中移除。即流表项从交换机设备移除的相对时间。
  • 硬超时(hard timeout),流表项的hard_timeout字段非0。当该流表项的存在时间超过了预设置的硬超时,流表项就会被交换机从流表中移除。即流表项从交换机移除的绝对时间。
  • 在Ruckus生产的ICX 7250、ICX 7450、ICX 7750等系列设备[1]中,当某条流表项两者字段为不同取值时,交换机的处理行为如表一所示。

表一【2】

空闲超时

硬超时

行为

非0 0

在空闲超时的时间内没有与该流表项匹配的包到达时,移除该流表项

0 非0

若流表项存在时间超过硬超时,移除该流表项

非0 非0

1.当空闲超时<硬超时时:

当在空闲超时期间没有数据报匹配该流表项,交换机删除该流表项;

当在空闲超时期间有数据报匹配该流表项,则交换机会在该流表项的存在时间超过硬超时时删除该流表项。

2.当空闲超时>硬超时时:

当该流表项的存在时间超过硬超时时,交换机删除该流表项。

0 0

除非控制器发出OFPFC_DELETE 的流表修改请求,否则交换机不会主动移除流表项。

说明:

  • 两者取值范围为均为 0-65535 s。
  • show openflow flows:查看流表项添加的时间、上一次被匹配的时间、以及流表项的有效时间。
  • 当一条流表项因超时被移除时,交换机会生成对应的系统日志。可以通过命令[no] openflow log timeout 来选择启用或禁用日志生成。
  • 如果一条流表项没有被指定有效时间,则有效时间默认为0。除非控制器主动删除,否则该流表项将永久存在。
  • 某条流表项被移除时,如果 OFPFF_SEND_FLOW_REM 标志位为真,则交换机需要向控制器发送一条消息,该消息包含了所删除流表项的详细信息,包括被移除的原因、生存时间等。
  • 在交换机与控制器之间的连接突然中断的情况下,交换机默认会进入fail-secure模式工作,所有发送给控制器的包都将被丢弃,交换机将继续按照流表项预设定有效时间对其进行移除。若在故障时将交换机设置为进入fail-standalone模式工作,那么交换机将会对新到达的流量按照传统路由交换功能进行处理,并且移除交换机内已有的所有流表项。
  • 当控制器发出OFPFC_MODIFY 或者 OFPFC_MODIFY_STRICT 的修改流表项请求时,交换机会根据请求对流表项的说明字段进行更新。

二、现有超时机制存在的问题

问题1:控制器对流表项设定哪一类型的超时能更好地缓解交换机流表容量紧张的问题呢?

  • 硬超时 vs 空闲超时
    因为硬超时不够灵活,所以一般情况下控制器会为流表项设定空闲超时而非硬超时。例如,考虑以下场景,控制器为一条会被频繁匹配的流表项设定硬超时,那么该流表项添加到流表的时间超过硬超时后就会被移除;在该表项因超时被移除后,接下来本应匹配这条流表项的数据报到达交换机时就会触发packet-in事件,增加控制器的负担;相反,如果控制器设定的是空闲超时,那么这条会被频繁匹配的流表项就不会被移除。换句话说,硬超时无法区分流表项是否有效,导致交换机流表空间无法被有效利用。因此,控制器通常为流表项设置空闲超时,而非硬超时。

问题2:如何设置空闲超时的大小,以缓解交换机流表容量紧张?

  • 过小的空闲超时 vs 过大的空闲超时
    较小的空闲超时能尽快腾出流表空间以容纳新的流表项,然而过小的空闲超时会导致额外的问题。

图一:过小的空闲超时和过大的空闲超时[3]
如图一所示,理想情况下,当流f1到达交换机时应该只触发一次packet-in事件,即流f1的第一个数据报到达时触发。

但是,当流f1的空闲有效时间T1小于相应的包到达的时间间隔I1时,控制器所下发的、匹配流f1的流表项总会在后续流f1的数据报到达之前删除,由于没有相应的流表项,流f1的每一个数据报到达时都会触发 packet-in 事件,这些packet-in事件会消耗大量的控制器资源。

当流f2的空闲有效时间T2大于相应的包到达的时间间隔I2时,一条流表项失效之后会在流表中多停留 T2-I2的时间,造成不必要的冗余和开销。

因此,根据不同流量特性设置合适的有效时间是十分重要的。然而OpenFlow协议本身并没有给出可行的解决方案来计算合适的有效时间。

三、现有超时机制缓解流表空间紧张问题效果不好的解决方案

当前,存在以下两种缓解流表空间紧张的解决方案:

3.1通过启发式算法或基于历史信息的算法计算得到针对不同的流量的流表项的有效时间

(1) Effective Switch Memory Management in OpenFlow Networks[4]
文章中提出一个控制器系统,该系统采用了一种自适应超时启发式算法(an adaptive timeout heuristic)来计算最合适的空闲超时,而不是将所有的有效时间都设置为相同的值。
(2) Intelligent Timeout Master: Dynamic Timeout for SDN-based Data Centers[3]
文章中提出在控制器中添加用来记录上一次超时时间的cache模块,并且使用基于历史信息的算法(history based algorithm)来预测得到合适的有效时间。同时利用流表负载作为来调节有效时间,避免流表空间溢出。

3.2提前删除无效流表项,而非在超过有效时间之后才删除

(1) FlowMaster: Early Eviction of Dead Flow on SDN
Switches
[5]
文章中提出一个提前移除流表项的方法,该方法采用一种投机机制(a speculative mechanism),通过预测判断某条流表项是否已经失效,并提前移除该流表项。
(2) A Zero Flow Entry Expiration Timeout P4 Switch[6]
文章中提出一种流表项移除技术,该技术是当交换机解析完TCP数据报的头部之后查看FIN或RST字段的值,若FIN或RST位为1,则说明这个TCP连接即将关闭,交换机将会移除相应的流表项,并向控制器发送一条消息,该消息包含了所删除流表项的详细信息,包括被移除的原因、生存时间等。

四、总结

本文介绍OpenFlow协议中为提高流表空间利用率而采用的超时机制以及该机制存在的问题,并简要介绍针对该问题的两种解决方案。

五、参考文献


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK