上傳人：扣***

認(rèn)證信息

認(rèn)證類型：機(jī)構(gòu)認(rèn)證

認(rèn)證主體：寧夏凱米世紀(jì)網(wǎng)絡(luò)科技有限公司

IP屬地：寧夏

統(tǒng)一社會信用代碼/組織機(jī)構(gòu)代碼

91640100MA774ECW4K

IP屬地：寧夏 上傳時間：2021-12-04 格式：DOCX 頁數(shù)：13 大?。?5.54KB 積分：10.8 舉報 版權(quán)申訴

1、    核心網(wǎng)nfv部署及組網(wǎng)方案的探討    李新明【摘要】為滿足移動互聯(lián)網(wǎng)時期市場和業(yè)務(wù)快速上線、頻繁迭代、定制化的需求，電信運營商引入核心網(wǎng)nfv成為必然選擇，也成為實現(xiàn)網(wǎng)絡(luò)建設(shè)低成本、高效運營的主要策略之一。本文分析了運營商部署nfv 需要解決的關(guān)鍵問題，并對vnf 組網(wǎng)、mano 部署和資源池部署方案進(jìn)行研究；最后對nfv 后續(xù)發(fā)展進(jìn)行展望。【關(guān)鍵詞】vnf 組網(wǎng)；vnf 部署；核心網(wǎng)discussion of nfv deployment and networking scheme of core networkli xin-ming（tia

2、nyuan ruixin communication technology co.， ltdxi'anshaanxi710075）【abstract】in order to meet the mobile internet market and business during the period of rapid on-line， frequent iteration and customization demand， telecom operators into core network nfv become inevitable choice， also become the n

3、etwork construction of low cost， high efficient operation of one of the main strategy. this paper analyzes the key problems that the operators need to solve in order to deploy nfv， and studies the deployment plan of vnf group network， mano deployment and resource pool. finally， the future developmen

4、t of nfv is prospected.【key words】vnf networking；vnf deployment；core network1. 前言nfv 標(biāo)準(zhǔn)化中的需求和架構(gòu)已確定，關(guān)鍵流程也基本具備， 但協(xié)議級接口流程尚未完成。截止到2014 年底，etsi 已經(jīng)完成了第一階段的工作，定義了nfv、mano 框架和功能，提供參考性的粗略流程。目前正在開展第二階段的工作，主要的工作內(nèi)容包括：mano 接口規(guī)范、加速技術(shù)、nsd 及vnf package 定義、hypervisor domain 需求。nfv 體系架構(gòu)如圖1 所示。運營商均認(rèn)可nfv 是未來發(fā)展方向， 但商用進(jìn)程

5、存在很多困難，at&t、vodafone、skt 等運營商僅進(jìn)行少量volte ims 和物聯(lián)網(wǎng)專網(wǎng)epc 的商用部署。2. nfv 部署過程中的關(guān)鍵問題2.1與現(xiàn)有it 云的差異。nfv 電信云資源池與現(xiàn)有it 云在硬件、虛擬層、管理架構(gòu)、管理維護(hù)需求、可靠性等方面均不同，滿足電信級要求的基礎(chǔ)設(shè)施構(gòu)建難度大，對于電信級云管平臺的要求也更嚴(yán)格。（1）承載的應(yīng)用不同，應(yīng)用特性也不同。（2）硬件配置要求不同。（3）對虛擬層要求不同。（4）可靠性要求不同。（5）云管理平臺要求不同。（6）資源隔離。2.2mano 和網(wǎng)管需要協(xié)同?，F(xiàn)有網(wǎng)管側(cè)重網(wǎng)元fcaps 的管理，nfv 的重點在于管理和編排

6、（資源動態(tài)管理、vnf 的編排）以及vnf 生命周期管理，nfv 云化使得對網(wǎng)元的管理分為虛擬網(wǎng)元功能的管理和云化資源管理兩部分，對網(wǎng)管體系提出全新的要求。為實現(xiàn)未來對虛擬網(wǎng)絡(luò)的端到端管理， 需mano 和oss 進(jìn)行協(xié)同。同時虛擬化網(wǎng)絡(luò)和傳統(tǒng)網(wǎng)絡(luò)會長期共存，需要由oss對虛擬化網(wǎng)絡(luò)和傳統(tǒng)網(wǎng)絡(luò)進(jìn)行協(xié)同管理，由nfvo 實現(xiàn)虛擬化網(wǎng)絡(luò)和傳統(tǒng)網(wǎng)絡(luò)業(yè)務(wù)編排。mano 和網(wǎng)管協(xié)同示意如圖2 所示。2.3標(biāo)準(zhǔn)化和接口iot。除了傳統(tǒng)的通信標(biāo)準(zhǔn)組織（etsi、3gpp），nfv 標(biāo)準(zhǔn)還涉及一些開源組織， 如openstack、opnfv 以及與sdn 相關(guān)的onf、odl、onos 等。與傳統(tǒng)電信標(biāo)準(zhǔn)側(cè)重

7、通信協(xié)議交互不同，nfv 更強(qiáng)調(diào)api 調(diào)用的軟件交互。由于涉及標(biāo)準(zhǔn)組織較多，各組織間需要配合協(xié)作，標(biāo)準(zhǔn)整體推進(jìn)困難，目前廠商產(chǎn)品及其商用進(jìn)展已快于標(biāo)準(zhǔn)化進(jìn)程，廠商為滿足部分運營商商用需求， 部分接口及流程采用私有方案；同時nfv 只是定義架構(gòu)層次， 通過協(xié)調(diào)其他開源或技術(shù)組織來實現(xiàn)對應(yīng)各個接口的具體定義，這樣與一個組織制定標(biāo)準(zhǔn)相比，技術(shù)標(biāo)準(zhǔn)的嚴(yán)密性會差一些，在保證多廠商設(shè)備兼容方面面臨很大風(fēng)險。運營商應(yīng)根據(jù)具體部署和運營需求，積極推動國際標(biāo)準(zhǔn)和廠商產(chǎn)品實現(xiàn)，并考慮在開源社區(qū)中發(fā)揮作用。2.4多廠商集成。傳統(tǒng)電信設(shè)備由電信運營商統(tǒng)一提供軟硬件一體設(shè)備及集成服務(wù)， 引入nfv 后將原來封閉的電信

8、設(shè)備商分解為多個層次：硬件設(shè)備商、虛擬化軟件供應(yīng)商、vim 軟件供應(yīng)商、vnf 軟件供應(yīng)商、nfvo（nfv orchestrator）軟件供應(yīng)商、nfv 系統(tǒng)集成商。傳統(tǒng)網(wǎng)元軟硬一體，無需縱向集成，而nfv 無論采用軟硬解耦還是三層解耦方式部署， 都需要有集成商來進(jìn)行縱向分層的集成工作， 復(fù)雜度大大提升。nfv 部署采用不同解耦方式時所需的集成工作有所不同。2.4.1采用軟硬件解耦方式部署。endprint軟硬件解耦方式部署如圖3 所示。軟硬件解耦方式， 即硬件資源層由運營商統(tǒng)一采購，有多個硬件廠商；hypervisor、vim、vnf、ems、vnfm 由vnf 廠商提供并集成；nfvo

9、與oss 可能單獨采購， 也可能由同一廠商提供。2.4.2采用3 層解耦方式部署。（1）3 層解耦方式部署如圖4 所示。（2）3 層解耦方式， 即硬件資源層由運營商統(tǒng)一采購，有多個硬件廠商；hypervisor、vim 由vim 廠商提供；vnf、ems、vnfm 由vnf 廠商提供；nfvo 與oss 可能單獨采購，也可能由同一廠商提供。運營商選定nfv 系統(tǒng)軟件集成商或自主實現(xiàn)三層的集成。與軟硬件解耦方式相比，增加vnf 與虛擬層之間的軟件集成以及vnfm 與vim 之間的接口集成，集成角色也有所變化。2.5核心網(wǎng)nfv 的電信級可靠性。2.5.1核心網(wǎng)元虛擬化后并不能降低電信應(yīng)用的可靠性

10、要求，仍需要滿足“5 個9”的可靠性，提供與電信網(wǎng)絡(luò)同樣的服務(wù)質(zhì)量和安全等級。傳統(tǒng)電信硬件通過定制化的、針對電信需求的硬件來提供高可靠性， 而nfv 整體業(yè)務(wù)端到端可靠性受限于vnf、虛擬化、硬件每一層的可靠性級別，虛擬化采用的cots 設(shè)備（“3 個9”）和開源社區(qū)軟件的可靠性相對降低。且解耦模型下傳統(tǒng)電信硬件-atca 的故障通知機(jī)制（實時精確）不復(fù)存在，故障的實時監(jiān)測和上報將依賴于各層間的交互（ha（high available）機(jī)制）。2.5.2為保證核心網(wǎng)元虛擬化后電信級可靠性，有下述要求。（1）對各層提出可靠性可用性要求（2）通過冗余配置來提高可靠性（3）進(jìn)行vnf 軟件架構(gòu)優(yōu)化（

11、4）各層故障處理聯(lián)動3. nfv組網(wǎng)方案3.1vnf 組網(wǎng)方案。3.1.1vnf 與pnf 混合組網(wǎng)。引入核心網(wǎng)nfv 后，對于傳統(tǒng)網(wǎng)絡(luò)不可能“一刀切”，全部替換，運營商應(yīng)采用先增量后存量替換的方式建設(shè)，因此在較長時期內(nèi)會存在云化網(wǎng)元（virtual network function，vnf） 和非云化網(wǎng)元（physical network function，pnf）共存的情況，以初期引入云化ims 為例，其組網(wǎng)有如下兩種方案。（1）pnf 與vnf 混合組pool。a.在pool 中pnf 與vnf 無差別，pool 組網(wǎng)方案、容災(zāi)流程與現(xiàn)網(wǎng)完全一致。未來擴(kuò)容時，可對pool 中vnf 進(jìn)行

12、擴(kuò)容或增加vnf 數(shù)量， 通過調(diào)整dns 中的權(quán)重進(jìn)行流量分類。b.需要同一套o(hù)mc 對vnf 和pnf 進(jìn)行管理， 支持對vnf 和pnf 不同軟件版本的管理和配置核查功能； 需要同一套o(hù)ss 實現(xiàn)對vnf 和pnf 的管理，在原oss 與oss/nfvo 之間同步網(wǎng)元的告警和性能信息。pnf 與vnf 混合組pool 如圖5 所示。（2）pnf 與vnf 獨立組網(wǎng)。pnf 與vnf 分別組pool，負(fù)責(zé)不同業(yè)務(wù)區(qū)域的業(yè)務(wù)，未來進(jìn)行容量擴(kuò)容時， 優(yōu)先對vnf pool 進(jìn)行擴(kuò)容。隨著vnfpool 的容量比例增加， 可能需要在擴(kuò)容時調(diào)整業(yè)務(wù)劃分，將部分用戶從傳統(tǒng)網(wǎng)元管轄區(qū)割接到虛擬網(wǎng)元管轄區(qū)

13、。建議獨立設(shè)置vnf 和pnf 的omc； 對于oss， 根據(jù)網(wǎng)管架構(gòu)而定，可以分設(shè)也可以合設(shè)。pnf 與vnf 獨立組網(wǎng)如圖6 所示。3.1.2vnf pool 相對于傳統(tǒng)網(wǎng)元pool 的優(yōu)化特性。3.1.2.1網(wǎng)元自動擴(kuò)縮容。vnf 具備自動擴(kuò)縮容特性，pool 內(nèi)網(wǎng)元為負(fù)荷分擔(dān)工作，因此pool 內(nèi)網(wǎng)元的彈性伸縮策略有如下兩種方式。（1）pool 內(nèi)網(wǎng)元擴(kuò)縮容聯(lián)動：該方式對mano 的要求較高，要求收集pool 內(nèi)網(wǎng)元的統(tǒng)計指標(biāo)后，根據(jù)預(yù)設(shè)的擴(kuò)縮容策略和算法，對pool 內(nèi)網(wǎng)元同步進(jìn)行擴(kuò)縮容。目前標(biāo)準(zhǔn)尚未定義，廠商產(chǎn)品也不支持。（2）pool 內(nèi)網(wǎng)元獨立進(jìn)行擴(kuò)縮容：同時要求pool 內(nèi)v

14、nf配置相同擴(kuò)縮容策略，包括采用的統(tǒng)計指標(biāo)和擴(kuò)縮容閾值等。由于pool 內(nèi)網(wǎng)元的負(fù)載不是百分之百相同，存在微小差異，因此該方式會存在pool 內(nèi)網(wǎng)元彈性擴(kuò)縮容不同步、短時間內(nèi)pool 內(nèi)網(wǎng)元容量不均衡的情況，但在較短時間內(nèi)可重新達(dá)到均衡，不影響網(wǎng)絡(luò)運行。3.1.2.2網(wǎng)元重生。（1）vnf 組pool 機(jī)制與基于vm ha 的vnf 重生機(jī)制結(jié)合，可提高可用性。pool+vnf 重生的倒換機(jī)制為：先啟動pool 內(nèi)倒換，與故障vnf 有連接的網(wǎng)元檢測到故障，發(fā)起倒換流程，將業(yè)務(wù)倒換到pool 內(nèi)其他網(wǎng)元。再進(jìn)行vnf 重生， 服務(wù)器出現(xiàn)故障時，vim 自動將虛擬機(jī)遷移到其他空閑vm 上， 保持

15、vm 的配置（如親和性） 和數(shù)據(jù)不變，使vnf 快速重生（單vm 的重建時間為35 min）。其他網(wǎng)元檢測到故障網(wǎng)元恢復(fù)，可發(fā)起倒回流程，或由網(wǎng)管人員手工倒回。vnf 重生示意如圖7 所示。（2）與傳統(tǒng)網(wǎng)元相比， 對于單純硬件故障引起的網(wǎng)元故障，不需人工更換硬件，通過vnf 重生大大縮短網(wǎng)元恢復(fù)時間；對于軟件故障，仍需要人工排查后進(jìn)行網(wǎng)元重啟。3.1.2.3負(fù)荷分擔(dān)策略。（1）以ims 域為例，ims 域傳統(tǒng)網(wǎng)元pool 的負(fù)荷分擔(dān)是通過dns 對pool 域名的解析實現(xiàn)的，dns 將pool 域名解析為帶優(yōu)先級和權(quán)重的pool 內(nèi)網(wǎng)元ip 地址列表，dns 中的容災(zāi)數(shù)據(jù)為靜態(tài)配置。（2）引入

16、nfv 后，由于網(wǎng)元有自動擴(kuò)縮容特性，網(wǎng)元的容量會動態(tài)變化，因此有動態(tài)負(fù)荷分擔(dān)的需求。endprint3.2mano 部署方案。核心網(wǎng)云管理平臺系統(tǒng)組網(wǎng)架構(gòu)如圖8 所示。雖然vnf 所需資源是由mano 自動部署的， 但業(yè)務(wù)網(wǎng)絡(luò)的運維架構(gòu)依然依靠傳統(tǒng)的ems/oss 機(jī)制， 因此mano 與ems/oss 之間需要協(xié)調(diào)交互， 共同完成對云化網(wǎng)元的管理。同時mano 部分功能與現(xiàn)有oss 功能有交叉。因此運營商在部署mano 時應(yīng)先做好新網(wǎng)管架構(gòu)的規(guī)劃，明確oss 與nfvo 的功能定位和未來演進(jìn)目標(biāo)。3.2.1nfvo 部署。（1）nfvo 實現(xiàn)nsd，vnffg、vnfd 的管理及處理， 網(wǎng)

17、絡(luò)服務(wù)生命周期的管理， 和vnfm 配合實現(xiàn)vnf 的生命周期管理和資源的全局視圖功能。nfvo 在網(wǎng)絡(luò)中所處的位置與oss 相當(dāng)，因此建議部署位置也與oss 相同，根據(jù)運營商未來網(wǎng)管架構(gòu)的規(guī)劃和維護(hù)管理需求，nfvo 可定制化新建或由現(xiàn)有oss 改造支持。（2）nfvo 要求連接多廠商vnfm、多廠商vim。3.2.2vnfm 部署。（1）vnfm 實現(xiàn)虛擬化網(wǎng)元vnf 的生命周期管理， 包括vnfd 的管理及處理、vnf 實例的初始化、vnf 的擴(kuò)容/縮容、vnf 實例的終止。支持接收nfvo 下發(fā)的彈性伸縮策略，實現(xiàn)vnf 的彈性伸縮。（2）目前vnfm 與vnf、ems 之間的接口為廠

18、商私有接口，無標(biāo)準(zhǔn)化計劃，因此建議vnfm 與vnf、ems 同廠商部署。部分mano 廠商也可提供genric vnfm，支持連接異廠商的vnf、ems。（3）同廠商ems 與vnfm 通常數(shù)量為11，軟硬解耦部署時，vnfm 要求支持連接同廠商多個vim；3 層解耦部署時，vnfm 要求連接多廠商vim。3.2.3vim 部署。（1）vim 是虛擬化基礎(chǔ)設(shè)施管理系統(tǒng)，主要負(fù)責(zé)基礎(chǔ)設(shè)施層硬件資源、虛擬化資源的管理，監(jiān)控和故障上報，面向上層vnfm 和nfvo 提供虛擬化資源池。同時，vim 提供虛擬機(jī)鏡像管理功能。（2）一般來說， 一個vim 對應(yīng)一套o(hù)penstack/一個區(qū)域，區(qū)域內(nèi)部根

19、據(jù)部署需求可劃分az 和ha， 區(qū)域內(nèi)實現(xiàn)資源共享、熱遷移，區(qū)域之間可以實現(xiàn)資源隔離。（3）同一dc 內(nèi)根據(jù)管理的硬件規(guī)模， 可部署多個vim，多個vim 可以同廠商也可以異廠商， 多個vim 所管理的物理服務(wù)器、存儲資源獨立，多個vim 所管理的資源可以共用組網(wǎng)設(shè)備。（4）同一dc 內(nèi)不同vim/region、多個dc 多個vim/區(qū)域可以通過多區(qū)域?qū)崿F(xiàn)共享訪問賬號和管理界面（目前是同廠商vim 可共享）。（5）vim 要求支持管理多廠商硬件； 軟硬解耦部署時，vim 要求支持連接同廠商多個vnfm；3 層解耦部署時，vim 要求支持連接多廠商vnfm。3.3資源池組網(wǎng)方案。3.3.1相對于

20、傳統(tǒng)網(wǎng)元的站點組網(wǎng)， 核心網(wǎng)nfv 資源池組網(wǎng)存在各類流量共用物理端口邏輯隔離、網(wǎng)元內(nèi)部流量需要站點組網(wǎng)設(shè)備疏通等特點。3.3.2核心網(wǎng)nfv 資源池組網(wǎng)與it 資源池組網(wǎng)架構(gòu)類似，采用層次化組網(wǎng)架構(gòu)。網(wǎng)絡(luò)出口層負(fù)責(zé)網(wǎng)絡(luò)內(nèi)部路由信息和外部路由信息轉(zhuǎn)發(fā)和維護(hù)。對外完成與外網(wǎng)設(shè)備高速互聯(lián)，對內(nèi)負(fù)責(zé)與數(shù)據(jù)中心的核心層交換設(shè)備互聯(lián)。網(wǎng)絡(luò)核心層部署核心交換機(jī)，負(fù)責(zé)接入層交換設(shè)備的匯聚，核心交換機(jī)上聯(lián)網(wǎng)絡(luò)出口層路由設(shè)備，完成與外網(wǎng)設(shè)備高速互聯(lián)。接入層包括接入交換機(jī)和接入終端設(shè)備，接入終端設(shè)備包括機(jī)架式服務(wù)器、刀片式服務(wù)器以及存儲設(shè)備。資源池分層組網(wǎng)架構(gòu)如圖9所示。3.3.3it 云資源池對于站點內(nèi)流量一般

21、分兩個物理平面：基礎(chǔ)設(shè)施平面、業(yè)務(wù)平面， 物理平面內(nèi)的不同流量采用vlan 隔離。但nfv 資源池相比it 云資源池更復(fù)雜，除基礎(chǔ)設(shè)施流量、業(yè)務(wù)流量、存儲流量外，還有網(wǎng)元生命周期管理流量，且為保證電信級可靠性，核心網(wǎng)nfv 平面隔離要求比it 云更嚴(yán)格。3.3.4根據(jù)核心網(wǎng)nfv 站點內(nèi)各類流量特點， 可分為以下幾類。（1）基礎(chǔ)設(shè)施管理流量。包括openstack 管理節(jié)點與各服務(wù)器上的代理通信的流量，對資源池虛擬資源進(jìn)行管理，在管理流量中優(yōu)先級最高；另外還有硬件管理接口，也采用獨立的物理接口。（2）其他管理流量。包括vim 與nfvo、vnfm 之間的資源管理接口；vnfm 與ems、vnf

22、、nfvo 之間的網(wǎng)元生命周期管理接口；ems 與vnf、oss 之間的網(wǎng)元應(yīng)用層網(wǎng)管接口。管理流量的流量帶寬需求較小，實時性不高，但安全級別要高于業(yè)務(wù)流量，以便于業(yè)務(wù)端口發(fā)生異常時，可以從管理端口進(jìn)行相應(yīng)的維護(hù)操作。（3）業(yè)務(wù)流量。包括vnf 內(nèi)部虛擬機(jī)之間、vnf 之間的流量，vnf 的計費和業(yè)務(wù)開通流量。業(yè)務(wù)流量的帶寬和實時性要求較高，且有信令監(jiān)測的需求。（4）存儲流量。包括vnf、mano、ems 與存儲設(shè)備之間的流量。流量帶寬在萬兆級別，實時性要求較高。3.3.5管理流量、業(yè)務(wù)流量、存儲流量的特點不同，考慮電信網(wǎng)絡(luò)可靠性，為避免相互影響，建議進(jìn)行平面物理隔離，每個平面采用獨立的服務(wù)器

23、物理網(wǎng)口和交換機(jī)，平面內(nèi)不同流量采用vlan 邏輯隔離，平面之間通過防火墻或承載網(wǎng)進(jìn)行互通。物理平面劃分示意如圖10 所示。（1）管理平面：openstack 管理節(jié)點與各服務(wù)器上的代理通信的流量； 根據(jù)維護(hù)管理要求，mano 和網(wǎng)管相關(guān)流量也可以走管理平面， 但需通過虛擬交換機(jī)，對于網(wǎng)元和虛擬層有配置要求；（2）業(yè)務(wù)平面：虛擬機(jī)之間及虛擬機(jī)對外的業(yè)務(wù)流量；endprint（3）存儲平面：虛擬機(jī)與存儲設(shè)備之間的流量。進(jìn)行物理平面隔離可以提升資源池組網(wǎng)的可靠性和安全性， 但也會增加服務(wù)器網(wǎng)口數(shù)量和交換機(jī)的配置數(shù)量，增加一定的組網(wǎng)復(fù)雜度。4. 結(jié)束語（1）傳統(tǒng)電信核心網(wǎng)引入nfv 實現(xiàn)云化， 將增

24、強(qiáng)網(wǎng)絡(luò)功能和容量的靈活性， 以更好地應(yīng)對市場和業(yè)務(wù)的快速變化。但對運營商來說，在技術(shù)、維護(hù)管理架構(gòu)、管理流程等各方面都存在挑戰(zhàn)， 對于產(chǎn)業(yè)鏈也需要進(jìn)行重新定位。（2）nfv 技術(shù)和產(chǎn)品也在逐步成熟過程中， 運營商應(yīng)先做好nfv 部署架構(gòu)設(shè)計， 基于產(chǎn)品成熟度和業(yè)務(wù)驅(qū)動引入nfv，同時考慮云化網(wǎng)元和傳統(tǒng)網(wǎng)元長期共存下的組網(wǎng)方案；應(yīng)根據(jù)具體部署和運營需求，積極推動nfv 相關(guān)技術(shù)標(biāo)準(zhǔn)的成熟；加強(qiáng)與產(chǎn)業(yè)鏈的合作，探索新的合作模式和商業(yè)模式。參考文獻(xiàn)1etsi. network functions virtualisation （nfv）； infrastructureoverview： gs nfv-inf 001s. 2015.2etsi. network functions virtualisation （nfv）； architecturalframework： gs nfv 002s. 2014.3etsi. netwo