SDN和NFV对OSS/BSS的影响[通俗易懂]

SDN和NFV对OSS/BSS的影响

大家好,又见面了,我是全栈君。

笔者近期调研SDN/NFV影响下的OSS,之前自己知识中没有相关的积累,又一直没有比较官方的资料或者观点,所以在整理的时候遇到了瓶颈。最近在ONF网站看到了刚发布的一篇文档,对OSS/BSS在SDN/NFV时代的挑战和发展做了比较全面的总结,其中多数观点也与笔者收集到的资料相符,在这里分享给大家。

在ETSI NFV ISG提出的NFV框架中,OSS与SDN控制器分别负责不同的工作:OSS负责静态配置或者可以缓慢进行的服务特性等的配置,而NFV编排器和SDN控制器则负责动态配置以及实时的网络状态传输。尽管如此,OSS和BSS仍然会维持其全局管控的角色。

传统网络和SDN网络一个关键的不同点在于网络结构框架。如图1所示对传统网络和SDN新型网络架构进行了对比,传统网络中的NMS负责静态配置NE,配置比较缓慢,而SDN控制器则会实时对网络事件做出响应。

Figure 1 New Paradigm VS Legacy

1.OSS/BSS的市场趋势
电信业务模型和网络架构已经保持不变很多年了。但是,移动设备数量的增长,数据服务的获取,不断增加的OTT供应商的竞争,对带宽需求的急剧增长,以及对减少开销和改善效率的前所未有的压力,推动服务供应商去转变他们的网络和运营。SDN和NFV在这个转变中将会成为重要的影响因素。由SDN和NFV催生的云技术,将会减少开销,引入新的收入来源,因此成为OSS/BSS发展进程中必须要考虑的一环。

2.挑战和障碍
SDN和NFV存在着巨大的潜能,只有OSS/BSS充分适应新技术,SDN和NFV的潜在价值才能被挖掘出来。OSS与新型网络的整合和交互能力是一项重大的挑战。另外一项挑战在于,利用SDN和NFV可以提高网络利用率,提高服务质量,但会对服务管理造成一定影响,使OSS/BSS的工作负担急剧增加。在这种情况下,OSS和BSS的性能可能会出现瓶颈。
NFV的基础设施需要能够动态地对资源重新分配,来满足各种流量需求。而当前OSS系统是无法支持这种实时动态的服务的,因为:
1) 静态服务配置:当前OSS系统中,假设服务的改变并不频繁,对网络的配置是静态的。
2) 服务参数僵化固定:不只是服务类型固定,OSS的服务参数也是固定的值或是不可选择的。
3) 没有策略驱动的实时服务变更:OSS系统不允许用户或者应用驱动的实时变更。对服务任何的改变都复杂耗时。
4) 不能对包/流在细粒度时间上进行响应:OSS系统为周期性定制的服务设计,可能几年或者几个月更新,特殊情况会几周或者几天。云服务中可能会提供小时的服务周期,但是OSS和BSS系统通常不会有这样的细粒度。

上述几个方面成为当前OSS与SDN/NFV融合的障碍所在。

在SDN和NFV中,网络不再是静态的。SDN控制器会使应用或者策略动态地优化网络资源利用率。OSS系统必须要能够接受动态网络变更,为SDN控制器和NFV编排器提供自由的空间来动态的进行策略更改,同时保证支持FCAPS。

3.传统OSS架构
TM Forum列出了关键的业务功能,作为其Business Process Framework(BPF)的一部分:
1) 策略、基础设施、产品——包括规划和产品生命周期管理
2) 运营——包括操作管理的核心
3) 企业管理——包括合作或者业务支持管理

OSS在SDN时代必须能够继续支持这些业务功能。BPF全面地定义了几个分类,包括部署、保障、计费和产品生命周期。多数运营商将会将这些再细化来满足他们管理用户、系统等的需求。

OSS系统经过多年的研究实践,形成了高度定制化的平台。比如,当前的策略,基础设施和产品功能就包含规划和建设业务实例的工具集。这些工具集可以是高度整合和自动化的系统,也可以是手动维护的电子表格。

BFP提供了一个全面、完整的视角,OSS功能可分为命令管理、服务保障或者计费等。这些都是关键的业务,由供应商定制的工具集所管理,满足运营商的业务和服务需求。

4.OSS在SDN/NFV时代的需求
1) 支持动态实时管理操作:OSS要能够允许由流量环境和网络事件引发的实时网络和服务的变更。实时响应的粒度应该达到流的级别,比如,分秒。如果OSS无法支持实时响应,那么就必须支持SDN控制器来完成。
2) 网络配置和网络状态管理的分离:在传统网络中,OSS需要配置网络服务参数,对应长期的网络状态。在SDN中,服务参数必须能够实时变更,对流量的变化做出及时的响应。OSS应该配置网络的基础设施,但是允许SDN控制器能够实时地基于流对网络状态或者服务参数进行修改。
3) 支持网络服务的模型化方法:OSS应该能够支持服务模型,自动映射到设备。
4) 与网络编排平台进行交互:OSS要能够配置NFVI,但是NFV编排器将会配置实际运行在基础设施上的VNF,并且为VNF分配资源。OSS和NFV编排器要能够交互,这就涉及一个通用的策略平台和管理信息模型。
5) 与SDN控制器的交互:OSS配置SDN基础设施,包括OpenFlow交换机,SDN控制器和环境。SDN控制器负责把网络服务和业务应用策略下发到SDN网络,比如通过不断地更新和维持OpenFlow流表。OSS和SDN控制器必须能够交互,这涉及到一个通用的策略平台和管理信息模型。

5.OSS相关架构的组件

OSS与SDN/NFV相关的组件如下:
1) 通过OSS与网络编排的组合支持动态实时SDN控制器
2) 将静态网络配置任务(OSS所管理)与动态实时的网络状态管理(SDN控制器所管理)分离
3) 支持灵活的服务模型(而不是静态OSS适配器),比如接受IETF Yang模型方法
4) 支持运营商OSS与网络编排平台的交互
5) 支持运营商OSS与网络SDN控制器的交互

下图展示了基于ONFSDN架构组件和与OSS/管理组件的交互情况:

Figure 2

该图2中,紫色服务由NBI提供,紫色控制器控制了五个资源组,其中的两个是紫色所有,另外三个分别来自不同的实体。同时作为NBI的客户和D-CPI的服务器,绿色和紫色是东西向的关系,每一个都可以向另一个请求服务。

其中OSS获得抽象视图的情况还有待讨论没,但作为管理角色,OSS关心网络中所有方面。

OSS/BSS管理提供了在SDN的每一层中基于策略的配置和管理:应用、控制和基础设施层。同时,SDN应用和SDN控制器会根据OSS配置的策略实时地对网络流量做出响应。

图3中,OSS会通过SDN控制逻辑监视动态的应用,并且在OSS、SDN控制器和SDN客户与服务器环境中协调工作。

Figure 3 SDN Control Logic Detail

6.整合SDN/NFV与OSS/BSS
传统OSS和新的SDN控制器、NFV编排器会共同协作。OSS负责管理相关的静态配置参数,限制整体上对子网或者服务的资源分配。SDN控制器和NFV编排平台将会动态的管理网络资源,实时的部署服务。

OSS系统,与ETSI NFV的架构一致,必须要支持传统OSS与MANO之间的Os-Ma接口。OSS系统代表对NFVI的细粒度管理,以及VIM和VNF管理,同时也会接收NFV编排器的指令。因此,OSS负责对底层设施和网络功能的高等级配置,而NFV MANO会负责管理基础设施和服务的动态特性。

Figure 4 NFV Reference Architecture Framework

SDN控制器和应用的整合将会是类似的方法。OSS管理SDN数据平面的配置,为SDN控制器配置策略,控制SDN应用的SLA,但是SDN转发平面的动态控制由SDN控制器和SDN控制器到数据平面的接口(CDPI)管理。

图5展示了SDN架构的关键组件和与OSS系统的交互。SDN架构包括有各种SDN应用的应用平面,有一个或多个控制器的控制平面,还有SDN网元组成的数据平面。OSS/BSS管理系统根据个人用户协议为每个SDN应用控制并配置SLA参数。OSS还负责配置策略和分配资源,限制SDN控制器的功能,对SDN数据路径网元进行初始配置,比如通过OF-Config进行初始化。SDN应用会根据配置的与当前数据流相关的SLA参数适配他们的应用逻辑,并通过NBI将高等级应用指令发送给SDN控制器。NBI还能将当前的网络状态、统计数据和事件实时反馈给SDN控制器。

SDN控制器将高层应用指令翻译成底层
指令,通过南向接口发送给数据路径转发网元使用,比如按照Openflow协议进行翻译和发送。南向CDPI也能够收集数据路径网元的统计数据、告警和故障信息等SDN控制器逻辑关心的问题,并且传送到更高层的应用层和OSS中。应用层、NBI、SDN控制器和南向CDPI的组合按照策略和OSS配置的资源限制对数据路径网元进行实时、精确控制。

Figure 5 Key Components with an SDN Architecture and Interworking with OSS

关于数据中心或者基于服务的云,一些实时网络控制可以直接由DC/云编排平台提供,像OpenStack通过其Neutron Plug-in。它能够随着计算和存储资源的分配和迁移进行实时的网络变更。DC/云OSS会配置相应的网元,设置资源限制,OpenStack Neutron Plug-in负责实时管理这些资源。

7.迁移策略
服务供应商、企业正在部署基于SDN/NFV的虚拟网络架构,接下来很可能会对OSS系统进行改造。当前运营商和企业网有庞大的网络资源,很难用新型网络和全新的OSS代替所有已有的基础设施。向着SDN和NFV的演进因此从小地方着手,在某种程度上,这类似于IPv6在IPv4中的地位。新型网络会首先部署在最有价值或者需要更新的网络中。

随着新型网络的部署,OSS系统必须要同时演进,否则就不能充分利用SDN或者NFV的优势。图6描述了当今典型的网络,其中网络功能基于物理硬件,由各自的EMS所管理,网络的连接由广域网中静态EMS完成。

Figure 6 Legacy Physical Network Functions with EMS

图7展示了网络功能全部虚拟化,由NFV编排平台编排的长期演进方案。网络连接部分由整合到NFV基础设施中的SDN网络控制器提供,部分由基于物理网络的SDN提供(广域网连接)。

Figure 7 Long Term Version

从当前网络到长期演进方案的转变需要一步一步完成。图8描述了这样的一个迁移场景:网络建立在传统网络之上,有静态的广域网连接,EMS负责控制物理网络功能;在这之上建立虚拟的NFV基础设施,部署SDN连接;SDN控制器和NFV编排平台与演进的OSS平台密切合作对整个网络进行编排。

Figure 8 Migration Scenario

ETSI NFV ISG预期从长远来看,VNF完全由VNFM管理,但是在过渡阶段,仍然需要EMS连接到每个VNF来协助VNFM管理VNF。图8中展示了从广域网连接到SDN网络的级联情况,以及EMS管理物理网络功能到管理VNF的过渡情况。这个转变可以按域进行或者按服务进行。

之前OSS所管理的网络状态是静态的,配置网络使其不按照预定的策略操作,无法变更。引入了SDN后,OSS将会设置策略限制,但是不需要感知动态实时的状态转变,这种转变由SDN控制器管理。用SDN控制器来负责动态网络的控制的方法也能够最小化对当前OSS的影响。

几乎没有服务供应商或者企业能够奢侈地进行全新的部署,因此许多运营商需要独自考虑SDN的部署。在数据中心内部的连接中实现迁移,以及早期部署,使用基于Openflow的SDN来支持企业、运营商IT或者NFV服务。数据中心之间的广域网互联可以依赖于已有的IP/MPLS,能够利用当前的协议(如BGP)来传送数据中心间的服务链或者虚拟租户网络中的数据。部署用于抽象E2E路径计算的PCE和进行高效流量工程的分段路由可以增强SDN数据中心的广域网可编程能力和控制。

8.结论
SDN和NFV为运营商在节省开销、增加创新和新的收入机会方面都提供了巨大便利。为了实现这些优点,需要OSS的架构巨大转变。这意味着引入能够处理更灵活的虚拟和可编程基础设施的控制器或者编排层。

传统与虚拟化基础设施的对比特性应该从全局管理视角考量。在迁移阶段这是非常重要的,两种类型的基础设施要同时演进。因此OSS需要适应接近实时的操作,能够支持混合网络。

虚拟网元的粒度和动态实时操作将会由SDN控制器控制,而不是OSS,这样当前OSS做出的改变最小,多数需要的功能放到SDN控制器中。按照有过渡状态的演进路线,运营商在传统OSS中的投资将是有限的,并逐渐演进到通用SDN控制器和网络编排平台的运营环境。

文中有一些自己的理解,如果有所偏差或者有不同的见解,欢迎告知和讨论,谢谢。



本文转自d1net(转载)

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/108371.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • pytest fixtures_premier fixture

    pytest fixtures_premier fixturefixture的优势Pytest的fixture相对于传统的xUnit的setup/teardown函数做了显著的改进:命名方式灵活,不局限于setup和teardown这几个命名conf

  • 时序数据库 日志_mysql恢复数据库

    时序数据库 日志_mysql恢复数据库1.基础1.1时序数据的定义什么是时间序列数据(TimeSeriesData,TSD,以下简称时序)从定义上来说,就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据,简单的说,就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于IT基础设施、运维监控系统和物联网中。对时序数据进行建模的话,会包含三个重要部分,分别是:主体,时间点和测量值。套用这…

  • 云服务器和虚拟主机的区别

    云服务器和虚拟主机的区别云服务器和虚拟主机的区别:1、技术原理:云服务器是基于庞大的服务器资源池,是在一组集群主机上虚拟出多个类似独立主机的部分,集群中每个主机上都有云服务器的一个镜像;虚拟主机是服务器划分出的一部分,因此也叫做虚拟空间,在服务器当中划分出一定的磁盘空间放置web程序组件,提供数据的存放和传输功能。2、可用资源:云服务器是独享资源,具有独立的CPU、内存、硬盘和ip等;虚拟主机则是众多网站空间共享一台物理服务器的资源。3、主机费用:由于虚拟主机是多个空间分享一台服务器的带宽、IP等资源,费用低廉,价格比云服

  • pycharm画的图不弹出_Pycharm没报错但不出图

    pycharm画的图不弹出_Pycharm没报错但不出图在代码后加plt.show()如importmatplotlib.pyplotaspltimportseabornassnssns.heatmap(cm,cmap=sns.color_palette(‘Blues’),annot=True)plt.show()plt.plot(fpr1,tpr1)plt.show()

  • sql-connectionStrings「建议收藏」

    sql-connectionStrings「建议收藏」<connectionStrings><addname=”ClassReservatConnectionString”connectionString=”server=localhost;userid=root;password=123456;database=classreservat;”providerName=”System.Data.SqlClient…

  • redis过期key的删除策略[通俗易懂]

    前言在使用redis的过程中,不免会产生过期的key,而这些key过期后并不会实时地马上被删除,当这些key数量累积越来越多,就会占用很多内存,因此在redis底层同时使用了三种策略来删除这些key。第一种策略:被动删除当读/写一个key时,redis首先会检查这个key是否存在,如果存在且已过期,则直接删除这个key并返回nil给客户端。第二种策略:定期删除redis中有一系列的定期任务(serverCron),这些任务每隔一段时间就会运行一次,其中就包含清理过期key的任务,运行频率由配置文件

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号