初探數通網絡開放可程式設計簡介

文章目錄

• ​​網絡運維面困難與挑戰​​

• ​​行業趨勢​​
• ​​面臨困難​​

• ​​數通網絡可開放程式設計簡介​​

• ​​應用場景​​

• ​​多廠商裝置快速适配​​
• ​​新業務快​​
• ​​網絡變更可靠​​
• ​​管控析全棧可程式設計​​

• ​​特性介紹​​

• ​​動态加載軟體包​​
• ​​事務機制​​
• ​​資料一緻性​​
• ​​使用者開放程式設計​​
• ​​支援配置預覽​​

• ​​支援配置校驗​​

網絡運維面困難與挑戰

行業趨勢

5G時代，網絡運維面臨越來越多的挑戰。從價值目标來說，網絡運維是從節約成本到收益的轉變，網絡運維更像是流量管理。傳統的網絡運維是典型的“人流量”人工運維模式，具有半人工半自動化的特點，也在朝着全自動化的目标努力演進。網絡運維首先要改變的是傳統的思維方式，從開發運維分離到開發運維一體化。這就要求營運商運維部門具備DevOps能力，網絡運維将從傳統的CT運維走向多元化的ICT運維。

在雲計算快速發展的時代，OTT通過雲原生架構保障雲服務體驗的設計理念深刻影響了營運商的網絡建設模式。無論是營運商強調雲前自下而上的網絡，還是自上而下的OTT網絡，戰略選擇差異背後共同的驅動因素是企業的數字化轉型正在加速雲網絡融合的需求。網絡與雲的融合意味着營運商和企業都需要根據自己的需求靈活定制，以滿足未來的業務場景。

面臨困難

在傳統的“人流量”人工操作維護模式下，操作人員面臨以下痛點：

• 營運商網絡陷入多廠商裝置管理的困境。廠商裝置多元化是營運商和企業避免被套牢的長期政策。但是單個廠商控制器隻能管理自己的網絡裝置，沒有統一的接口标準與OSS系統內建。随着新裝置的增加，适配效率取決于制造商的能力和響應速度，這限制了端到端網絡服務自動化的發展。長期以來發展緩慢，已經成為業内公認的瓶頸。
• 新業務推出慢，周期短需要等半年，長的需要等一兩年，不能滿足新時代的要求。新業務推出緩慢的原因有很多，其中一個原因是新業務是以傳統的開發和運維分離的方式推出的：營運商首先提出新的服務需求，各種裝置廠商開發釋出版本，營運商重新接受使用，整個過程持續很長一段時間。
• 網絡裝置适配和網絡割接工作需要手動執行海量指令行腳本，容易出錯。随着腳本規模的增加，其可維護性也持續下降，使得網絡運維逐漸成為一個高風險職業。
• 顯然，這種基于單一廠商配置和基線的網絡管控理念已經不能滿足營運商日益靈活靈活的運維需求，開放可程式設計的多廠商網絡管控解決方案應運而生。

  

  圖表 1 傳統的“人流量”人工操作維護模式

數通網絡可開放程式設計簡介

面對網絡運維的嚴峻挑戰，開放可程式設計系統以YANG模型驅動為基礎，提供了端到端的開放可程式設計能力：裝置驅動可程式設計、網絡業務可程式設計、開放裝置和業務北向接口，并且提供了安全可靠的保障機制。

圖表 2 适合人群

應用場景

多廠商裝置快速适配

營運商和企業網絡一般都有多廠商裝置共存的場景(如多廠商5G站自動上線、多廠商CPE配置等)。缺乏統一的管理和控制。新裝置內建慢，自動化程度低，開通周期長，成為端到端業務傳遞的瓶頸。開放式可程式設計系統通過YANG接口自動識别并讀取裝置的YANG模型檔案，生成網元驅動包并加載到系統中，一天即可完成一個新的裝置适配管，适配效率提高90%。

新業務快

新服務的推出依賴于OSS系統和廠商控制器的版本更新，受API接口內建不足、定制成本高的問題困擾，導緻推出周期長，難以滿足業務場景靈活變化的需求。開放式可程式設計系統支援自定義業務YANG模型和業務邏輯，自動生成北行API接口，實作與OSS系統的快速內建，完成裝置和網絡服務的添加、删除、修改和檢查等操作。開發時間從6-9個月釋出縮短到1個月按需釋出，業務上線周期縮短80%。

網絡變更可靠

存量網絡運維存在大量業務遷移變更的訴求，基本依賴人工操作或指令行腳本，出錯率高。海量腳本維護困難，網絡變更風險高，正确率難以保證。開放可程式設計系統提供Dryrun、復原、事務、并發等安全可靠機制保障，網絡變更正确率提升到99.9%。

管控析全棧可程式設計

面對5G網絡切片與智能運維的場景，基于使用者自定義網絡業務模型，除了實作業務發放可程式設計外，開放可程式設計系統還提供控制算路與智能分析可程式設計能力，最大程度支援營運商業務面向未來網絡演進。

圖表 3以Windows為例，客戶對網絡操作平台能力訴求

特性介紹

動态加載軟體包

通過編寫和加載軟體包，實作新裝置的快速納管和新業務的快速建構。

圖表 4 AOC開放可程式設計平台所需具備的架構和能力

系統提供的軟體包包括：

2. SND包：網元驅動包（Specific NE Driver Pkg），為開放可程式設計系統提供與網元互動的資料模型。該資料模型通常包含一個.py檔案和若幹特性的資料模型（YANG），前者用于定義網元的相關資訊，如裝置類型、廠商、連接配接資訊等，後者描述了網元相關特性的資料結構。系統通過加載網元驅動包，可以和裝置建立連接配接，進行資料查詢和配置下發，實作裝置納管。支援的SND包類型包括：NETCONF SND、CLI SND、NETCONF&CLI雙協定SND、RESTCONF SND和Customized SND（提供YANG到其它協定的通用驅動）。
3. SSP包：業務包（Specific Service Plugin Pkg），定義了完成一套網絡級業務配置對應的資料模型。該資料模型通常包含一個Jinja2模闆檔案、一個Python映射腳本和業務YANG模型。其中：

• Jinja2模闆描述了業務的資料結構，并使用Jinja2文法完成了諸如插值、條件判斷、循環等操作。
• Python映射腳本描述了如何将使用者送出的資料填充到模闆，并映射到網中繼資料結構中。
• 業務YANG模型描述了業務的相關參數，按照業務輸入，建構業務YANG模型。
• 系統通過加載業務包，可以進行業務配置下發，實作新業務的快速建構。

圖表 5 Yang模型驅動

事務機制

系統提供了事務機制，配置變化支援在一個原子事務裡送出，保證開放可程式設計系統中的資料和轉發器的資料一緻性。同一個事務裡的資料會并發下發到多台裝置，要麼全部成功，要麼全部回退，沒有部分資料成功。

圖表6事務機制:失敗自動復原，保障配置安全

資料一緻性

開放可程式設計系統儲存了下發到裝置資料的副本，能夠采集裝置資料，發現裝置資料和開放可程式設計系統上資料的差異并在界面呈現，可以以開放可程式設計系統為準或者以裝置為準進行資料同步。

圖表 7 資料一緻性:多頭管理及時發現

使用者開放程式設計

• 支援RESTCONF和CLI等北向接口，支援基于Python腳本在開放可程式設計系統上開發新的能力。
• 支援模型驅動的程式設計接口。使用者在編寫SSP包（業務包）時，使用系統提供的EasyMap算法，隻需要寫建立流程，更新和删除都由算法比較計算得出，簡化使用者程式設計，降低開發難度。
• 支援YANG模型自動生成南向封包，提升驅動開發效率。

  

  圖表8 Mapping：支撐極簡代碼

支援配置預覽

對于配置到開放可程式設計系統上的資料，在下發到裝置前，使用者可以進行配置預覽，檢視将要下發到裝置上的封包以及新舊配置資料的差異資訊。

圖表 9 配置預覽

支援配置校驗

使用者配置到開放可程式設計系統上的資料可以基于YANG模型以及YANG模型提供的檢查文法，進行相關的配置校驗檢查。

圖表10 高效的業務配置

圖表 11 資料溯源:配置可追溯

圖表 12 配置曆史:曆史操作完全掌控

參考文檔

1. 數通可開放程式設計快速入門

​Start.html">​https://devzone.huawei.com/cn/enterprise/aoc/quickStart.html​​

1. 數通可開放程式設計文檔中心

​​https://devzone.huawei.com/cn/enterprise/aoc/apiDoc.html​​

1. 專家講解：數通網絡開放可程式設計的架構和能