前言

由于工作原因，筆者曾參與分析ECOMP白皮書與第一版源代碼，但是近幾個月ECOMP又發(fā)生了很多變化，包括與Open-O合并成為ONAP，架構也隨之發(fā)生很多改變，而這個階段筆者并沒有繼續(xù)跟進，并且ECOMP本身非常龐大和復雜，如果文中出現(xiàn)謬誤，也歡迎大家批評指正。

一、AT&T為什么需要ECOMP？

自2006年開始到2013年期間，AT&T業(yè)務收入基本上原地踏步。八年業(yè)務收入總共增長8%，年均復合增長率接近1%。業(yè)務收入算術平均值為1255億美金，八年最大的上下波動幅度僅僅為-5.7%--+5.5%。盡管這八年之間業(yè)務本身經歷了寬帶高速增長、triple play業(yè)務大發(fā)展、移動用戶爆發(fā)式增長、智能手機拉動數(shù)據(jù)業(yè)務等巨大變化，但基本上算是此消彼長，總體業(yè)務收入穩(wěn)如泰山。這才是AT&T在資本市場面臨的大挑戰(zhàn)。

業(yè)務收入持續(xù)高增長無望，而持續(xù)穩(wěn)定股利分紅的壓力就變得山大了。因此AT&T在2013年底高調宣布了Domain2.0計劃，期望借助新技術新標準帶來的機會，全面調整優(yōu)化供應商結構，實現(xiàn)CAPEX大幅度壓縮。也就是說，AT&T持續(xù)增長沒什么希望，必然要走節(jié)支道路，新技術提供機會和手段，Domain2.0高調登臺，同時畫新業(yè)務機會的餅。

Domain2.0標志著 AT&T要轉型成為軟件公司， AT&T計劃從三方面入手來落地該計劃。

 ● 以SDN/NFV技術為基礎的云化網(wǎng)絡架構轉型

 ● 從傳統(tǒng)運營商和MVNO的商業(yè)模式向類似Google的partner分成的商業(yè)模式轉型

 ● 從現(xiàn)有的煙囪模式的組織和人力資源模型向分層的、以軟件為中心的組織和人力資源模型轉型

二、什么是ECOMP？

ECOMP分為兩大框架（設計期框架、運行期框架），兩級編排（ MSO & Controller ），八大軟件系統(tǒng)：

 ● ASDC(Service Design and Creation)：業(yè)務開發(fā)設計工具

 ● MSO(Master Service Orchestrator)：跨域業(yè)務編排

 ● Cloud Controller：云基礎設施資源控制器

 ● SDN Controller：網(wǎng)絡業(yè)務的快速布放

 ● APP Controller ：VF生命周期管理

 ● DCAE(Data Collection, Analytics and Events)：數(shù)據(jù)采集分析與事件上報，包含F(xiàn)CAPS功能

 ● A&AI(Active and Available Inventory)：維護全局的資源，服務及其關系的視圖

 ● ECOMP Common Services：提供日志，訪問控制，消息總線等公共服務

ECOMP的核心理念是整合采購認證，業(yè)務設計，部署以及運維，強調整體的自動化，無碼化。把運維的要素（Policy，Analytic）包含在業(yè)務設計中，整合云計算，NFV，SDN等技術，實現(xiàn)自動化的部署，監(jiān)控，按需調整虛擬化資源來提供云服務；同時注重開放能力，開放VF資源、業(yè)務的設計能力以及策略、DCAE應用的開發(fā)能力，引入更多生態(tài)伙伴。

這里面我們提取幾個關鍵詞：無碼化，自動化，開放能力。

首先看一下ECOMP怎么實現(xiàn)無碼化，ECOMP的無碼化主要還是依賴于類似ODL的Model Driven思想，整個ECOMP平臺分為設計期框架和執(zhí)行期框架，設計期框架提供多種模型設計接口，包括：Resource，Service, Product, Offer, Policy, Process等，每種模型可以用不同的模型語言描述，可以看出ECOMP的模型驅動不僅僅是數(shù)據(jù)模型化，還有業(yè)務/編排/策略模型化。

而在設計期框架的工作完成之后，平臺會把各個模型分發(fā)到對應的執(zhí)行部件去執(zhí)行，在不同的部件涉及到不同類型的模型，詳細請見下圖：

接著看一下ECOMP怎么實現(xiàn)自動化，傳統(tǒng)業(yè)務流程: 專注于業(yè)務本身特性，業(yè)務部署和運維需要繁瑣整合。 而ECOMP對于新業(yè)務的設計和上線有一套約束，其要求在新業(yè)務設計階段必須考慮到后續(xù)的運維，由此加入了 Policy 和 Analytics 元素，一步到位實現(xiàn)部署和運維的自動化。

而ECOMP的開放能力也是一個很重要的方面，從當前第一版的代碼來看，其開放的能力包括：開放的資源上線能力，開放的業(yè)務定義能力，開放的產品定義能力，開放的流程定義與策略定義能力，新的數(shù)據(jù)分析應用的開發(fā)與上線以及開放的模擬與測試能力。

三、ECOMP VS NFV MANO

ECOMP號稱是增強型的MANO架構，首先我們還是先看看ETSI對于MANO的定義：

相對于傳統(tǒng)的PNF對接EMS的架構，在做了NFV之后，除了PNF被拆分成NFVI和VNF兩層，還增加了MANO框架，這其中MANO的各個部件的分工如下：

 ● NFVO：業(yè)務與資源的編排，主要提供全局的資源調度能力和全局的業(yè)務編排能力。

 ● VNFM：VNF的生命周期管理（提供包括部署/擴容/縮容/下線等自動化能力）。

 ● VIM：NFVI層基礎設施管理系統(tǒng)，包括通用的物理和虛擬資源的管理（資源分配與調度，F(xiàn)CAPS等）。

這其中涉及到一些接口標準化問題，其中VIM和NFVI的接口由于OpenStack的開源影響力，各方已經高度一致。

Orchestrator與VNFM以及VIM層的接口由于其負責跨廠家，跨數(shù)據(jù)中心資源協(xié)同，是通用的，各方也沒有分歧。

而VNFM和VNF之間的接口由于VNFM是通用的還是NFV各廠家獨有的，這部分在還有較多爭論，所以該部分接口尚未標準化。

AT&T號稱ECOMP是一個增強型的MANO，其認為ETSI的NFV MANO架構存在兩個比較大的問題：

 ● 沒有充分利用SDN/NFV的優(yōu)勢，整體視野仍然不夠，仍然是一個集成商的思路（各個公司提供對應部件）

 ● 沒有充分實現(xiàn)VNF和廠商獨立，接口沒有充分標準化，存在廠商鎖定風險

AT&T考慮到以上幾點在MANO的基礎上做了不少改進，包括如下的ECOMP相對于MANO的部件和接口級差別：

 ● 新增開放的設計期框架，使得ECOMP只只需要關注于業(yè)務創(chuàng)新，無需關注運行時業(yè)務無關的執(zhí)行框架；

 ● ETSI NFV框架中的網(wǎng)管仍然負責VNF的FCAPS管理，VNFM只負責虛擬化網(wǎng)元的生命周期管理，ECOMP通過增加DCAE和Policy融合VNF的FCAPS管理，打破VNF和廠商EMS綁定的關系；

 ● ECOMP希望標準化Ve-Vnfm和Nf-Vi接口，定下VNF和NFVI開發(fā)和對接規(guī)范，進一步避免廠商鎖定

四、后續(xù)

限于篇幅，本文也只能點到為止，AT&T在電信云領域扛起了創(chuàng)新的大旗，現(xiàn)在看決心是有的，但是能不能做成，并不好說，至少從第一版的代碼來看，缺陷很多，第一，代碼質量比較差，有很多不規(guī)范的地方；第二，拿不出一個可以本地玩的版本，開源軟件本地沒法玩這一點對于開源的品牌是一個比較大的損害；總之，對于ECOMP的未來，還有很長的路要走。