李新明
【摘要】為滿足移動(dòng)互聯(lián)網(wǎng)時(shí)期市場和業(yè)務(wù)快速上線、頻繁迭代、定制化的需求,電信運(yùn)營商引入核心網(wǎng)NFV成為必然選擇,也成為實(shí)現(xiàn)網(wǎng)絡(luò)建設(shè)低成本、高效運(yùn)營的主要策略之一。本文分析了運(yùn)營商部署NFV 需要解決的關(guān)鍵問題,并對(duì)VNF 組網(wǎng)、MANO 部署和資源池部署方案進(jìn)行研究;最后對(duì)NFV 后續(xù)發(fā)展進(jìn)行展望。
【關(guān)鍵詞】VNF 組網(wǎng);VNF 部署;核心網(wǎng)
Discussion of NFV deployment and networking scheme of core network
Li Xin-ming
(Tianyuan 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 network 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 development of NFV is prospected.
【Key words】VNF networking;VNF deployment;Core network
1. 前言
NFV 標(biāo)準(zhǔn)化中的需求和架構(gòu)已確定,關(guān)鍵流程也基本具備, 但協(xié)議級(jí)接口流程尚未完成。截止到2014 年底,ETSI 已經(jīng)完成了第一階段的工作,定義了NFV、MANO 框架和功能,提供參考性的粗略流程。目前正在開展第二階段的工作,主要的工作內(nèi)容包括:MANO 接口規(guī)范、加速技術(shù)、NSD 及VNF package 定義、Hypervisor Domain 需求。NFV 體系架構(gòu)如圖1 所示。
運(yùn)營商均認(rèn)可NFV 是未來發(fā)展方向, 但商用進(jìn)程存在很多困難,AT&T、Vodafone、SKT 等運(yùn)營商僅進(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ù)需求、可靠性等方面均不同,滿足電信級(jí)要求的基礎(chǔ)設(shè)施構(gòu)建難度大,對(duì)于電信級(jí)云管平臺(tái)的要求也更嚴(yán)格。
(1)承載的應(yīng)用不同,應(yīng)用特性也不同。
(2)硬件配置要求不同。
(3)對(duì)虛擬層要求不同。
(4)可靠性要求不同。
(5)云管理平臺(tái)要求不同。
(6)資源隔離。
2.2MANO 和網(wǎng)管需要協(xié)同。
現(xiàn)有網(wǎng)管側(cè)重網(wǎng)元FCAPS 的管理,NFV 的重點(diǎn)在于管理和編排(資源動(dòng)態(tài)管理、VNF 的編排)以及VNF 生命周期管理,NFV 云化使得對(duì)網(wǎng)元的管理分為虛擬網(wǎng)元功能的管理和云化資源管理兩部分,對(duì)網(wǎng)管體系提出全新的要求。為實(shí)現(xiàn)未來對(duì)虛擬網(wǎng)絡(luò)的端到端管理, 需MANO 和OSS 進(jìn)行協(xié)同。
同時(shí)虛擬化網(wǎng)絡(luò)和傳統(tǒng)網(wǎng)絡(luò)會(huì)長期共存,需要由OSS對(duì)虛擬化網(wǎng)絡(luò)和傳統(tǒng)網(wǎng)絡(luò)進(jìn)行協(xié)同管理,由NFVO 實(shí)現(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è)重通信協(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)程,廠商為滿足部分運(yùn)營商商用需求, 部分接口及流程采用私有方案;同時(shí)NFV 只是定義架構(gòu)層次, 通過協(xié)調(diào)其他開源或技術(shù)組織來實(shí)現(xiàn)對(duì)應(yīng)各個(gè)接口的具體定義,這樣與一個(gè)組織制定標(biāo)準(zhǔn)相比,技術(shù)標(biāo)準(zhǔn)的嚴(yán)密性會(huì)差一些,在保證多廠商設(shè)備兼容方面面臨很大風(fēng)險(xiǎn)。
運(yùn)營商應(yīng)根據(jù)具體部署和運(yùn)營需求,積極推動(dòng)國際標(biāo)準(zhǔn)和廠商產(chǎn)品實(shí)現(xiàn),并考慮在開源社區(qū)中發(fā)揮作用。
2.4多廠商集成。
傳統(tǒng)電信設(shè)備由電信運(yùn)營商統(tǒng)一提供軟硬件一體設(shè)備及集成服務(wù), 引入NFV 后將原來封閉的電信設(shè)備商分解為多個(gè)層次:硬件設(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 部署采用不同解耦方式時(shí)所需的集成工作有所不同。
2.4.1采用軟硬件解耦方式部署。
軟硬件解耦方式部署如圖3 所示。
軟硬件解耦方式, 即硬件資源層由運(yùn)營商統(tǒng)一采購,有多個(gè)硬件廠商;Hypervisor、VIM、VNF、EMS、VNFM 由VNF 廠商提供并集成;NFVO 與OSS 可能單獨(dú)采購, 也可能由同一廠商提供。
2.4.2采用3 層解耦方式部署。
(1)3 層解耦方式部署如圖4 所示。
(2)3 層解耦方式, 即硬件資源層由運(yùn)營商統(tǒng)一采購,有多個(gè)硬件廠商;Hypervisor、VIM 由VIM 廠商提供;VNF、EMS、VNFM 由VNF 廠商提供;NFVO 與OSS 可能單獨(dú)采購,也可能由同一廠商提供。運(yùn)營商選定NFV 系統(tǒng)軟件集成商或自主實(shí)現(xiàn)三層的集成。與軟硬件解耦方式相比,增加VNF 與虛擬層之間的軟件集成以及VNFM 與VIM 之間的接口集成,集成角色也有所變化。
2.5核心網(wǎng)NFV 的電信級(jí)可靠性。
2.5.1核心網(wǎng)元虛擬化后并不能降低電信應(yīng)用的可靠性要求,仍需要滿足“5 個(gè)9”的可靠性,提供與電信網(wǎng)絡(luò)同樣的服務(wù)質(zhì)量和安全等級(jí)。傳統(tǒng)電信硬件通過定制化的、針對(duì)電信需求的硬件來提供高可靠性, 而NFV 整體業(yè)務(wù)端到端可靠性受限于VNF、虛擬化、硬件每一層的可靠性級(jí)別,虛擬化采用的COTS 設(shè)備(“3 個(gè)9”)和開源社區(qū)軟件的可靠性相對(duì)降低。且解耦模型下傳統(tǒng)電信硬件-ATCA 的故障通知機(jī)制(實(shí)時(shí)精確)不復(fù)存在,故障的實(shí)時(shí)監(jiān)測和上報(bào)將依賴于各層間的交互(HA(high available)機(jī)制)。
2.5.2為保證核心網(wǎng)元虛擬化后電信級(jí)可靠性,有下述要求。
(1)對(duì)各層提出可靠性可用性要求
(2)通過冗余配置來提高可靠性
(3)進(jìn)行VNF 軟件架構(gòu)優(yōu)化
(4)各層故障處理聯(lián)動(dòng)
3. NFV組網(wǎng)方案
3.1VNF 組網(wǎng)方案。
3.1.1VNF 與PNF 混合組網(wǎng)。
引入核心網(wǎng)NFV 后,對(duì)于傳統(tǒng)網(wǎng)絡(luò)不可能“一刀切”,全部替換,運(yùn)營商應(yīng)采用先增量后存量替換的方式建設(shè),因此在較長時(shí)期內(nèi)會(huì)存在云化網(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ò)容時(shí),可對(duì)pool 中VNF 進(jìn)行擴(kuò)容或增加VNF 數(shù)量, 通過調(diào)整DNS 中的權(quán)重進(jìn)行流量分類。
B.需要同一套OMC 對(duì)VNF 和PNF 進(jìn)行管理, 支持對(duì)VNF 和PNF 不同軟件版本的管理和配置核查功能; 需要同一套OSS 實(shí)現(xiàn)對(duì)VNF 和PNF 的管理,在原OSS 與OSS/NFVO 之間同步網(wǎng)元的告警和性能信息。PNF 與VNF 混合組pool 如圖5 所示。
(2)PNF 與VNF 獨(dú)立組網(wǎng)。
PNF 與VNF 分別組pool,負(fù)責(zé)不同業(yè)務(wù)區(qū)域的業(yè)務(wù),未來進(jìn)行容量擴(kuò)容時(shí), 優(yōu)先對(duì)VNF pool 進(jìn)行擴(kuò)容。隨著VNFpool 的容量比例增加, 可能需要在擴(kuò)容時(shí)調(diào)整業(yè)務(wù)劃分,將部分用戶從傳統(tǒng)網(wǎng)元管轄區(qū)割接到虛擬網(wǎng)元管轄區(qū)。建議獨(dú)立設(shè)置VNF 和PNF 的OMC; 對(duì)于OSS, 根據(jù)網(wǎng)管架構(gòu)而定,可以分設(shè)也可以合設(shè)。PNF 與VNF 獨(dú)立組網(wǎng)如圖6 所示。
3.1.2VNF pool 相對(duì)于傳統(tǒng)網(wǎng)元pool 的優(yōu)化特性。
3.1.2.1網(wǎng)元自動(dòng)擴(kuò)縮容。
VNF 具備自動(dòng)擴(kuò)縮容特性,pool 內(nèi)網(wǎng)元為負(fù)荷分擔(dān)工作,因此pool 內(nèi)網(wǎng)元的彈性伸縮策略有如下兩種方式。
(1)pool 內(nèi)網(wǎng)元擴(kuò)縮容聯(lián)動(dòng):該方式對(duì)MANO 的要求較高,要求收集pool 內(nèi)網(wǎng)元的統(tǒng)計(jì)指標(biāo)后,根據(jù)預(yù)設(shè)的擴(kuò)縮容策略和算法,對(duì)pool 內(nèi)網(wǎng)元同步進(jìn)行擴(kuò)縮容。目前標(biāo)準(zhǔn)尚未定義,廠商產(chǎn)品也不支持。
(2)pool 內(nèi)網(wǎng)元獨(dú)立進(jìn)行擴(kuò)縮容:同時(shí)要求pool 內(nèi)VNF配置相同擴(kuò)縮容策略,包括采用的統(tǒng)計(jì)指標(biāo)和擴(kuò)縮容閾值等。由于pool 內(nèi)網(wǎng)元的負(fù)載不是百分之百相同,存在微小差異,因此該方式會(huì)存在pool 內(nèi)網(wǎng)元彈性擴(kuò)縮容不同步、短時(shí)間內(nèi)pool 內(nèi)網(wǎng)元容量不均衡的情況,但在較短時(shí)間內(nèi)可重新達(dá)到均衡,不影響網(wǎng)絡(luò)運(yùn)行。
3.1.2.2網(wǎng)元重生。
(1)VNF 組pool 機(jī)制與基于VM HA 的VNF 重生機(jī)制結(jié)合,可提高可用性。pool+VNF 重生的倒換機(jī)制為:先啟動(dòng)pool 內(nèi)倒換,與故障VNF 有連接的網(wǎng)元檢測到故障,發(fā)起倒換流程,將業(yè)務(wù)倒換到pool 內(nèi)其他網(wǎng)元。再進(jìn)行VNF 重生, 服務(wù)器出現(xiàn)故障時(shí),VIM 自動(dòng)將虛擬機(jī)遷移到其他空閑VM 上, 保持VM 的配置(如親和性) 和數(shù)據(jù)不變,使VNF 快速重生(單VM 的重建時(shí)間為3~5 min)。其他網(wǎng)元檢測到故障網(wǎng)元恢復(fù),可發(fā)起倒回流程,或由網(wǎng)管人員手工倒回。VNF 重生示意如圖7 所示。
(2)與傳統(tǒng)網(wǎng)元相比, 對(duì)于單純硬件故障引起的網(wǎng)元故障,不需人工更換硬件,通過VNF 重生大大縮短網(wǎng)元恢復(fù)時(shí)間;對(duì)于軟件故障,仍需要人工排查后進(jìn)行網(wǎng)元重啟。
3.1.2.3負(fù)荷分擔(dān)策略。
(1)以IMS 域?yàn)槔?,IMS 域傳統(tǒng)網(wǎng)元pool 的負(fù)荷分擔(dān)是通過DNS 對(duì)pool 域名的解析實(shí)現(xiàn)的,DNS 將pool 域名解析為帶優(yōu)先級(jí)和權(quán)重的pool 內(nèi)網(wǎng)元IP 地址列表,DNS 中的容災(zāi)數(shù)據(jù)為靜態(tài)配置。
(2)引入NFV 后,由于網(wǎng)元有自動(dòng)擴(kuò)縮容特性,網(wǎng)元的容量會(huì)動(dòng)態(tài)變化,因此有動(dòng)態(tài)負(fù)荷分擔(dān)的需求。
3.2MANO 部署方案。
核心網(wǎng)云管理平臺(tái)系統(tǒng)組網(wǎng)架構(gòu)如圖8 所示。
雖然VNF 所需資源是由MANO 自動(dòng)部署的, 但業(yè)務(wù)網(wǎng)絡(luò)的運(yùn)維架構(gòu)依然依靠傳統(tǒng)的EMS/OSS 機(jī)制, 因此MANO 與EMS/OSS 之間需要協(xié)調(diào)交互, 共同完成對(duì)云化網(wǎng)元的管理。同時(shí)MANO 部分功能與現(xiàn)有OSS 功能有交叉。因此運(yùn)營商在部署MANO 時(shí)應(yīng)先做好新網(wǎng)管架構(gòu)的規(guī)劃,明確OSS 與NFVO 的功能定位和未來演進(jìn)目標(biāo)。
3.2.1NFVO 部署。
(1)NFVO 實(shí)現(xiàn)NSD,VNFFG、VNFD 的管理及處理, 網(wǎng)絡(luò)服務(wù)生命周期的管理, 和VNFM 配合實(shí)現(xiàn)VNF 的生命周期管理和資源的全局視圖功能。NFVO 在網(wǎng)絡(luò)中所處的位置與OSS 相當(dāng),因此建議部署位置也與OSS 相同,根據(jù)運(yùn)營商未來網(wǎng)管架構(gòu)的規(guī)劃和維護(hù)管理需求,NFVO 可定制化新建或由現(xiàn)有OSS 改造支持。
(2)NFVO 要求連接多廠商VNFM、多廠商VIM。
3.2.2VNFM 部署。
(1)VNFM 實(shí)現(xiàn)虛擬化網(wǎng)元VNF 的生命周期管理, 包括VNFD 的管理及處理、VNF 實(shí)例的初始化、VNF 的擴(kuò)容/縮容、VNF 實(shí)例的終止。支持接收NFVO 下發(fā)的彈性伸縮策略,實(shí)現(xiàn)VNF 的彈性伸縮。
(2)目前VNFM 與VNF、EMS 之間的接口為廠商私有接口,無標(biāo)準(zhǔn)化計(jì)劃,因此建議VNFM 與VNF、EMS 同廠商部署。部分MANO 廠商也可提供genric VNFM,支持連接異廠商的VNF、EMS。
(3)同廠商EMS 與VNFM 通常數(shù)量為1∶1,軟硬解耦部署時(shí),VNFM 要求支持連接同廠商多個(gè)VIM;3 層解耦部署時(shí),VNFM 要求連接多廠商VIM。
3.2.3VIM 部署。
(1)VIM 是虛擬化基礎(chǔ)設(shè)施管理系統(tǒng),主要負(fù)責(zé)基礎(chǔ)設(shè)施層硬件資源、虛擬化資源的管理,監(jiān)控和故障上報(bào),面向上層VNFM 和NFVO 提供虛擬化資源池。同時(shí),VIM 提供虛擬機(jī)鏡像管理功能。
(2)一般來說, 一個(gè)VIM 對(duì)應(yīng)一套OpenStack/一個(gè)區(qū)域,區(qū)域內(nèi)部根據(jù)部署需求可劃分AZ 和HA, 區(qū)域內(nèi)實(shí)現(xiàn)資源共享、熱遷移,區(qū)域之間可以實(shí)現(xiàn)資源隔離。
(3)同一DC 內(nèi)根據(jù)管理的硬件規(guī)模, 可部署多個(gè)VIM,多個(gè)VIM 可以同廠商也可以異廠商, 多個(gè)VIM 所管理的物理服務(wù)器、存儲(chǔ)資源獨(dú)立,多個(gè)VIM 所管理的資源可以共用組網(wǎng)設(shè)備。
(4)同一DC 內(nèi)不同VIM/region、多個(gè)DC 多個(gè)VIM/區(qū)域可以通過多區(qū)域?qū)崿F(xiàn)共享訪問賬號(hào)和管理界面(目前是同廠商VIM 可共享)。
(5)VIM 要求支持管理多廠商硬件; 軟硬解耦部署時(shí),VIM 要求支持連接同廠商多個(gè)VNFM;3 層解耦部署時(shí),VIM 要求支持連接多廠商VNFM。
3.3資源池組網(wǎng)方案。
3.3.1相對(duì)于傳統(tǒng)網(wǎng)元的站點(diǎn)組網(wǎng), 核心網(wǎng)NFV 資源池組網(wǎng)存在各類流量共用物理端口邏輯隔離、網(wǎng)元內(nèi)部流量需要站點(diǎn)組網(wǎng)設(shè)備疏通等特點(diǎn)。
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ù)。對(duì)外完成與外網(wǎng)設(shè)備高速互聯(lián),對(duì)內(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ù)器以及存儲(chǔ)設(shè)備。資源池分層組網(wǎng)架構(gòu)如圖9所示。
3.3.3IT 云資源池對(duì)于站點(diǎn)內(nèi)流量一般分兩個(gè)物理平面:基礎(chǔ)設(shè)施平面、業(yè)務(wù)平面, 物理平面內(nèi)的不同流量采用VLAN 隔離。但NFV 資源池相比IT 云資源池更復(fù)雜,除基礎(chǔ)設(shè)施流量、業(yè)務(wù)流量、存儲(chǔ)流量外,還有網(wǎng)元生命周期管理流量,且為保證電信級(jí)可靠性,核心網(wǎng)NFV 平面隔離要求比IT 云更嚴(yán)格。
3.3.4根據(jù)核心網(wǎng)NFV 站點(diǎn)內(nèi)各類流量特點(diǎn), 可分為以下幾類。
(1)基礎(chǔ)設(shè)施管理流量。
包括OpenStack 管理節(jié)點(diǎn)與各服務(wù)器上的代理通信的流量,對(duì)資源池虛擬資源進(jìn)行管理,在管理流量中優(yōu)先級(jí)最高;另外還有硬件管理接口,也采用獨(dú)立的物理接口。
(2)其他管理流量。
包括VIM 與NFVO、VNFM 之間的資源管理接口;VNFM 與EMS、VNF、NFVO 之間的網(wǎng)元生命周期管理接口;EMS 與VNF、OSS 之間的網(wǎng)元應(yīng)用層網(wǎng)管接口。管理流量的流量帶寬需求較小,實(shí)時(shí)性不高,但安全級(jí)別要高于業(yè)務(wù)流量,以便于業(yè)務(wù)端口發(fā)生異常時(shí),可以從管理端口進(jìn)行相應(yīng)的維護(hù)操作。
(3)業(yè)務(wù)流量。
包括VNF 內(nèi)部虛擬機(jī)之間、VNF 之間的流量,VNF 的計(jì)費(fèi)和業(yè)務(wù)開通流量。業(yè)務(wù)流量的帶寬和實(shí)時(shí)性要求較高,且有信令監(jiān)測的需求。
(4)存儲(chǔ)流量。
包括VNF、MANO、EMS 與存儲(chǔ)設(shè)備之間的流量。流量帶寬在萬兆級(jí)別,實(shí)時(shí)性要求較高。
3.3.5管理流量、業(yè)務(wù)流量、存儲(chǔ)流量的特點(diǎn)不同,考慮電信網(wǎng)絡(luò)可靠性,為避免相互影響,建議進(jìn)行平面物理隔離,每個(gè)平面采用獨(dú)立的服務(wù)器物理網(wǎng)口和交換機(jī),平面內(nèi)不同流量采用VLAN 邏輯隔離,平面之間通過防火墻或承載網(wǎng)進(jìn)行互通。物理平面劃分示意如圖10 所示。
(1)管理平面:OpenStack 管理節(jié)點(diǎn)與各服務(wù)器上的代理通信的流量; 根據(jù)維護(hù)管理要求,MANO 和網(wǎng)管相關(guān)流量也可以走管理平面, 但需通過虛擬交換機(jī),對(duì)于網(wǎng)元和虛擬層有配置要求;
(2)業(yè)務(wù)平面:虛擬機(jī)之間及虛擬機(jī)對(duì)外的業(yè)務(wù)流量;
(3)存儲(chǔ)平面:虛擬機(jī)與存儲(chǔ)設(shè)備之間的流量。
進(jìn)行物理平面隔離可以提升資源池組網(wǎng)的可靠性和安全性, 但也會(huì)增加服務(wù)器網(wǎng)口數(shù)量和交換機(jī)的配置數(shù)量,增加一定的組網(wǎng)復(fù)雜度。
4. 結(jié)束語
(1)傳統(tǒng)電信核心網(wǎng)引入NFV 實(shí)現(xiàn)云化, 將增強(qiáng)網(wǎng)絡(luò)功能和容量的靈活性, 以更好地應(yīng)對(duì)市場和業(yè)務(wù)的快速變化。但對(duì)運(yùn)營商來說,在技術(shù)、維護(hù)管理架構(gòu)、管理流程等各方面都存在挑戰(zhàn), 對(duì)于產(chǎn)業(yè)鏈也需要進(jìn)行重新定位。
(2)NFV 技術(shù)和產(chǎn)品也在逐步成熟過程中, 運(yùn)營商應(yīng)先做好NFV 部署架構(gòu)設(shè)計(jì), 基于產(chǎn)品成熟度和業(yè)務(wù)驅(qū)動(dòng)引入NFV,同時(shí)考慮云化網(wǎng)元和傳統(tǒng)網(wǎng)元長期共存下的組網(wǎng)方案;應(yīng)根據(jù)具體部署和運(yùn)營需求,積極推動(dòng)NFV 相關(guān)技術(shù)標(biāo)準(zhǔn)的成熟;加強(qiáng)與產(chǎn)業(yè)鏈的合作,探索新的合作模式和商業(yè)模式。
參考文獻(xiàn)
[1]ETSI. Network functions virtualisation (NFV); infrastructureoverview: GS NFV-INF 001[S]. 2015.
[2]ETSI. Network functions virtualisation (NFV); architecturalframework: GS NFV 002[S]. 2014.
[3]ETSI. Network functions virtualisation (NFV); accelerationtechnologies; report on acceleration technologies & use cases:GS NFV-IFA 001[S]. 2015.
[4]ETSI. Network functions virtualisation (NFV); managementand orchestration: GS NFV-MAN 001[S]. 2014.
[5]ETSI. Network functions virtualisation(NFV); accelerationtechnologies; VNF interfaces specification: GS NFV-IFA002[S]. 2016.
[6]ETSI. Network functions virtualisation (NFV); managementand orchestration; Or-Vi reference point -interface and informationmodel specification: GS NFV-IFA 005[S]. 2016.
[7]ETSI. Network functions virtualisation (NFV); managementand orchestration; Vi-Vnfm reference point-interface and informationmodel specification: GS NFV-IFA 006[S]. 2016.
[8]趙慧玲, 史凡. SDN/NFV的發(fā)展與挑戰(zhàn)[J]. 電信科學(xué), 2014,30(8): 13-18.
[9]翟振輝,邱巍,吳麗華,吳倩. NFV基本架構(gòu)及部署方式. 電信科學(xué),2017(6):180-185.