前言
由于工作原因，笔者曾参与分析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的未来，还有很长的路要走。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
