OpenFlow协议超时机制简介

简介:

一、背景

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

65df77093c8bcee31350785b9ef1ca36582c09ae

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]

6f7935d645d591069c3e26a6b1a4fb46428f0f5c

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

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

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

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

 ●  过小的空闲超时 vs 过大的空闲超时

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

6207224e8067c0f1c3117a7a48a03d0abc94667b

图一:过小的空闲超时和过大的空闲超时[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协议中为提高流表空间利用率而采用的超时机制以及该机制存在的问题,并简要介绍针对该问题的两种解决方案。


原文发布时间为:2018-10-31

本文作者:multhree

本文来自云栖社区合作伙伴“SDNLAB”,了解相关信息可以关注“SDNLAB”。

相关文章
|
1月前
|
网络协议 算法 网络性能优化
|
6月前
|
JSON 移动开发 网络协议
认识协议【网络基础】
认识协议【网络基础】
38 1
|
4月前
MQTT协议本身是支持心跳保活机制的
MQTT协议本身是支持心跳保活机制的
74 3
|
6月前
|
设计模式 缓存 网络协议
网络协议 | 典型协议、B/S模式、C/S模式
网络协议 | 典型协议、B/S模式、C/S模式
90 0
|
6月前
|
网络协议 网络架构
TCP协议报文,核心特性可靠的原因,超时重传详细介绍
TCP协议报文,核心特性可靠的原因,超时重传详细介绍
|
9月前
|
运维 监控 Dubbo
Dubbo协议异步单一长连接原理与优势
Dubbo协议异步单一长连接原理与优势
420 0
|
10月前
|
存储 XML Java
网络基础 CAS协议学习总结
网络基础 CAS协议学习总结
252 0
|
12月前
|
网络协议 安全
TCP协议中的几个核心特性(上)
TCP协议中的几个核心特性(上)
|
12月前
|
网络协议 网络性能优化
TCP协议中的几个核心特性(下)
TCP协议中的几个核心特性(下)
|
网络协议 算法
【网络篇】第十二篇——TCP协议通讯流程
【网络篇】第十二篇——TCP协议通讯流程
【网络篇】第十二篇——TCP协议通讯流程

热门文章

最新文章