标签：交换   缺陷   多协议   mui   流量   存在   服务器   flow   and   

一

• 文章名称：Network Function Virtualization Enablement Within SDN Data Plane
• 发表时间：2017
• 期刊来源：IEEE INFOCOM 2017 - IEEE Conference on Computer Communications
  
• 解决问题：

NFV借助SDN架构来实现，有以下问题：

• 一、流必须通过连接的NF实体，路由策略将变得不灵活，网络中将产生阻塞点，这是有害并且没有必要的。
• 二、控制器对于NFs没有完全的可视化，比如，有多少实例存在，实例放在哪，特定实例可以处理的流量。同样的，NFs的控制器仅能得知有限的网络信息。这样的隔离系统结构导致NFs和网络利用不是最优的。
• 三、NF趋向于改变数据包的状态，这样的改变对于控制器是不可见的。
• 所做贡献：
  • 一、提出NEWS（NFV Enablement Within SDN Data Plane），这个方法将网络状态维护在中央控制器，同时有机地高效地可扩展地支持NF功能。NEWS扩展当前的SDN架构使NFs作为SDN的一部分。这意味着NF实体和控制协议与SDN是一体的。
• 实验对比：
  • 三个带状态防火墙携带小文件（1k到9k）下端到端的性能服务。
  • 携带大文件（10M）的三个带状态防火墙端到端的性能服务。
  • 对比NEWS和OVS的连接跟踪实现。
  • 对比NEWS 服务器选择和HAProxy。
  • 评估可加载应用程序模块的开销，以检查加载应用程序的延迟，以及可加载应用程序是否会影响数据路径性能。

二

• 文章名称：In-band Network Function Telemetry
• 文章名称：带内网络功能遥测
• 发表时间：2018
• 期刊来源：SIGCOMM
• 解决问题：
  • 一、在设计用于有效测量VNF运行时性能的综合架构方面尚未做过任何工作，如何有效地监控NFs运行时性能？
• 所做贡献：
  • 一、设计了通用的架构，可以用于测量中间盒的性能而且不导致任何负载。
  • 二、为带内遥测报告和postcard-like 报告提出了头部格式。
  • 三、进行初步的评估，证明设计引起的微小负载。
• 实验对比：
  基于BESS实现了这个框架，在数据平面，对比不同模块处理数据包的速率。
  ------

三

• 文章名称：OpenNF: Enabling Innovation in Network Function Control
• 发表时间：2014
• 期刊来源：ACM SIGCOMM Computer Commuication Review
• 解决问题：
  • 一、一些应用依赖于动态重新分配数据包进行处理（比如NF升级和数据包处理的动态重新分配），但是当应用（NF）过载，SDN会产生一个新的NF实例，迁移流进行平衡，平衡过程中，新的NF实例对流的处理由于没有必要的NF内部state，可能导致无法检测攻击。虽然SDN可以通过等待当前的流处理完之后再迁移流，但这将导致过载减缓的延迟并且增加SLA惩罚的可能性。（论文中是用IDSs的例子进行说明的）
• 所做贡献：
  • 一、提出OenNF，一种控制层架构，提供高效、协调控制内部NF state和网络转发state ，以允许根据NF实例快速安全，细粒度的流重新分配。
• 不足之处：
  • 不明

• 实验对比：围绕以下问题进行试验

  • 即使在应用程序请求保证状态或状态操作时，是否可以有效地移动，复制和共享状态？ 应用程序从以不同粒度移动，复制或共享状态的能力中看到了哪些好处？
  • NF如何高效的导入导出状态，并且这些操作影响NF的性能吗？NFs应该修改多少以支持南向API?
  • NF部署的规模是如何影响OpenNF的效率的？
  • 现有NF控制平面在多大程度上阻碍了满足高水平目标组合的能力？
  • 现有NF控制平面在多大程度上阻碍了满足高水平目标组合的能力？

四

• 文章名称：Fast Failure Detection and Recovery in SDN with Stateful Data Plane

• 发表时间：2017
• 期刊来源： COMMUNICATIONS SURVEYS AND TUTORIALS
• 解决问题：
  • 一、当前SDN对于故障恢复的支持非常的弱，而传统技术，例如 多协议标签交换（MPLS）快速重路由通常被认为对于运营商网络更可靠。
  • 二、一些流量工程应用，比如故障恢复，挑战着数据平面概念的限制，就拿代表性数据平面的技术来说，一些OpenFlow的缺陷不利于流实现高效的重新路由方案。OpenFlow配置和重配置转发规则都是通过控制器进行执行，由于过载和延迟的要求，限制了对流的监视和控制。
  • 三、 对于故障情况，OpenFlow快速故障转移组仅在检测到故障的交换机提供本地备用路径时才有效。遗憾的是，这种替代路径可能不可用，在这种情况下，需要控制器的干预，其不能保证可达性，以便在网络中的另一点建立重新路由。
• 所做贡献：
  • 一、为带状态SDN数据平面提出了SPIDER，一种数据包处理的管道设计，允许直接通过交换机快速路径，用完全可编程监测和重路由机制实现故障恢复策略。
• 不足之处：
  • 一、安全
  • 二、误报
  • 三、下行状态同步
  • 四、管理权限下发
• 实验对比：
  • 与BFD对比
  • 与MPLS Fast Reroute对比
  • 数据平面协调

五

• 文章名称：A Zero Flow Entry Expiration Timeout P4 Switch
• 发表时间：2018
• 期刊来源：SOSR
• 解决问题：
  • 一、现在的OpenFlow基于流期满的机制，这个机制依赖于固定的超时时间，在期满之后交换机动态的将流表项从流表中移除。分配合适的超时时间值是在高效的流表利用和控制器过载之间的一个折中。
  • 二、为建立巨大可扩展网络，OpenFlow交换机不得不支持大量同时的流，这些流依赖于流表的表项。然而，由于TCAM（Ternary Content Addressable Memory）的限制，流表是有限的。控制器根据hard timeout 和 idle timeout添加和移除流表项。为了减少不必要的TCAM占用，交换机在timeout期满时进行移除对应的表项而不匹配流量。timeout太大导致流表利用率低，太小导致控制器过载（负荷）。
  • 三、解决方案，提出检测TCP流的FIN和RST包，当检测到时，移除流表中对应的表项。目的在于实现最佳的流表利用并且不需要控制器额外的工作负载。
• 所做贡献：
  • 一、实现了一个简单的0流表项超时期满方案，利用了潜在的基于P4的交换机检测TCP流的FIN和RST数据包，并且移除表中对应的流表项，以减小不必要的流表占用实现0流表项超时期满方案，同时不导致控制器过载。
• 不足之处：
  • 一 、无
• 实验对比：
  • 提出的方案与 idle timeout 和hard timeout对比流表使用量（TCAM的占用）
  • 提出的方案与idle timeout 和hard timeout对比packet-in events

带状态论文粗读（二）

标签：交换   缺陷   多协议   mui   流量   存在   服务器   flow   and   

原文地址：https://www.cnblogs.com/Pan-xi-yi/p/9946962.html