帶你讀《ONAP技術詳解與應用實踐》之一：網絡自動化挑戰及ONAP介紹

點選檢視第二章 點選檢視第三章

ONAP技術詳解與應用實踐

任旭東　著

第1章

網絡自動化挑戰及ONAP介紹

什麼是ONAP？營運商在網絡轉型中遇到的挑戰是什麼？雲服務廠商和OTT服務商在其網絡自動化實踐中有何經驗可以借鑒？為什麼ONAP是電信産業網絡自動化領域最有前景的開源實作方式？本章試圖從以上幾個問題入手，逐漸揭開ONAP的神秘面紗。

在介紹ONAP之前，我們先來了解網絡在自動化演進過程中面臨的挑戰。

1.1　網絡自動化演進的挑戰

自貝爾于1876年2月14日在美國專利局申請電話專利權，這一百多年來電信基礎設施網絡飛速發展。時至今日連接配接超過50億移動使用者的電信行業已徹底改變了世界。它讓我們彼此相連，帶給我們娛樂、傳遞給我們新聞，給予我們靈感。長期以來，電信營運商都是引領社會數字化的弄潮兒，是自動化的引領者。近年以來，網際網路服務商，尤其是公有雲巨頭們憑借強大的軟體能力，實作了高度自動化的基礎設施運維模式，大大提升了勞動生産率。相對而言，營運商們的網絡運維和營運模式卻變化不大，自動化水準不高，效率提升不明顯，在同OTT争奪未來ICT基礎設施服務市場的競争中處于不利地位。主要原因為：

（1）受組織架構和技術水準等的限制，如今的電信網絡仍然主要靠人工來管理，自動化程度不高。

大量工作需要人來手動完成，導緻業務發放時間長，業務無法及時上市；運作過程中故障平均恢複時長讓使用者無法忍受。這些都影響了網絡靈活和終端使用者體驗。

一方面，營運商在部署新業務時，往往需要數月甚至更長的時間，這嚴重影響了電信業務的創新效率；另一方面，在網絡運維中心，工程師們不僅每天監控着成千上萬的告警，還要建立故障單來跟蹤問題的解決過程。運維工程師必須經過專業教育訓練才能使用軟體系統執行日常任務。他們未必清楚如何增強軟體以适應不斷變化的需求，還可能受限于不支援定制功能的軟體。由于手動操作的單調性和重複性，常年累月，運維人員會失去動力，枯燥的工作會導緻嚴重的運維人員流失。

依賴重複的手工流程展現在：操作人員要麼把相應的步驟寫入手冊，要麼将其形成個人知識庫。但即便手冊說明足夠詳細，操作人員經驗足夠豐富，依賴手工流程也容易出錯。不精準的分析和不正确的配置所帶來的風險極高，甚至可能會帶來服務中斷、收入損失和客戶流失等問題。

（2）煙囪式的運維模式使得網絡無法全生命周期統一管理，網絡運維不可視，故障無法實時感覺。

營運商目前使用的大多數運維支撐軟體（OSS）都是基于封閉的軟體架構設計的。這些架構基于不同領域部署，進而形成一個個運維孤島，使得軟體變更周期不可控，新業務的上市時間長，網絡跨域故障無法快速修複。可以毫不誇張地說：“我們使用的是21世紀的4G網絡、光纖網絡，甚至5G商用已經此起彼伏，但網絡自動化程度在某種意義上還停留在20世紀。我們很多的運維工具和手段讓人感覺身處石器時代。”

運維組織的層級化、地域化嚴重阻礙了網絡自動化程度。例如，通常有三個層級的客戶服務和網絡運維，這也是煙囪式軟體和流程式煙囪的一個表現，并且在級與級之間存在大量的手動切換。典型的運維模式是按照國家、省、地市等行政地域來進行的，網絡雖然全程全網打通，信令可達，但是運維指令是被局限在這些行政區域之内的，嚴重依賴人為協調、溝通、審批等工單流程，實際上是無法自動化完成一條跨省電路實施的。除去基本的語音業務以外，其他業務在不同區域的業務體驗、運維體驗也都是不連續的，最終導緻使用者在不同地域會明顯感覺到差異。

（3）網絡擴容的計劃模式難以适應業務的變化，難以實時響應業務訴求。

随着業務種類、數量的快速變化，對網絡本身的彈性也提出了更高的要求。資源的自動擴縮可以有效節省成本，比如在業務的低谷期可以将資源降下來，在業務高峰期可以自動擴容。每年的春晚以及其他一些大型活動期間，在短時間内會召回大量平時不活躍的使用者，給網絡帶來數倍于日常的流量。可以說網絡的重大事件服務保障堪比一場重大戰役，需要調動各種資源并準備各種預案以應對。

另外，突發業務訴求和流量變更也往往需要營運商網絡随之快速适配。但現實中，大部分業務仍然無法實作按需調整。業務能否按需調整直接關系到已有客戶的黏性和新客戶的拓展。總體來說，目前這樣的彈性調配在營運商網絡中還很難完全自動化實作。

（4）營運支援系統複雜且支離破碎，缺乏統一平台和架構，導緻網絡轉型難以成功。

面對越來越複雜的業務，面對越來越多樣化的使用者需求，從初期機房中的幾十台裝置發展到如今龐大的資料中心，單靠人工已經無法滿足技術、業務、管理等方面的要求。自動化、架構優化、過程優化等降低運維成本的因素越來越被人們所重視。

從2000年開始，營運商已開啟網絡轉型之路。然而，轉型并不容易。由于種種原因，超過80%的轉型最終無法完全實作既定目标。全球一大批營運商接連開展了一波又一波的轉型實踐，但是目前為止，還沒有走出一條清晰且公認成功的轉型之路。

從運維管理支撐系統角度來看，無論是早期的ITU-T的TMN的五層模型，還是後來TMF（電信管理論壇）的NGOSS的eTOM模型，以及再後來演化的ZOOM模型等，帶給産業界的依然是各種煙囪林立的、割裂的、定制化的資訊孤島，而且年複一年積累下來，每個大型電信營運商無不積累了數百套甚至上千套這樣的系統，它們每個都有具體的用途，但沒有一個人能把全部系統的關系說清楚，更談不上自動化打通各系統間的資料流和業務流。這也是轉型不容易的原因之一。

面對電信産業的衆多挑戰，要提高成本效益和品質，營運商需要探索創新的自動化模式。電信營運商參考其他行業的優秀自動化實踐，包括OTT廠商、雲服務提供商、标準産業組織和開源産業組織，希望從其他行業汲取經驗，以便建立更加靈活的網絡自動化模式。在自動化的基礎上，還可以引入AI，增加更多網絡智能化及網絡自動駕駛的能力。

1.2　網絡自動化商業實踐

1.2.1　AT&T的網絡自動化實踐

AT&T是全球技術實力最強的電信營運商之一，ECOMP是AT&T為實作網絡轉型而新設計的自動化平台，全稱是Enhanced Control, Orchestration，Management & Policy（增強的控制、編排、管理與政策）。

2016年ECOMP正式上線，到2016年年底支撐AT&T實作網絡虛拟化比例到30%，在接下來的兩年中ECOMP持續擴充，到2018年年底，AT&T公開表示完成了65.5%的網絡虛拟化。

2017年AT&T基于ECOMP平台開源了OpenECOMP項目，2018年OpenECOMP和Open-O合并形成ONAP。

ECOMP的架構圖（見圖1-1）主要由兩部分組成：一部分是用于對業務進行設計、定義和編碼的設計态環境；另一部分是自動執行設計态輸出結果（業務邏輯及政策驅動的閉環工作流）的運作态環境。

ECOMP的設計态主要子產品如下：

• 業務設計和建立（AT&T Service Design & Creation）是一個內建了工具、技術和資源庫的開發環境，用來定義、仿真、認證AT&T的網絡資産及其關聯流程和政策。
• 政策建立（Policy Creation）是設計政策的工具。政策關注引發動作的特定條件，輸出機器可讀的規則，定義基于觸發或請求的動作。
• 分析應用設計（Analytic Application Design）是設計大資料分析應用的平台，輸出的應用可以運作在DCAE平台上。

  

ECOMP的運作态主要子產品如下：

• 主業務編排器（Master Service Orchestrator，MSO）是一個高層工作流執行器，其自動按順序執行建立、修改或移除網絡/應用或基礎設施服務和資源所需的活動、任務、規則和政策。
• 控制器（Controllers）是居于雲和網絡之上，執行配置、實時政策，并控制分布式元件和業務狀态的應用。AT&T并沒有使用一個龐大的控制層，而是分别使用三個控制器來管理指定控制域：雲計算資源（基礎設施控制器，通常在雲上）、網絡配置（網絡控制器）和應用（應用控制器）。
• 資料收集、分析和事件（Data Collection，Analytics and Events，DCAE）是個支援分析和事件的架構型元件。它收集性能、使用率和配置資料；進行計算分析；輔助進行排障；公布事件、資料并分析資料。
• 活動和可用資源庫（Active and Available Inventory，A&AI）提供資源、業務及其相關實時“自頂向下”視圖，展現了一個客戶所買産品與組成這些産品的原材料所構成的資源關系。A&AI不僅登記了業務和資源，還維護了互相關系視圖。

ECOMP聚焦如下三個核心能力：

• 使能新業務：ECOMP平台創新性地改進了新業務上線方式，使得AT&T、網絡Vendor、OSS內建商、第三方應用開發者、雲服務提供商等可以基于一套平台（ECOMP）工作，顯著提升了新業務上線的自動化水準，使得AT&T能快速擴充面向雲消費者和企業業務的産品組合，增加AT&T網絡對客戶的價值。
• 政策驅動客戶體驗保障：ECOMP平台通過支援對網絡、業務和容量進行準實時政策驅動的自動化再配置來提升客戶體驗。
• 端到端生命周期管理：ECOMP平台為營運商在實時工作負載情況下的産品/業務提供設計、建立和生命周期管理的能力。

1.2.2　網際網路企業的網絡自動化實踐

大型網際網路企業建設和維護着一張覆寫全球、連接配接大量資料中心的網絡。他們一般開發自己的自動化平台來運維網絡，以降低故障、提升效率。

Google的DevOps理念的核心是用軟體來自動化重複的工作，進而使運維者的精力可以主要用來開發軟體。Facebook和Alibaba的自動化工具比較類似，都是采用模型驅動的方式來自動化網絡配置。

網際網路企業的理念和技術思路對電信産業有借鑒意義，故這裡進行簡單介紹。

1. Google的DevOps運維實踐

Google的産品和服務是全球部署的，通常沒有時間和人力像其他組織一樣手動維護系統，是以Google更傾向于在其系統中實作自動化。Google的運維團隊把大部分時間用于開發自動化平台。

Google認為自動化的價值在于一緻性、平台性和自愈性。

• 一緻性：展現在自動化系統可以無數遍地、一緻性地執行範圍明确且步驟已知的程式。而任何個人或者群體在執行數百次重複動作過程中，不可能保證每次都以相同的方式進行，因為沒有人能像機器一樣永遠保持一緻。不一緻性會導緻錯誤和疏漏，以及其他可靠性問題。這在電信行業尤為重要。
• 平台性：是指自動化的系統可以提供一個可以擴充的、廣泛适用的平台。一個平台可以将錯誤集中化，修改一個錯誤就意味着該錯誤被永遠修複。一個平台更容易被擴充，進而執行額外的任務，這顯然比給人賦能并讓人去執行更容易。此外，平台通過越來越多的可視化手段，可以暴露自身的各項名額，幫助人們發現流程中的細節，并在過程中衡量這些細節和名額。
• 自愈性：采用自動化系統解決常見故障，由于平台對問題和故障可以自動感覺，故平台可以基于已有經驗或者預置政策實作常見故障自動化修複。這樣可以明顯降低常見故障的平均修複時間（MTTR）。在Google的基礎設施中，自動化系統應用廣泛，能夠快速響應對服務的變化和支援。

2. Facebook的自動化平台Robotron

Robotron主要是在業務發放方面，将運維人員的運維意圖自動翻譯成異構的裝置配置。除了配置之外，Robotron還承擔管控的角色，即需要實時掌控網絡的配置部署情況，防止網絡的部署與規劃産生偏差。如圖1-2所示，Robotron的功能覆寫于整個網絡的管理周期：網絡設計→配置生成→部署→監控。

Robotron資訊完全依賴于FBNet抽象層，FBNet将對整個網絡，包括網絡實體或邏輯元件，進行面向對象的模組化，比如裝置、端口、鍊路、IP位址等。基于這個網絡抽象模型對象，運維人員可進行網絡設計（Network Design）、配置生成（Config Generation）、部署（Deployment）和監控（Monitoring）。

• 網絡設計：主要是确定各種網絡資源對象的拓撲和關聯關系，設計的輸出是對目标網絡的抽象。
• 配置生成：基于網絡設計的輸出，配置生成子產品可以根據裝置的廠商和型号資訊，自動生成裝置的配置腳本。這個子產品要針對不同的裝置類型來開發對應的配置生成子產品。
• 部署：部署是配置下發的工作流，為了消除配置下發的風險，需要完成裝置初始狀況的比較确認、配置任務的原子化（同一個時間段隻有一個操作）、配置的校驗、配置的復原等工作。
• 監控：監控是通過收集裝置的實時配置，生成網絡的實際狀态，以确認網絡配置被正确下發，确認網絡運作狀态與抽象層相符合。

從Robotron平台我們可以學習到抽象模組化和Top-Down的思路，用抽象模型來表述目标配置，用Top-down的方式來生成具體的配置。

3.阿裡NetCraft網絡配置自動化實踐

阿裡開發的NetCraft主要是為了解決網絡變更的配置問題，以降低人工操作引起的故障。NetCraft也用模型的方式來描述網絡的配置。阿裡認為網絡模型要滿足四個要素：

• 可解釋性：網絡模型的可描述性，即要深入到網絡的方方面面，包括連通性、協定層，隻有資訊足夠全，才是高品質的模型。
• 互操作性：網絡模型要能友善地轉換為網絡配置，反之亦然。這個是基于意圖網絡模型的技術底座。
• 靈活性：操作粒度要原子化，并支援下發、復原等操作，隻有将業務意圖解構為足夠細的原子化操作，才能保證自動化工作的平滑切換。
• 獨立性：網絡模型要能屏蔽多廠商之間的差異。

NetCraft網絡模型的關鍵設計就是其多圖層機制。NetCraft的設計思路是将網絡自下而上劃分為多個圖層：最底層是實體層，包含網絡裝置的實體連結關系，可以包含裝置名稱、LLDP、ETH-Trunk資訊；實體層之上是IP層，包含接口的IP位址資訊；再之上是各種協定圖層，如BGP、OSPF、ISIS、MPLS。NetCraft會為所有的路由協定單獨建構一個圖層。不同圖層之間的關聯是通過裝置接口、裝置自身等圖層間共享的實體實作的，BGP和OSPF圖層之間通過IP圖層的三層IP接口相關聯的。

在屬性定義方面，NetCraft和Robotron一樣，所有的屬性都是依存于網絡圖層中的各種實體。NetCraft的這種多層圖機制易于了解，能達成良好的可解釋性。

NetCraft的架構如圖1-3所示。

網絡操作者的主要工作是設計目标網絡模型（Target Network Model），配置生成器（Configuration Generator）負責解析目标網絡模型，并結合預定義的配置模闆，将目标網絡模型轉換為對應的裝置配置指令。遷移規劃器（Transition Planner）根據目标模型要修改的配置，計算上述多個圖層之間的配置依存關系，通過精心設計的業務編排來達成業務的平滑部署。配置下發（Configuration Executer）結合目标配置和切換規劃，進行具體配置的逐漸下發，每下發一步都會檢測網絡狀态，如果異常則復原。模型生成器（Model Generator）将配置逆向解析回運作網絡模型（Running Network Model），用于網絡診斷工作。

可以看到，NetCraft同Robotron的整體架構和思路是非常類似的，都是Top-down的思路。NetCraft的多層網絡模組化和關聯關系模組化也值得借鑒。

1.2.3　網絡裝置廠商的自動化系統

業界領先的網絡裝置廠商，比如華為、思科，一般也會提供比較強大的網絡管理工具，尤其是在電信專用裝置領域，比如光網絡（SDN、OTN）、接入網絡（DSL、PON）、無線網絡（2G、3G、4G、5G）、電信核心網（IMS、EPC）等，廠商提供的網管軟體普遍支撐圖形化界面、端到端的業務自動發放、告警管理、性能管理等功能。

對于最新興起的SD-WAN解決方案，網絡控制器一般都提供CPE裝置的自動開局（即插即用）功能和業務自動化發放（即Zero-touch-provisioning）功能。

最近幾件，SDN概念的興起，簡化了分布式控制，采用集中化路由技術和控制的方式提升網絡效率。比如采用Segment Routing技術來簡化MPLS的控制器，采用BGP協定來集中控制和排程流量。是以廠商提供的軟體工具往往是管理和控制融合的産品。比如華為公司的NCE是SDN增強型“管理、控制和分析一體化內建”的新産品。

廠商提供的網絡裝置管理和控制軟體，除提供GUI界面外，也提供API接口。使用者可以直接在GUI上進行網絡配置，也可以通過API內建到電信營運商的綜合網管系統裡。

大部分場景下，廠商提供的管理軟體是必不可少的，尤其是電信網絡，其裝置數量、規模巨大，讓OSS層面的系統直接管理裝置是不現實的。而利用廠商的管理軟體，把一張大規模的複雜網絡抽象成一個相對簡單的網絡是大有好處的。

本書介紹的ONAP平台，主要是通過對接廠商管理軟體的API，進行網絡對象的抽象資源模組化，以實作全網範圍内的業務自動化。

1.3　開放網絡自動化平台—ONAP

ONAP（Open Network Automation Platform）項目是Linux基金會下的一個開源項目，2017年4月由OpenECOMP和OPEN-O項目合并而來。

1. OpenECOMP

2017年2月，AT&T正式向Linux基金會貢獻ECOMP（增強控制、編排、管理和政策）平台的業務無關的代碼，進而形成OpenECOMP開源項目。

2. Open-O

Open-O是2016年年初在中國移動、華為和Linux基金會的倡導下發起的協同器開源項目，該項目得到首批15家企業成員的支援，包括中國電信、南韓電信、中興通訊、Intel、愛立信、GigaSpaces、InfoBlox、Red Hat等。這個項目也是由Linux基金會管理的。

2016年11月7日，Open-O正式釋出了Open-O 1.0版本，該版本名稱為Sun。

3. ONAP

為了聚集産業力量，減少産業分裂，共同打造網絡自動化的準事實标準，開源項目Open-O和OpenECOMP經過多次接觸，最終達成合并協定，2017年4月，新項目誕生，并正式改名ONAP。

ONAP是電信産業聯合打造的一個網絡自動化平台，會員覆寫了全球領先的營運商、裝置制造商、IT企業、晶片公司、網際網路廠商和雲服務商等。

ONAP繼承了原來OpenECOMP項目及Open-O項目的主要成員，其中營運商會員覆寫全球移動使用者超過70%，成員包括AT&T、中國移動、中國電信、中國聯通、Orange、Vodafone、加拿大Bell等。ONAP廠商成員包括華為、Juniper、思科、愛立信、Giga-Spaces、IBM、英特爾、Metaswitch、微軟、新華三、諾基亞、Raisecom、Reliance Jio、Tech Mahindra、VMware、Wind River和ZTE等。

2018年，ONAP成為網絡開源項目LFN（Linux Foundation Networking，Linux網絡基金會）旗下的項目之一。截至2019年3月，ONAP已經擁有110多個會員，已發展成為電信産業規模最大且最具影響力的開源社群之一。

關于Linux基金會和LFN

Linux基金會（Linux Foundation，LF），是一家非營利性組織，緻力于圍繞開源項目建構可持續的生态系統，以加速技術開發和行業采用。Linux是開源軟體項目曆史上規模最大、應用範圍最廣的項目。除Linux外，LF作為業界頂級開源基金會，還積極監管了許多成功的開源項目，包括Xen、KVM、CNCF、Hyperledger等。ONAP也是其中之一。

2018年1月LF宣布成立LFN項目，将旗下多個面向網絡領域的開源項目合并。目前LFN擁有七個網絡開源項目，分别是ONAP、OPNFV、OpenDaylight、FD.io、PNDA、SNAS.io和Tungsten Fabric。LFN成立旨在協調目标相似的開源項目，消除不同項目之間的重疊或備援，并建立更高效的流程，加快其工作。LFN為各項目之間的合作提供一個平台，同時保證技術上的獨立性。

LFN中的七個項目構成了從資料平面到控制平面、編排、自動化和端到端測試的網絡堆棧的基礎，ONAP自身與LFN中的項目聯系緊密，尤其是開源控制器項目ODL（OpenDayLight）及端到端測試項目OPNFV。

ONAP定位為一個開源的自動化平台和程式設計架構，旨在通過為大規模的實體和虛拟網絡裝置提供全局的編排功能來解決傳統模式因規模和成本帶來的挑戰。ONAP平台為實體和虛拟網絡功能提供了一個模型驅動的業務編排和政策驅動的實時閉環自動化平台。ONAP平台可以快速自動化部署新業務，并支援全生命周期管理。

ONAP的目标是打造與業務、廠商無關的自動化業務使能平台，解決營運商數字化轉型面臨的挑戰。ONAP平台核心能力包括：

• 實作網絡靈活性、彈性和自愈能力，實時感覺和響應業務訴求。
• 使營運商或第三方能近乎實時地重新配置網絡、編排服務和擴縮容量，縮短新産品上市時間。
• 成為全生命周期管理高度動态化的網絡與軟體系統，實作可視化。

ONAP自動化目标是閉環自動化，覆寫設計→建立→收集→分析→檢測→釋出→響應，覆寫業務全生命周期閉環自動化，各種關鍵角色，如供應商、網絡設計人員、網絡運維人員，在同一流程和自動化平台上銜接，顯著減少人工幹預以提升工作效率：

• 供應商：按需提供相應産品包後，能自動上線到營運商的ONAP系統。
• 網絡設計人員：完成對業務的規劃設計後（包括對新增業務的設計或對已有業務的設計、修改），支援新業務自動部署與發放，并在後續的運維全流程中自動響應網絡和資源狀況變化而無須人工介入。
• 網絡運維人員：從後期重複繁重的維護工作中解放出來，一旦完成對特定運維動作的規劃設計，則後續此類運維工作即可自動進行，運維人員可把時間花在更有創造性的工作中，比如針對不在規劃範圍内的異常進行總結分析，給出新的規劃設計後部署實施，不斷提升網絡維護效率。

圖1-4所示從較高層級示意了閉環自動化及業務生命周期内不同階段的自動化。

ONAP通過提供一套通用、開放、可互操作的北向REST接口來同營運商的OSS/BSS系統內建，南向可以與多個VIM、VNFM、SDN控制器甚至傳統網絡裝置的內建來支援各種網絡環境。ONAP采用标準模型，降低了異構裝置的內建和部署成本，同時最大限度地減少了管理的碎片化。在ONAP平台上，網絡營運商和他們的網絡/雲業務提供商可以在一個動态、閉環的過程中進行協作，執行個體化網絡裝置和業務，并對操作類事件進行實時響應。

ONAP源代碼遵循Apache 2.0協定，文檔遵循Creative Commons Attribution 4.0 Interna-tional Public License，隻要給出适當的署名即可自由分享和演繹，詳見附錄A。總之，ONAP遵循的協定是比較寬松的許可協定，這使得為ONAP做貢獻和将其作為商業使用非常友善。

ONAP項目官網：

https://www.onap.org/

ONAP項目Wiki：

https://wiki.onap.org/

ONAP社群貢獻：

https://onap.biterg.io/

Apache 2.0協定：

http://www.apache.org/licenses/LICENSE-2.0

1.4　ONAP版本路标及關鍵特性

ONAP的版本命名按照英文字母A～Z排序，每個版本選用不同的世界城市命名，社群計劃每6個月釋出一個版本。截至2019年3月，共釋出了3個版本、分别是Amsterdam版本、Beijing版本和Casablanca版本。最新版本Casablanca（簡稱C版本）包含了30多個項目，C版本新增代碼總量60多萬行，代碼送出12萬次以上，開發者超過500，參與代碼貢獻的組織30多個，社群貢獻持續活躍。最新版本Dublin版本預計在2019年6月釋出。目前，ONAP社群規劃的前6個版本的釋出時間如圖1-5所示。

1.4.1　Amsterdam版本

作為ONAP的第一個版本，Amsterdam版本于2017年11月16日釋出。該版本基于統一的體系架構，整合了來自OpenECOMP和OPEN-O的代碼。

Amsterdam版本為兩個場景提供了經過驗證的藍圖。第一個藍圖是VoLTE（Voice Over LTE），它允許通過虛拟化核心網絡把語音業務統一在IP網絡上進行處理。ONAP用于設計、部署、監控端到端VoLTE業務以及生命周期管理。第二個藍圖是Residential vCPE（面向家庭的寬帶接入業務），它通過ONAP部署基于虛拟化技術的網絡寬帶接入服務，這意味着CSP可以快速并按需向家庭客戶提供新服務。

Amsterdam版本提供如下功能子產品：

（1）Portal：基于不同的使用者角色，在設計态和運作态提供一緻的使用者體驗。

（2）設計态架構（Design-time Framework）：一個全面的開發環境，包含用于定義或描述網絡資源、網絡服務和産品需要的工具、技術和存儲庫。其包括如下元件。

• 業務設計和建立（SDC）：提供網絡業務設計和建立人員所需的工具，用于定義、模拟、認證網絡服務、網絡資産及與其相關的自動化處理流程和政策。
• VNF軟體開發套件（VNFSDK）：提供給VNF供應商的VNF打包和驗證的工具。
• 政策建立（Policy）：提供給網絡政策的建立和管理人員的工具，提供了建立和驗證政策/規則、識别政策重疊、解決政策沖突及根據需要派生其他政策的功能。
• 閉環自動化管理平台（CLAMP）：提供了設計和管理自動化控制閉環的方法和工具。

（3）運作态架構（Run-time Framework）：運作态架構執行由設計态架構分發的配置、規則和政策，以及與管理對應的控制器。

• Service Orchestrator（SO）：執行指定的基礎設施服務工作流，自動建立、修改或删除服務所需的資源、規則、政策和配置。
• SDN控制器（SDN-C）：執行網絡領域的資源配置和管理。
• 應用程式控制器（APPC）：執行虛拟網絡功能（VNF）配置和生命周期管理操作。
• 虛拟功能控制器（VF-C）：執行網絡業務（NS）的配置和生命周期管理，同時使用VNF Manager來執行VNF的配置與生命周期管理操作。
• 活動和可用資源庫（A&AI）：提供系統資源、服務、産品及與其相關的實時視圖。

（4）閉環自動化：設計→建立→收集→分析→檢測→釋出→響應。

• 資料收集、分析和事件（DCAE）：收集事件、性能、使用情況，并将資訊釋出到與執行閉環操作相關的部件（如SO）以觸發政策。其子項目Holmes将收集到的資訊與A&AI中的對象關聯，為電信基礎設施和服務提供告警關聯分析。
• 公共服務：保障ONAP元件正常營運的服務，包括活動記錄、報告、通用資料層、通路控制、彈性和軟體生命周期管理等部分。

1.4.2　Beijing版本

Beijing版本于2018年6月7日釋出。在Beijing版本中，社群聚焦平台和閉環自動化增強，以確定可擴充性、安全性、穩定性和性能，并支援實際部署。該版本擴充平台支援容器化部署，并為虛拟VNF開發人員、服務設計人員和營運維護人員提供強大的文檔支援。

Beijing版本增強了如下元件：

• External API：該元件從北向內建角度提高和TMF标準的互操作性，有利于同BSS的內建。
• ONAP Operations Manager（OOM）：提供了基于Kubernetes托管雲環境的ONAP安裝和部署功能，大大簡化了ONAP的安裝部署流程。
• Multi-site State Coordination Service（MUSIC）：提供跨站點的高可用基礎服務，支援ONAP擴充到多站點環境，以支援全球規模部署的基礎架構要求。
• ONAP Optimization Framework（OOF）：ONAP優化架構提供了一種聲明式、政策驅動的方法，用于建立和運作優化應用程式，如位置歸屬、部署和變更管理排程優化。

Beijing版本增強了如下特性：

資訊模型、工作流和政策模型：增強了對相關标準的遵從，包括ETSI NFV MANO、TM Forum SID、OASIS TOSCA、IETF和MEF等。

• 變更管理（Change Management）：支撐虛拟網關（vG）VNF的更新工作流程和自動化。
• 硬體平台感覺（Hardware Platform Awareness）：通過感覺容量、位置、硬體能力的差異，将資源（如VNF等）置于正确的雲/區域（HPA定義DPDK、SR-IOV等規則）。
• 手動觸發的自動擴縮（Auto-scaling out with manual trigger）：手動觸發系統橫向擴充或縮小，以應對變化的容量或負載需求。

1.4.3　Casablanca版本

Casablanca版本于2018年11月30日釋出。Casablanca進一步增加了ONAP的可部署性，引入了新的應用場景藍圖CCVPN，不僅支援虛拟網元（VNF），而且支援實體網元（PNF）和新的工作流編排工具。

Casablanca版本增加了元件Post Orchestration Model Based Audit（POMBA）：該元件基于事件驅動，對業務的設計态屬性、運作态屬性和網絡真實的屬性進行交叉對比，生成審計報告。

Casablanca版本增加了如下特性：

• 從7個次元繼續提升ONAP的軟體品質：穩定性、安全性、可擴充性、性能、彈性、可管理性和可用性。
• 簡化ONAP安裝和部署：使用Kubernetes（Docker和Helm Chart技術）簡化安裝，OOM支援可插拔的存儲，為使用者提供更多存儲選項。
• 引入新場景藍圖：支援5G新藍圖，新增CCVPN藍圖（結合OTN與SD-WAN的企業VPN專線業務）。
• SDC支撐兩個新的設計工具：DCAE Design Studio和SO Workflow Designer。
• 支援ETSI NFV-SOL003标準。
• DCAE：支援與Linux Foundation的PNDA項目內建，作為對CDAP的補充。
• A&AI：通過提供曆史資料來支援審計功能。
• External API：繼續與TMF（圍繞ServiceOrder）和MEF API（圍繞Legato和Interlude API）協調，以簡化與OSS/BSS的內建流程。
• CLAMP：提供了新儀表闆功能，用于在設計态和運作态檢視DMaaP和其他事件，友善Close Loop閉環自動化的調試。

1.4.4　Dublin及後續版本展望

社群Dublin版本截至本書截稿前還處在開發階段，計劃于2019年6月正式釋出。

Dublin版本将繼續朝着ONAP商用部署的目标努力，不會引入新的元件，目前已經收集了30多個需求，其中增強5G use case、BBS use case等處于較高優先級，特性增強方面包括：變更管理擴充；5G需求、PNF發現、參數支援、算法、模型配置；VNF擴縮容增強；核心服務、VNF生命周期管理狀态和轉換模型等。

1.5　ONAP與相關标準開源組織協同

ONAP一直在緊跟标準組織在SDN/NFV方面的進展，并在實施過程中盡量遵循與繼承标準已有成果，比如ETSI、MEF、TMF、IETF、3 GPP、BBF等。同時，ONAP還與許多開源社群開展了協同工作，典型的有OpenStack、Kubernetes和OPNFV等。

1.5.1　ONAP與ETSI NFV

歐洲電信标準組織（European Telecommunications Standards Institute，ETSI）是電信産業具有全球影響力的電信裝置和網絡标準制定者。ETSI NFV是2012年在ETSI下面專門成立的聚焦在NFV相關架構和接口定義的産業标準組（Industry Specification Group），是NFV領域的标準權威組織。

ETSI NFV定義的NFV架構如圖1-6所示。

ETSI NFV的标準定義聚焦在VNF和NS（Network Service）的生命周期管理，也就是圖1-6中右邊方框内所示的MANO（NFVO和VNFM在一起的統稱）的相關架構和接口。

從功能範疇上來說，ONAP的範圍遠遠大于MANO的範疇，ONAP要解決的是全部網絡基礎設施端到端的自動化運維問題，而MANO僅關注NFV的生命周期自動化。

在架構和實作上，ONAP的VF-C子產品相當于ETSI的NFVO功能，而VNFM子產品一般由廠商來實作，VIM子產品一般由雲平台供應商來實作。ONAP同廠商特有的VNFM和VIM的內建接口都遵循ETSI NFV的相關标準（SOL003、SOL005等）

ONAP在VNF的資訊模型和SO、VF-C子產品的接口上遵循ETSI NFV的相關标準。

ETSI VNF的相關标準還在持續演進中，還有很多标準沒有定稿，ONAP同ETSI VNF的關系是互相促進，互相影響的。ONAP的開源實作可能領先于ETSI的标準制定，并促成ETSI相關标準的成熟。

1.5.2　ONAP與MEF

城域以太網論壇（MEF）是2001年成立的一個專注于解決城域以太網專線業務技術标準的非營利性組織。最近幾年MEF的工作重點轉移到推動營運商的數字化轉型和業務标準定義上來。MEF根據使用者和營運商之間的消費關系提出了LSO（Lifecycle Service Orchestration，生命周期服務編排）的概念和對應的參考架構。

如圖1-7所示，在一個營運商的域内（SP Domain），從上到下分别有：

• Business Application：商務相關的系統，對應傳統的BSS系統，以及客戶關系、報價、計費等系統。
• Service Orchestration Functionality：業務編排功能，進行網絡業務的完整生命周期管理，包括建立、修改、保障、修複和終結等。
• Infrastructure Control and Management：基礎設施的控制和管理，比如雲管理平台、SDN控制器、MANO等軟體系統（一般由裝置商提供軟體系統）。
• Element Control and Management：網元的控制和管理（裝置商實作）。

2017年11月，ONAP宣布同MEF達成合作，一起推動網絡業務的靈活營運。在MEF的LSO參考架構裡面，ONAP實作了Service Orchestration Functionality的功能。ONAP的External API項目會參考LSO的LEGATO、INTERLUDE、PRESTO的接口标準。

在Casablanca版本的CCVPN用例中，在External API（北向接口項目中）支援跨營運商的企業以太專線定義中，參考了MEF的Interlude（MEF中定義的，用于Service Orche-strator間互動接口的API标準名）接口标準。

1.5.3　ONAP與TMF

TMF（TeleManagement Forum，電信管理論壇）是一個為電信營運和管理提供政策建議和實施方案的世界性組織，是專注于通信行業OSS（Operations Support Systems，運維支撐系統）和管理問題的全球性非營利性社團聯盟。TMF提出的NG OSS（New Generation Operations Systems and Software，下一代運維系統）功能模型，包括TOM（Telecom Opera-tions Map，電信營運圖）和eTOM（enhanced Telecom Operations Map，增強電信營運圖），被國際電信營運商、裝置制造商及電信營運支撐系統開發商廣泛接受，成為事實上的國際标準。

TMF的Open API計劃是一項全球性計劃，旨在實作跨複雜生态系統服務的端到端無縫連接配接及其互操作性和可移植性。該計劃正在建立一個Open API套件，該套件是一套基于REST的标準API，可在營運和管理系統之間實作快速、可重複和靈活的內建，進而更輕松地建立、建構和營運複雜的創新服務。

2018年3月，ONAP與TMF宣布正式合作，以確定開放API成為ONAP等關鍵開源項目的一部分。TMF開放API成為ONAP Beijing版本（2018年6月釋出）的重要組成部分。在ONAP的Casablanca版本的CCVPN用例中，External API（北向接口項目中）實作對TMF接口标準的架構支援，包括為了實作跨ONAP的通信，支援了TMT 641（Service Order API，業務訂單接口）标準，後續還會支援TMF 633（目錄接口）、TMF638（業務狀态變更通知）等标準接口。

1.5.4　ONAP與IETF

IETF（Internet Engineering Task Force）負責網際網路标準的開發和推動。IETF制定了TCP、IP、MPLS等關鍵網際網路協定。

IETF面向SDN各技術領域開展标準化工作，IETF的SDN參考架構已基本成為SDN的主流标準架構。

IETF定義了網絡配置模型語言YANG，并且定義了很多網絡資源和業務模型，比如L3VPN、L2VPN、L1VPN等。

SDN控制器北向接口的配置模型，一般會遵照IETF模型。ONAP同SDN廠商進行對接時，一般采用IETF定義的RestConf接口和對應的YANG模型。

在Casablanca版本的CCVPN用例中，ONAP同OTN控制器的接口采用了IETF定義的ACTN（Abstraction and Control of TE networks）相關标準，包括拓撲模型、業務模型等。

1.5.5　ONAP與3GPP

3GPP（3rd Generation Partnership Project，第三代合作夥伴計劃）是1998年全球各大标準組織為了協同3G标準合作建立的組織。3GPP成立後就成為無線通信領域的權威組織，并制定了WCDMA、TD-SCDMA等3G标準，以及4G标準LTE和最新的5G标準。

2018年3GPP釋出了首個5G标準版本R15，标志着世界正式進入5G時代。

4G改變生活，5G改變社會。5G的基站網絡規模會大大超過4G的；5G大量采用虛拟化技術來實作核心網業務；5G要求支援網絡切片（Network Slicing）；5G的基站分成DU和CU等，這類新的特點導緻5G的自動化運維成為一個很大的挑戰。

5G是ONAP的一個核心應用場景，5G藍圖是ONAP持續多個版本的藍圖。

3GPP也成立了專門的工作組來研究5G同ONAP內建的運維架構。

1.5.6　ONAP與BBF

BBF（Broadband Forum，寬帶論壇）是1994年成立的全球标準組織，聚焦在定義寬帶接入的相關技術，比如DSL和PON等。

BBF近年來積極推動把NFV引入電信機房，提出CloudCO（Cloud Central Office）架構。

ONAP社群的vCPE和BBS兩個藍圖，都是聚焦在未來的家庭寬帶業務場景，相關标準參照BBF。

以上介紹了ONAP與部分标準組織的合作，接下來介紹ONAP與幾個主要開源社群開展的協同工作。

1.5.7　ONAP與OpenStack

OpenStack是目前最主流的開源雲計算基礎設施管理平台，目标是幫助服務商和企業内部實作類似于Amazon EC2和S3的雲基礎架構服務（Infrastructure as a Service，IaaS）。

電信營運商的NFVi基礎設施普遍采用OpenStack作為雲作業系統，提供虛拟機的編排管理和虛拟網絡資源的配置管理等功能。

ONAP從第一個版本開始就在MultiVIM項目中支援與OpenStack的內建，多數元件也同時支援通過OpenStack的Heat腳本進行部署管理。從Beijing版本開始ONAP支援通過OOM內建的Kubernetes實作容器化部署與管理。

1.5.8　ONAP與Kubernetes

Kubernetes（簡稱K8s）是Google開源的一個容器編排引擎，目前是CNCF（Cloud native Computing Foundation，雲原生雲計算基金會）基金會下面的項目。K8s是叢集中負責管理跨多台主機容器化應用的開源系統，支援自動化部署、大規模可伸縮、應用容器化管理，其目标是讓部署容器化的應用簡單且高效。

K8s目前已是面向雲原生的應用，是容器化部署場景的最熱門的開源項目，尤其是從VNF向CNF演進的過程，K8s被認為是預設配套。

ONAP在很多項目中都在開展與K8s的內建，包括Multi-VIM項目、OOM項目等。OOM對ONAP的支援就是通過K8s實作的，使用了Rancher、Helm、Kubectl等元件。

1.5.9　ONAP與OPNFV

OPNFV（Open Platform for NFV）是2014年9月在Linux基金會下成立的一個開源項目，專注于加速NFV的發展，其目标是建立一個營運商級的、內建的開源參考平台。營運商與廠商共同推進NFV的演進，確定多個開源元件之間的一緻性、性能和互操作性。

OPNFV的工作範疇是建構NFV基礎設施（NFVi），虛拟化基礎架構管理（VIM），并将應用程式可程式設計接口（API）包括在其他NFV元素中。這些NFV元素一起構成了虛拟網絡功能（VNF）和管理、網絡編排（MANO）元件。OPNFV有望提高性能和功率效率，提高可靠性、可用性和可維護性。

截至2018年11月，OPNFV共釋出了7個版本，OPNFV項目能夠很好地與上下遊的開源項目緊密合作，共同促進NFV的發展和應用。

OPNFV是一個內建型的開源項目，成立多年，在NFV和NFVi的功能測試、性能測試上積累了大量的測試工具和測試用例。

2018年OPNFV成立OPNFV Verified Program（OVP）認證項目，針對商用VIM産品進行認證。

LFN成立以後，ONAP對NFV的認證和OPNFV對VIM的認證将統一運作，在LFN成立統一的CVC（Compliance andVerification Committee）進行管理。

1.6　營運商部署實踐進展

ONAP得到了全球主要大型營運商的支援，很多營運商都成立了專門的ONAP團隊，對ONAP進行測試、驗證和試點，或者基于ONAP進行商業版本開發，把ONAP引入到生産環境裡面。到本書截稿時為止，基于部分營運商在ONAP社群中的公開資訊，進展彙總如下。

1.美國電信電報公司（AT&T）

AT&T的網絡自動化生産系統ECOMP就是ONAP在其生産系統中的應用。AT&T已經商業化部署的新業務，比如Network On Demand、5G實驗網，都是基于ONAP進行的。AT&T采用社群優先（ONAP First ）戰略，生産系統對平台的新需求優先在ONAP社群開發，保證生産系統和ONAP版本的同步更新。

AT&T自身有很強大的軟體開發和架構能力，對ONAP的商業開發其仍然引入了商業合作夥伴（如Amdocs、Tech Mahindra等公司），共同推動ONAP在自身網絡中的落地。

AT&T的網絡技術演進的完整戰略還包含引入人工智能和邊緣計算，與此相對應，它也在主動推進兩個新開源項目：聚焦網絡人工智能的Acumos AI項目和聚焦邊緣計算的內建軟體棧項目Akraino。同時AT&T也在積極推進ONAP同Acumos和Akraino的內建、協同。

2.中國移動

自2017年年初加入ONAP社群以來，中國移動一直積極參與并為社群做貢獻，現擔任技術指導委員會的副主席，參與架構設計，在多個核心子產品積極貢獻代碼。中國移動還設有ONAP實驗室，并負責管理。

在ONAP的第一版本中，中國移動在社群釋出了核心網的用例VoLTE，初步驗證了ONAP的端到端的業務能力；在第二版本中驗證了CPE用例；在第三版本中，聯合沃達豐和華為推出CCVPN用例，以實作跨營運商、跨域、跨層的VPN業務連接配接。目前團隊仍在進行CCVPN用例的擴充工作，比如多站點業務的建立、業務修改、AI應用的自動部署等，希望借助該用例，進一步增強ONAP平台的能力。

着眼于下一代網絡的主要場景，依托于下一代網絡的關鍵技術，中國移動基于開源社群ONAP的開源版本，自主研發了用于營運商網絡設計編排、自動化和智能化運維管理的商用産品。2018年8月，在浙江部署整套ONAP環境，并進行了技術驗證；2018年11月份在陝西省進行商用測試，從一階段測試結果看，對外接口已經可以滿足企标要求，目前正在進行二階段性能、可靠性等測試。2019年将與5G規模試驗網同步，支援切片和子網切片的編排與管理。

3.中國電信

中國電信參考ONAP架構研發的網絡服務編排器已在現網應用。對于重點業務，如雲網協同和智能專線等，中國電信在積極研究基于ONAP平台來編排智能專線業務并積極推動試點。同時，中國電信在國際網絡CTGNet中也積極嘗試ONAP的應用與部署。中國電信也投入專門團隊研究和貢獻ONAP社群項目，承擔了社群Benchmark項目相關工作并進行S3P驗證測試。後續中國電信也将繼續積極跟進ONAP社群，尋求商業合作夥伴，将其作為面向CTNet2025的核心網絡營運系統引擎，提升網絡的自動化、智能化水準。

4.中國聯通

中國聯通基于ONAP開源代碼積極開展産品創新，自研開發IPRAN+骨幹網跨域編排器，實作了跨網絡領域、跨地市和跨廠家的統一業務編排與網絡協同。在社群方面，中國聯通積極參與并貢獻相關項目，牽頭完成ONAP白皮書中文版翻譯工作，推動ONAP相關接口标準的商業實踐，緻力于ONAP中國社群及相關産業的發展和壯大。

5.法國電信（Orange）

法國電信把ONAP作為實作集團OSS簡化和網絡自動化戰略的關鍵措施并堅定推行。法國電信明确要求從2019年起，所有的招标書都會把ONAP作為必選項。2018年，法國電信聯合華為在生産環境公有雲上驗證了SD-WAN業務的自動化。

2019年是法國電信推動ONAP落地的關鍵年，法國電信為此專門發出了ONAP夥伴标書，尋找商業夥伴，為法國電信提供定制開發、系統內建和業務設計服務，并計劃在西班牙子網開展現網試點。

6.加拿大Bell電信（Bell Canada）

加拿大Bell電信也是最早把ONAP引入到商業生産環境的電信營運商之一。從ONAP第一個版本（Amsterdam）開始，Bell就把ONAP用于虛拟化基礎設施層（NFVi）的自動化和商業SD-WAN業務的自動化，其SD-WAN業務已經推向市場。

加拿大Bell計劃逐漸把ONAP推廣到整個營運商網絡，包含有線、無線、骨幹網、資料中心等。Bell對ONAP的商業化途徑也是尋求與商業合作夥伴共同開發，需要商業合作夥伴提供定制開發、內建和業務設計等服務。

7.沃達豐（Vodafone）

沃達豐積極參與了ONAP的CCVPN Blueprint的驗證。沃達豐是一個全球營運商，在很多國家擁有獨立營運的子網，沃達豐的自動化戰略是為每個國家子網引入基于ONAP的商業編排器，并要求所有子網的編排器必須相容ONAP的外部接口，并能夠實作多個國家編排器之間的互聯互通。

8.土耳其電信（Turk Telekom）

土耳其電信計劃基于ONAP第三個版本（Casablanca）進行商業化部署，推出SD-WAN業務。

從中國三大營運商到歐洲大T，再到北美的領先營運商，全球很多電信營運商正基于ONAP開展商用部署實踐活動，或是基于ONAP的架構重構自己的網絡OSS系統，以期在未來的網絡自動化浪潮中保持先進地位。在這個如火如荼的過程中，中國的營運商和裝置廠商也正在發揮越來越重要的作用，在未來網絡自動化程序中必将占有一席之地。

1.7　本章小結

本章首先介紹了網絡自動化演進的曆史和挑戰，介紹了AT&T的自動化實踐，以及網際網路廠商的相關實踐。

ONAP是電信産業集中力量應對網絡自動化挑戰的産物，ONAP為實體和虛拟網絡功能提供了一個模型驅動的業務編排和政策驅動的實時閉環自動化平台，可以快速自動化部署新業務，并支援全生命周期管理。本章簡單介紹了ONAP要解決的問題及其解決思路，并介紹了目前幾個ONAP版本的演進情況，以期讀者對ONAP有一個初步的認識。

本章還簡單介紹了ONAP同一些标準組織和開源組織的關系，這些知識有利于讀者在一個很大的架構下了解ONAP的功能和角色。

本章最後還介紹了全球營運商基于ONAP開展的實驗和部署實踐。