摘要：
近年来，软件定义网络越来越受到关注，尤其是在OpenFlow被提出之后。
尽管以控制器为中心的范例为管理和可见性带来了巨大优势，但它也可能导致交换机控制器接口上出现一些可伸缩性和性能问题。
我们提出了“黑洞机制”作为替代，以减少反应模式下OpenFlow操作的通信开销，讨论UDP流量对控制平面通信的影响，并且描述了无论何种流量类型，硬超时导致的匹配规则过期问题。
最后，我们使用Pantou OpenFlow交换机和运行L2_learning应用程序的POX控制器，通过实验设置评估通信开销。
背景/问题：
网络的集中视图有助于简化部署和流量工程。
尽管集中式视图带来了一些巨大的优势，但它也是体系结构的关键点，可能导致瓶颈或单点故障——所有数据包转发决定都在控制器上，故障或性能下降对SDN系统有很大影响。因此，控制器性能问题是特别重要的研究课题。
有一些策略可以解决Controller的性能限制：基于散列的ECMP流转发，通配符规则流转发，逻辑上分布式的Controller部署，物理上分布式的Controller部署，分层Controller系统，多线程Controller等。
有关性能的一个重要方面是OpenFlow交换机和Controller之间的大量消息交换。
为了减少交换控制器消息的通信量，有使用通配符流条目的提议，例如DEVOFLOW和DIFANE：
DEVOFLOW试图通过使用流通配符并引入机制来提高可见性，以减少Switch-Controller的开销，旨在通过规则克隆和本地操作机制将某些控制权还给交换机。 DIFANE通过有选择地将数据包定向通过中间交换机（授权交换机），将所有流量保持在数据平面中来解决该问题。
另一种方法建议使用多个表来减少QoS流实例化期间的过载。
解决办法：
我们建议实现一种称为“黑洞”的机制，该机制用于以太网交换机中，以静默方式丢弃例如拒绝服务流量，可以将同一机制应用于OpenFlow交换机，以减少发送到Controller的重复数据包的数量，并减少过载。
OpenFlow规范没有一种机制可以确保仅将第一个数据包发送到Controller，因此我们建议包括一个新阶段来执行此检查。
openflow
新机制
提议的修改仅适用于不匹配的数据包，因此不会影响流表上的常规条目。换句话说，对于动作是“发送给控制器”的情况，我们建议的更改仅影响表丢失。
具体实现：
blackhole基本思想是实现一种机制，以检查在时间间隔T内是否已经向控制器发送了通知：
当第一个数据包到达时，没有先前的通知，因此通常将数据包发送给控制器。然而，如果在时间间隔T内存在相同流的后续分组，则丢弃下一个分组。参数T可以是固定值（即1s），也可以是控制器配置的参数。
通过这种机制，控制器将周期性地仅接收每个流一个数据包。TCP或SCTP会话刚建立的情况中，黑洞机制不会施加任何限制或约束，第一个数据包始终像在当前实现中一样被处理。
当条目由于硬超时而到期时，黑洞的主要优点尤其体现在UDP和TCP/SCTP流上。
但是为了实现黑洞机制，必须存储已经通知的流的列表。 这就必须使用更多内存来保留此信息的成本。 该内存应足够大，以在一定时间间隔内容纳不同流量。
“黑洞”机制有助于减少Switch-Controller接口的过载，同时在反应模式操作中保持每个新流的可见性优势。，并且通过仅对OpenFlow交换机的数据包处理进行少量更改，黑洞机制就可以维持原始的OpenFlow架构，不会给Controller带来更大的复杂性。
忽略吐槽：
自己在论文里说了并没有比较出这个机制和普通机制哪个性能高。
讲道理，我惊了，还有这种操作，这是IEEE的？
致命的是，它也没讲清楚这个简单的操作究竟有什么用，（通过这种机制控制器将周期性地仅接收每个流一个数据包），为什么就能说明解决了控制器拥塞情况，不会出现问题吗？兄弟，后面全都被你丢了嗷，真的没事哦？
我上我也行
这论文，精彩。
网友评论