OpenDaylight用例之网络资源优化用例

移动计算,流媒体和基于云的服务带来了网络流量的极大增长,这给网络基础设施带来了很大的挑战。仅仅依靠增加硬件设备和管理团队已经无法解决这个问题,企业和服务提供商迫于投资者的压力,需要以较少的投入做更多的事,因此,网络运营商必须想法让他们的网络投入具有最高的投资回报率(ROI)。

企业和服务提供商纷纷转向SDN以提高他们基础设施和运营的效率。通过集中控制和提供空前的智能性和开放性,SDN为网络运营商提供了前所未有的优化基础设施的工具。

挑战
改善并最优化网络性能始终是网络的一项挑战。不管采用什么技术,在哪里部署,谁来部署,网络设计考虑的第一因素是经济效益。

随着线性速率成倍增长,网络越来越低效,网络优化需求越来越急迫。由于带宽和网络延迟优先级很高,运营商和他们的用户都在寻求方法优化网络开销、网络弹性和其他跨异构网络技术和设备的QoS指标。网络优化对于昂贵的网络带宽,例如WAN(对于企业和云提供商)、海缆网络和传输网(对于运营商),是最重要的。

没有运营商可以奢侈到推翻一切从头再来。运营商已经在现有的基础设施上投入了很多钱,因此需要不断地管理和发展现有网络以充分利用他们的大量投入。 所以,网络资源优化方案必须使运营商能够从现有基础设施获取更多利益,而利用创新方案让这些变得可行。

强有力的网络资源优化方案应该提供:

具有优化一系列参数的能力(带宽,延迟,开销和可用性等)具有执行一系列优化算法的能力健壮的拓扑和网络状态,包括多层次拓扑(对于运营商网络而言)支持多种技术和应用策略加强具有操作多厂商设备的能力,包括不支持SDN(non-SDN-enabled)的硬件。
为什么选择OpenDaylight?
通过统一维护网络拓扑和配置连同告警和性能状态,OpenDaylight为网络资源优化(NRO)提供了一套丰富的基础网络服务和扩展网络服务。大型企业通过利用OpenDaylight的逻辑集中网络状态、数据分析和异构基础设施之间的流量工程策略形成的NRO算法获益。运营商正在实现基于OpenDaylight融合分组光网络的多层控制,这样可以优化带宽使用、保护带宽和动态服务环境的服务布局。

通过使用OpenDaylight提供的一个开放式SDN平台,运营商可以发挥出软件定义网络的潜能。

模型驱动服务抽象层(MD-SAL)利用业界标准的YANG模型将网络应用映射到底层设备支持的格式。模块化、插件南向接口方法(例如,控制器到设备)广泛支持标准的网络管理接口(例如BGP,PCEP),OpenFlow以及专用的接口和设备。意图为基础的北向(例如,网络应用到控制器)接口将SDN能力暴露给不同的网络应用同时将底层基础设备的细节抽象化。已具备支持专有网络服务和扩展网络服务的能力,包括路径计算、资源管理、针对虚拟域和物理域的数据分析。多种内置的策略规范。业界广泛认可,包括最大的控制器社区。
通过允许运营商组合网络应用和设备,OpenDaylight提供了一个强有力的支持自动化和操作智能化的服务交付平台,也支持运营商根据自身情况进行SDN迁移。

示例
腾讯DCI
作为中国杰出的网络服务提供商,腾讯处于竞争激烈的消费空间,节省开销很关键,尤其在WAN方面。腾讯开发了基于OpenDaylight的控制器,用以优化带宽使用从而解决其在大量的数据中心间传输服务的问题。

中国移动NovoNet
中国移动作是全世界最大的服务提供商之一。NovoNet描绘了2020年基于SDN和NFV的企业网络的愿景。其中一个重要用例就是围绕“自配置、自管理、智能流量规划和实时感知”实现的流量优化。

CHINA MOBILE NOVONET
多层次传输控制器解决方案
SDN在电信行业一个重要的用例就是Transport-SDN,专注于解决城域网和长距离连接的光分组设施的控制问题。很多主流的原始设备制造商已经基于OpenDaylight开发出了Transport SDN控制器,用来控制多层次设备。

爱立信SDN控制器
爱立信的Transport SDN产品提供了一个网络资源和拓扑端到端、优化的资源位置以及跨IP层和光层的网络引擎的抽象视图。

本文转自d1net(转载)

时间: 2024-09-19 08:58:32

OpenDaylight用例之网络资源优化用例的相关文章

okhttp-单例Okhttp能像单例httpclient一样不需要我们手动去维护cookie吗?

问题描述 单例Okhttp能像单例httpclient一样不需要我们手动去维护cookie吗? android 6.0sdk移除了apache的httpclient,volley必须得手动维护cookie,网上有文章说Okhttp支持cookies维护,但我有个疑问,单例Okhttp能像单例httpclient一样不需要我们手动去维护cookie吗?多谢解答 解决方案 最好用httpclient,它比较完备. 解决方案二: HTTP 协议可能是现在 Internet 上使用得最多.最重要的协议了

java-项目中什么时候用单例什么时候用多例?

问题描述 项目中什么时候用单例什么时候用多例? 在网上看朋友说,action一定要用多例,保证数据安全.那么在项目开发中,通常哪些地方用单例哪些地方用多例呢? 解决方案 单例多例需要搞明白两个问题: 1. 什么是单例多例: 2. 如何产生单例多例: 3. 为什么要用单例多例 4. 什么时候用单例,什么时候用多例: 1. 什么是单例多例: 所谓单例就是所有的请求都用一个对象来处理,比如我们常用的service和dao层的对象通常都是单例的,而多例则指每个请求用一个新的对象来处理,比如action;

java web-Struts里的action是单例,那这个单例是什么意思?

问题描述 Struts里的action是单例,那这个单例是什么意思? Struts里的action是单例,那这个单例是什么意思?Struts里的action是单例,那这个单例是什么意思? 解决方案 首先action不是单例.这里说的单例,是设计模式里提到的单例模式(singleton),一个程序这个类型只有一个对象实例. 解决方案二: struts 2的Action是多实例的并非单例,也就是每次请求都会产生一个Action的对象.Servlet是单例的,也就是整个应用中每个被请求到的Servle

Spring中单例bean访问非单例bean的第一种方式:方法注入

方法注入在Spring中是很少用的,主要应用是, 对象中可能定义了一个受保 护的抽象方法,而容器可能在运行时实现他以返回由容器查询得到的对象. 方法注入的最好用途之一就是处理单态.无状态对象需要调用非单态.有状 态或者非线程安全对象的情况. 以前刚接触Spring时,如果在单例bean中调用非单例bean,只要把那个非单 例bean 的singleton设置为false就可以了.其实不然,大家想,我们创建了一 个单例对象,在此单例对象中所用到的其它bean也只会创建一次--(大多数情 况是这样的

不得不说--自动化测试元素定位与用例设计

  关于自动化测试,经常被问到元素的定位 与 如何设计用例. 很多时间我也帮不了你解决实际的问题,只能从个人脚本谈谈如何看待这些问题.   不得不说之元素定位   虽然,本章写了十几篇文章来讲元素的定位与操作,对于碰到的一些常见功能,如何通过技巧来定位它们,但是在实际的自动化脚本开发中,不管是新手还是具有一定经验的老手,我们面临最多的问题仍然是元素的定位问题. 有时间元素定位非常简单,例如,我们只要知道这个元素有的id和name 就可以轻松的来定位到它:有时间元素的定位却非常的令人非常头疼,尽管

不得不说之用例设计

自动化测试用例如何设计,对于新手来说也是比较难理解的问题. 不少新手刚刚掌握了写脚本的能力,一上来就拿着功能测试用例一条一条的转化成自动化用例.在写的过程中,会发现诸多问题,例如,脚本中重复代码很多,一个脚本的执行结果影响到另一个脚本的执行,有些功能用例很难转化成自动化用例等. 站在用户角度设计自动化 在功能测试的时候我们一般会遵循这个原因,但是自动化测试往往可以实现更强大的功能,所以,我们在设计脚本的时候很容易违背这个原则.例如,你要获得的数据是用户不可见的,你要判断用例是否成功的信息也是用户

环环相扣---近期自动测试经验总结

1.问题的提出 产品开发时的自测是确保产品质量的一个重要的环节,而自动测试也是提升产品质量和提升研发效率的有效途径之一. 在设计自动测试时,我们要考虑的因素包括以下方面: 第一,测试用例的充分性. 第二,代码覆盖率尽量高. 第三,每次触发时要对之前的功能进行回归测试. 第四,新增加的测试用例不能影响老的测试用例. 第五,每个测试用例针对程序的一个小功能进行测试,且各个用例不重复. 要实现对所有软件模块进行自动测试,难度是相当大的.很多开发小组尝试着让一组测试用例触发所有的模块,即将所有模块纳入一

自动化测试 之 “好用例、坏用例”

自动化测试的重要性显而易见,但自动化测试又无法解决所有问题,所以说完全依赖自动化是不可能的,但完全没有自动化是万万不能.在软件开发项目中,重度依赖人力进行持续回归是一件非常枯燥的重复工作.企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量,而队伍中的同学在每天重复劳动的工作之下,也丝毫得不到成长,看不到方向. 尽管自动化测试不能解决所有问题,但是却拥有一个优势:"Once" Written, Run Anytime as Desired(一旦写好,即可随意重复执行).所以,自

使用用例获取需求

简介: 研发都通常都使用典型场景(scenarios)来理解一个系统的需要是什么和系统是怎样工作的.不幸的是,尽管研发都已这样做了,但他极少用有效的形式归档.用例(Use-Cases)就是将这些场景获取正式化.形式化的技术. 用例是Jacobson在面象对象的软件工程中提出的,但他实际上是独立于面象对象的.用例是获取业务过程和系统需求的有效方式.而且技术本身是非常简单易学的. 使需求可被浏览 形式化场景获取是为了使用户和研发者都能浏览这些场景.所有功能需求符号都必须满足以下两条准则: 应易于需求