ECOMP——增强型MANO,两大框架、两级编排、八大软件系统

SDNLAB的大表哥,某不愿透露真实身份的神秘作者

前言

由于工作原因,笔者曾参与分析ECOMP白皮书与第一版源代码,但是近几个月ECOMP又发生了很多变化,包括与Open-O合并成为ONAP,架构也随之发生很多改变,而这个阶段笔者并没有继续跟进,并且ECOMP本身非常庞大和复杂,如果文中出现谬误,也欢迎大家批评指正。

一、AT&T为什么需要ECOMP?

自2006年开始到2013年期间,AT&T业务收入基本上原地踏步。八年业务收入总共增长8%,年均复合增长率接近1%。业务收入算术平均值为1255亿美金,八年最大的上下波动幅度仅仅为-5.7%--+5.5%。尽管这八年之间业务本身经历了宽带高速增长、triple play业务大发展、移动用户爆发式增长、智能手机拉动数据业务等巨大变化,但基本上算是此消彼长,总体业务收入稳如泰山。这才是AT&T在资本市场面临的大挑战。

业务收入持续高增长无望,而持续稳定股利分红的压力就变得山大了。因此AT&T在2013年底高调宣布了Domain2.0计划,期望借助新技术新标准带来的机会,全面调整优化供应商结构,实现CAPEX大幅度压缩。也就是说,AT&T持续增长没什么希望,必然要走节支道路,新技术提供机会和手段,Domain2.0高调登台,同时画新业务机会的饼。

Domain2.0标志着 AT&T要转型成为软件公司, AT&T计划从三方面入手来落地该计划。

  • 以SDN/NFV技术为基础的云化网络架构转型
  • 从传统运营商和MVNO的商业模式向类似Google的partner分成的商业模式转型
  • 从现有的烟囱模式的组织和人力资源模型向分层的、以软件为中心的组织和人力资源模型转型

二、什么是ECOMP?


ECOMP分为两大框架(设计期框架、运行期框架),两级编排( MSO & Controller ),八大软件系统:

  • ASDC(Service Design and Creation):业务开发设计工具
  • MSO(Master Service Orchestrator):跨域业务编排
  • Cloud Controller:云基础设施资源控制器
  • SDN Controller:网络业务的快速布放
  • APP Controller :VF生命周期管理
  • DCAE(Data Collection, Analytics and Events):数据采集分析与事件上报,包含FCAPS功能
  • A&AI(Active and Available Inventory):维护全局的资源,服务及其关系的视图
  • ECOMP Common Services:提供日志,访问控制,消息总线等公共服务

ECOMP的核心理念是整合采购认证,业务设计,部署以及运维,强调整体的自动化,无码化。把运维的要素(Policy, Analytic)包含在业务设计中,整合云计算,NFV,SDN等技术,实现自动化的部署,监控,按需调整虚拟化资源来提供云服务;同时注重开放能力,开放VF资源、业务的设计能力以及策略、DCAE应用的开发能力,引入更多生态伙伴。

这里面我们提取几个关键词:无码化,自动化,开放能力

首先看一下ECOMP怎么实现无码化,ECOMP的无码化主要还是依赖于类似ODL的Model Driven思想,整个ECOMP平台分为设计期框架和执行期框架,设计期框架提供多种模型设计接口,包括: Resource,Service, Product, Offer, Policy, Process等,每种模型可以用不同的模型语言描述,可以看出ECOMP的模型驱动不仅仅是数据模型化,还有业务/编排/策略模型化。

而在设计期框架的工作完成之后,平台会把各个模型分发到对应的执行部件去执行,在不同的部件涉及到不同类型的模型,详细请见下图:

接着看一下ECOMP怎么实现自动化,传统业务流程: 专注于业务本身特性,业务部署和运维需要繁琐整合。 而ECOMP对于新业务的设计和上线有一套约束,其要求在新业务设计阶段必须考虑到后续的运维,由此加入了 Policy 和 Analytics 元素,一步到位实现部署和运维的自动化。

而ECOMP的开放能力也是一个很重要的方面,从当前第一版的代码来看,其开放的能力包括:开放的资源上线能力,开放的业务定义能力,开放的产品定义能力,开放的流程定义与策略定义能力,新的数据分析应用的开发与上线以及开放的模拟与测试能力。

三、ECOMP VS NFV MANO

ECOMP号称是增强型的MANO架构,首先我们还是先看看ETSI对于MANO的定义:

相对于传统的PNF对接EMS的架构,在做了NFV之后,除了PNF被拆分成NFVI和VNF两层,还增加了MANO框架,这其中MANO的各个部件的分工如下:

  • NFVO : 业务与资源的编排,主要提供全局的资源调度能力和全局的业务编排能力。
  • VNFM:VNF的生命周期管理(提供包括部署/扩容/缩容/下线等自动化能力)。
  • VIM:NFVI层基础设施管理系统,包括通用的物理和虚拟资源的管理(资源分配与调度,FCAPS等)。

这其中涉及到一些接口标准化问题,其中VIM和NFVI的接口由于OpenStack的开源影响力,各方已经高度一致。

Orchestrator与VNFM以及VIM层的接口由于其负责跨厂家,跨数据中心资源协同,是通用的,各方也没有分歧。

而VNFM和VNF之间的接口由于VNFM是通用的还是NFV各厂家独有的,这部分在还有较多争论,所以该部分接口尚未标准化。

AT&T号称ECOMP是一个增强型的MANO,其认为ETSI的NFV MANO架构存在两个比较大的问题:

  • 没有充分利用SDN/NFV的优势,整体视野仍然不够,仍然是一个集成商的思路(各个公司提供对应部件)
  • 没有充分实现VNF和厂商独立,接口没有充分标准化,存在厂商锁定风险

AT&T考虑到以上几点在MANO的基础上做了不少改进,包括如下的ECOMP相对于MANO的部件和接口级差别:

  • 新增开放的设计期框架,使得ECOMP只只需要关注于业务创新,无需关注运行时业务无关的执行框架;
  • ETSI NFV框架中的网管仍然负责VNF的FCAPS管理,VNFM只负责虚拟化网元的生命周期管理,ECOMP通过增加DCAE和Policy融合VNF的FCAPS管理,打破VNF和厂商EMS绑定的关系;
  • ECOMP希望标准化Ve-Vnfm和Nf-Vi接口,定下VNF和NFVI开发和对接规范,进一步避免厂商锁定

四、后续

限于篇幅,本文也只能点到为止,AT&T在电信云领域扛起了创新的大旗,现在看决心是有的,但是能不能做成,并不好说,至少从第一版的代码来看,缺陷很多,第一,代码质量比较差,有很多不规范的地方;第二,拿不出一个可以本地玩的版本,开源软件本地没法玩这一点对于开源的品牌是一个比较大的损害;总之,对于ECOMP的未来,还有很长的路要走。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/19865.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于17-09-18
0