zoukankan      html  css  js  c++  java
  • 流量迁移(二)

    一、 Predictive Analysis in Network Function Virtualization

    NFV的预测分析

    问题提出:

    1、新部署的NFV服务比精致的硬件更容易出现问题。
    2、NFV相当于在原来的设备上添加了更多的层,导致底层设备故障事件更难定位。
    如何更好的为NFV进行故障预测和分析?

    问题解决:

    针对一种重要的NFV——vPE (virtualized Provider Edge router),设计了将深度学习模型(LSTM),模型定制和通过迁移学习共享到syslog的组合相结合的系统,从而使我们能够识别潜在故障特征,从而近乎实时地预测故障,最后进行了性能的测试。

    主要面临的问题:

    1、解决训练样本数据不均衡:使用无监督的异常检测方法来训练带有“正常”日志的长短期记忆(LSTM)网络[14]模型。 异常日志模式会触发对网络故障情况的预测。
    2、解决NFV的多样性,不好选特征集的问题:使用聚类来识别具有相似配置和日志行为的VNF,并对其进行汇总(将它们作为合并后的系统日志作为一个单元进行处理)
    3、网络基础架构随着时间动态修改:使用类似于迁移学习的增量培训。 这有助于我们在软件更新后快速引导模型,而不会导致收集训练数据的时间延迟。
    Q1:这个系统是如何设计的? 机器学习算法等分析日志,进行预测异常故障。
    Q2:性能如何、能否进行复现?暂时没法复现。

    二、 Design and Implementation of a Consolidated Middlebox Architecture

    摘要:

    当今的中间盒昂贵且封闭,几乎没有钩子和钩子扩展性,另外它们来自于独立的厂商,并部署为独立的设备,在管理中间盒集合方面几乎没有凝聚力。随着网络需求在规模和种类上不断上升,这种自下而上的方法将中间盒部署置于不断增长的设备蔓延的轨道上,相应地增加了资本和管理成本。为问题的解决,提出CoMb,对中间盒的建立和管理整合在一起的机遇进行了探索【解决部署不高效,管理不方便问题】。
    效果:CoMb将网络配置成本降低了1.8–2.5倍,并将网络中的负载不平衡降低了2–25倍。

    Click

    Click建立网络原型:The click modular router,在github有star。
    类似于将中间盒当作SDN中的交换机,然后加一个中央控制器。。。这也行?

    三、 OFM-- Optimized Flow Migration for NFV Elasticity Control

    年份: 2018
    来源: IWQos

    摘要:

    之前的NFV流迁移重点关注的是使用什么样的机制来保证 (带有状态的NF直接)正确的流量迁移。但是,忽略了迁移流的选择也是一个重大的问题。本文提出了一种新型的流量迁移控制器——OFM,确定不同情况的触发条件和控制目标,主要解决三个挑战:1)避免缓存溢出 2)迁移成本计算 3)高效选择迁移的流量,在SDN和NFV结合的环境下实现了OFM。

    主要贡献:

    1. 对典型的NF弹性控制场景进行了分类。主要包括NF扩展、NF负载均衡、NF故障恢复和NF升级。然后分析了它们的触发条件和流选择的目标。
    2. 为NFV弹性控制的流量迁移优化设计了OFM。OFM收集流的数据和NF运行时的负载,并且识别出哪里需要进行流量迁移。通过有效地建模缓冲区需求和迁移延迟,OFM可以选择适当的流以实现弹性控制目标,同时最大程度地减少迁移成本并避免缓冲区溢出。
      3.OFM基于floodlight,并且给出了广泛的评估。

    四 OpenNF---Enabling Innovation in Network Function Control

    年份:2014
    来源:sigcom

    摘要:

    SDN+NFV可以帮助运营商满足严格的服务水平协议,准确监控和操纵网络流量,并最大程度地减少运营支出。但是,在要求在整个网络功能(NF)实例的集合中重新分配数据包处理的情况下,要同时实现所有这三个目标,就需要一个框架,该框架应提供对内部NF状态和网络转发状态的高效,协调的控制。 为此,我们设计了一个称为OpenNF的控制平面。 我们使用精心设计的API以及事件和转发更新的巧妙组合,以解决竞争条件,限制开销并容纳各种NF。 我们的评估表明,OpenNF可以在不影响灵活性的情况下提供有效的状态控制,并且需要适度添加NF。

    三个挑战问题:

    • 1)迁移时NF状态竞争问题:引入事件概念以及结合两个阶段更新网络转发状态实现解决。
    • 2)迁移可能导致负载过大:引入南向API接口以精确的操纵应用状态的移动、复制、共享。
    • 3)迁移的同时减小对NFs的更改:设计了新颖的南向接口允许控制器请求导入 /导出NF状态,而不用改变NF内部状态的管理。

    OpenNF的评估表明:

    (1)与使用当前的控制框架相比,OpenNF可以消除虚假警报并将NFScale in时间缩短数十分钟; (2)即使要求某些保证,状态也可以被有效地移动,复制和共享,例如,涉及500个流的状态的无损移动仅花费215ms,并且对操作期间接收到的数据包仅施加50ms的额外等待时间; (3)为支持OpenNF南向API而添加的NF最多将代码大小增加了9.8%,并且在状态导出或导入期间,NF的数据包处理时间增加了不到6%。

    五 Load Balancing Algorithm Based on Time Series Prediction of Packet Loss Rate

    对实际的网络物理路径进行路径丢包率预测,从而选择合适的路径发送数据包。

    摘要:

    当前的负载均衡方法存在一些问题,例如缺乏为突然的峰值做准备的能力。本文,我们描述了PPLR(prediction packet loss rate)如何动态预测所有可用网络路径上的丢失水平,以及如何为下一预测期调整数据包的分配比例。

    在本文中,我们介绍了一种新的基于数据包的多路径负载平衡算法,称为PPLR,这是一种主动的负载平衡策略,可以防止数据包丢失。PPLR算法要求动态预测所有可用路径上的损耗水平。 然后将此预测信息用作控制信息的输入,以在某个预测周期将数据包的比例分配给可用路径。

    预测丢包率的动机来自多种考虑。

    第一

    在特殊的BADABING中使用主动测量损耗率,BADABING是目前可用的最准确的损耗特性测量工具[6]。

    第二

    预测方法将比通常测量的方法更快地跟踪拥塞状况。 值采用反应性方法。

    第三

    对于使用前向纠错(FEC)传输的实时多媒体流量,它代表带宽开销,因此,必须仅发送所需数量的这些内容。 在这方面,准确的预测将非常有用。在PPLR中,负载平衡决策基于对单个路径的丢包率的预测,而不是对相同路径的过去丢失级别的测量。

  • 相关阅读:
    [LeetCode] Meeting Rooms I & II
    [LeetCode] Graph Valid Tree
    [LeetCode] Palindrome Permutation I & II
    [LeetCode] Encode and Decode Strings
    [LeetCode] Paint Fence
    android 发送短信功能
    andrioid 分享到其它(短信,qq,微信等功能)
    android Dialog实例
    android开发之onCreate( )方法详解
    android edittext属性说明
  • 原文地址:https://www.cnblogs.com/Pan-xi-yi/p/11727663.html
Copyright © 2011-2022 走看看