ECOMP——增强型MANO，两大框架、两级编排、八大软件系统
作者：互联网
前言
由于工作原因，笔者曾参与分析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的未来，还有很长的路要走。
标签：VNF,软件系统,NFV,业务,ECOMP,AT&T,MANO 来源： https://blog.51cto.com/u_15127593/2744391