李新明??

【摘要】為滿足移動互聯網時期市場和業(yè)務快速上線、頻繁迭代、定制化的需求，電信運營商引入核心網NFV成為必然選擇，也成為實現網絡建設低成本、高效運營的主要策略之一。本文分析了運營商部署NFV 需要解決的關鍵問題，并對VNF 組網、MANO 部署和資源池部署方案進行研究；最后對NFV 后續(xù)發(fā)展進行展望。

【關鍵詞】VNF 組網；VNF 部署；核心網

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 標準化中的需求和架構已確定，關鍵流程也基本具備， 但協(xié)議級接口流程尚未完成。截止到2014 年底，ETSI 已經完成了第一階段的工作，定義了NFV、MANO 框架和功能，提供參考性的粗略流程。目前正在開展第二階段的工作，主要的工作內容包括：MANO 接口規(guī)范、加速技術、NSD 及VNF package 定義、Hypervisor Domain 需求。NFV 體系架構如圖1 所示。

運營商均認可NFV 是未來發(fā)展方向， 但商用進程存在很多困難，AT&T、Vodafone、SKT 等運營商僅進行少量VoLTE IMS 和物聯網專網EPC 的商用部署。

2. NFV 部署過程中的關鍵問題

2.1與現有IT 云的差異。

NFV 電信云資源池與現有IT 云在硬件、虛擬層、管理架構、管理維護需求、可靠性等方面均不同，滿足電信級要求的基礎設施構建難度大，對于電信級云管平臺的要求也更嚴格。

（1）承載的應用不同，應用特性也不同。

（2）硬件配置要求不同。

（3）對虛擬層要求不同。

（4）可靠性要求不同。

（5）云管理平臺要求不同。

（6）資源隔離。

2.2MANO 和網管需要協(xié)同。

現有網管側重網元FCAPS 的管理，NFV 的重點在于管理和編排（資源動態(tài)管理、VNF 的編排）以及VNF 生命周期管理，NFV 云化使得對網元的管理分為虛擬網元功能的管理和云化資源管理兩部分，對網管體系提出全新的要求。為實現未來對虛擬網絡的端到端管理， 需MANO 和OSS 進行協(xié)同。

同時虛擬化網絡和傳統(tǒng)網絡會長期共存，需要由OSS對虛擬化網絡和傳統(tǒng)網絡進行協(xié)同管理，由NFVO 實現虛擬化網絡和傳統(tǒng)網絡業(yè)務編排。

MANO 和網管協(xié)同示意如圖2 所示。

2.3標準化和接口IoT。

除了傳統(tǒng)的通信標準組織（ETSI、3GPP），NFV 標準還涉及一些開源組織， 如OpenStack、OPNFV 以及與SDN 相關的ONF、ODL、ONOS 等。與傳統(tǒng)電信標準側重通信協(xié)議交互不同，NFV 更強調API 調用的軟件交互。由于涉及標準組織較多，各組織間需要配合協(xié)作，標準整體推進困難，目前廠商產品及其商用進展已快于標準化進程，廠商為滿足部分運營商商用需求， 部分接口及流程采用私有方案；同時NFV 只是定義架構層次， 通過協(xié)調其他開源或技術組織來實現對應各個接口的具體定義，這樣與一個組織制定標準相比，技術標準的嚴密性會差一些，在保證多廠商設備兼容方面面臨很大風險。

運營商應根據具體部署和運營需求，積極推動國際標準和廠商產品實現，并考慮在開源社區(qū)中發(fā)揮作用。

2.4多廠商集成。

傳統(tǒng)電信設備由電信運營商統(tǒng)一提供軟硬件一體設備及集成服務， 引入NFV 后將原來封閉的電信設備商分解為多個層次：硬件設備商、虛擬化軟件供應商、VIM 軟件供應商、VNF 軟件供應商、NFVO（NFV orchestrator）軟件供應商、NFV 系統(tǒng)集成商。傳統(tǒng)網元軟硬一體，無需縱向集成，而NFV 無論采用軟硬解耦還是三層解耦方式部署， 都需要有集成商來進行縱向分層的集成工作， 復雜度大大提升。NFV 部署采用不同解耦方式時所需的集成工作有所不同。

2.4.1采用軟硬件解耦方式部署。endprint

軟硬件解耦方式部署如圖3 所示。

軟硬件解耦方式， 即硬件資源層由運營商統(tǒng)一采購，有多個硬件廠商；Hypervisor、VIM、VNF、EMS、VNFM 由VNF 廠商提供并集成；NFVO 與OSS 可能單獨采購， 也可能由同一廠商提供。

2.4.2采用3 層解耦方式部署。

（1）3 層解耦方式部署如圖4 所示。

（2）3 層解耦方式， 即硬件資源層由運營商統(tǒng)一采購，有多個硬件廠商；Hypervisor、VIM 由VIM 廠商提供；VNF、EMS、VNFM 由VNF 廠商提供；NFVO 與OSS 可能單獨采購，也可能由同一廠商提供。運營商選定NFV 系統(tǒng)軟件集成商或自主實現三層的集成。與軟硬件解耦方式相比，增加VNF 與虛擬層之間的軟件集成以及VNFM 與VIM 之間的接口集成，集成角色也有所變化。

2.5核心網NFV 的電信級可靠性。

2.5.1核心網元虛擬化后并不能降低電信應用的可靠性要求，仍需要滿足“5 個9”的可靠性，提供與電信網絡同樣的服務質量和安全等級。傳統(tǒng)電信硬件通過定制化的、針對電信需求的硬件來提供高可靠性， 而NFV 整體業(yè)務端到端可靠性受限于VNF、虛擬化、硬件每一層的可靠性級別，虛擬化采用的COTS 設備（“3 個9”）和開源社區(qū)軟件的可靠性相對降低。且解耦模型下傳統(tǒng)電信硬件-ATCA 的故障通知機制（實時精確）不復存在，故障的實時監(jiān)測和上報將依賴于各層間的交互（HA（high available）機制）。

2.5.2為保證核心網元虛擬化后電信級可靠性，有下述要求。

（1）對各層提出可靠性可用性要求

（2）通過冗余配置來提高可靠性

（3）進行VNF 軟件架構優(yōu)化

（4）各層故障處理聯動

3. NFV組網方案

3.1VNF 組網方案。

3.1.1VNF 與PNF 混合組網。

引入核心網NFV 后，對于傳統(tǒng)網絡不可能“一刀切”，全部替換，運營商應采用先增量后存量替換的方式建設，因此在較長時期內會存在云化網元（virtual network function，VNF） 和非云化網元（physical network function，PNF）共存的情況，以初期引入云化IMS 為例，其組網有如下兩種方案。

（1）PNF 與VNF 混合組pool。

A.在pool 中PNF 與VNF 無差別，pool 組網方案、容災流程與現網完全一致。未來擴容時，可對pool 中VNF 進行擴容或增加VNF 數量， 通過調整DNS 中的權重進行流量分類。

B.需要同一套OMC 對VNF 和PNF 進行管理， 支持對VNF 和PNF 不同軟件版本的管理和配置核查功能； 需要同一套OSS 實現對VNF 和PNF 的管理，在原OSS 與OSS/NFVO 之間同步網元的告警和性能信息。PNF 與VNF 混合組pool 如圖5 所示。

（2）PNF 與VNF 獨立組網。

PNF 與VNF 分別組pool，負責不同業(yè)務區(qū)域的業(yè)務，未來進行容量擴容時， 優(yōu)先對VNF pool 進行擴容。隨著VNFpool 的容量比例增加， 可能需要在擴容時調整業(yè)務劃分，將部分用戶從傳統(tǒng)網元管轄區(qū)割接到虛擬網元管轄區(qū)。建議獨立設置VNF 和PNF 的OMC； 對于OSS， 根據網管架構而定，可以分設也可以合設。PNF 與VNF 獨立組網如圖6 所示。

3.1.2VNF pool 相對于傳統(tǒng)網元pool 的優(yōu)化特性。

3.1.2.1網元自動擴縮容。

VNF 具備自動擴縮容特性，pool 內網元為負荷分擔工作，因此pool 內網元的彈性伸縮策略有如下兩種方式。

（1）pool 內網元擴縮容聯動：該方式對MANO 的要求較高，要求收集pool 內網元的統(tǒng)計指標后，根據預設的擴縮容策略和算法，對pool 內網元同步進行擴縮容。目前標準尚未定義，廠商產品也不支持。

（2）pool 內網元獨立進行擴縮容：同時要求pool 內VNF配置相同擴縮容策略，包括采用的統(tǒng)計指標和擴縮容閾值等。由于pool 內網元的負載不是百分之百相同，存在微小差異，因此該方式會存在pool 內網元彈性擴縮容不同步、短時間內pool 內網元容量不均衡的情況，但在較短時間內可重新達到均衡，不影響網絡運行。

3.1.2.2網元重生。

（1）VNF 組pool 機制與基于VM HA 的VNF 重生機制結合，可提高可用性。pool+VNF 重生的倒換機制為：先啟動pool 內倒換，與故障VNF 有連接的網元檢測到故障，發(fā)起倒換流程，將業(yè)務倒換到pool 內其他網元。再進行VNF 重生， 服務器出現故障時，VIM 自動將虛擬機遷移到其他空閑VM 上， 保持VM 的配置（如親和性） 和數據不變，使VNF 快速重生（單VM 的重建時間為3～5 min）。其他網元檢測到故障網元恢復，可發(fā)起倒回流程，或由網管人員手工倒回。VNF 重生示意如圖7 所示。

（2）與傳統(tǒng)網元相比， 對于單純硬件故障引起的網元故障，不需人工更換硬件，通過VNF 重生大大縮短網元恢復時間；對于軟件故障，仍需要人工排查后進行網元重啟。

3.1.2.3負荷分擔策略。

（1）以IMS 域為例，IMS 域傳統(tǒng)網元pool 的負荷分擔是通過DNS 對pool 域名的解析實現的，DNS 將pool 域名解析為帶優(yōu)先級和權重的pool 內網元IP 地址列表，DNS 中的容災數據為靜態(tài)配置。

（2）引入NFV 后，由于網元有自動擴縮容特性，網元的容量會動態(tài)變化，因此有動態(tài)負荷分擔的需求。endprint

3.2MANO 部署方案。

核心網云管理平臺系統(tǒng)組網架構如圖8 所示。

雖然VNF 所需資源是由MANO 自動部署的， 但業(yè)務網絡的運維架構依然依靠傳統(tǒng)的EMS/OSS 機制， 因此MANO 與EMS/OSS 之間需要協(xié)調交互， 共同完成對云化網元的管理。同時MANO 部分功能與現有OSS 功能有交叉。因此運營商在部署MANO 時應先做好新網管架構的規(guī)劃，明確OSS 與NFVO 的功能定位和未來演進目標。

3.2.1NFVO 部署。

（1）NFVO 實現NSD，VNFFG、VNFD 的管理及處理， 網絡服務生命周期的管理， 和VNFM 配合實現VNF 的生命周期管理和資源的全局視圖功能。NFVO 在網絡中所處的位置與OSS 相當，因此建議部署位置也與OSS 相同，根據運營商未來網管架構的規(guī)劃和維護管理需求，NFVO 可定制化新建或由現有OSS 改造支持。

（2）NFVO 要求連接多廠商VNFM、多廠商VIM。

3.2.2VNFM 部署。

（1）VNFM 實現虛擬化網元VNF 的生命周期管理， 包括VNFD 的管理及處理、VNF 實例的初始化、VNF 的擴容/縮容、VNF 實例的終止。支持接收NFVO 下發(fā)的彈性伸縮策略，實現VNF 的彈性伸縮。

（2）目前VNFM 與VNF、EMS 之間的接口為廠商私有接口，無標準化計劃，因此建議VNFM 與VNF、EMS 同廠商部署。部分MANO 廠商也可提供genric VNFM，支持連接異廠商的VNF、EMS。

（3）同廠商EMS 與VNFM 通常數量為1∶1，軟硬解耦部署時，VNFM 要求支持連接同廠商多個VIM；3 層解耦部署時，VNFM 要求連接多廠商VIM。

3.2.3VIM 部署。

（1）VIM 是虛擬化基礎設施管理系統(tǒng)，主要負責基礎設施層硬件資源、虛擬化資源的管理，監(jiān)控和故障上報，面向上層VNFM 和NFVO 提供虛擬化資源池。同時，VIM 提供虛擬機鏡像管理功能。

（2）一般來說， 一個VIM 對應一套OpenStack/一個區(qū)域，區(qū)域內部根據部署需求可劃分AZ 和HA， 區(qū)域內實現資源共享、熱遷移，區(qū)域之間可以實現資源隔離。

（3）同一DC 內根據管理的硬件規(guī)模， 可部署多個VIM，多個VIM 可以同廠商也可以異廠商， 多個VIM 所管理的物理服務器、存儲資源獨立，多個VIM 所管理的資源可以共用組網設備。

（4）同一DC 內不同VIM/region、多個DC 多個VIM/區(qū)域可以通過多區(qū)域實現共享訪問賬號和管理界面（目前是同廠商VIM 可共享）。

（5）VIM 要求支持管理多廠商硬件； 軟硬解耦部署時，VIM 要求支持連接同廠商多個VNFM；3 層解耦部署時，VIM 要求支持連接多廠商VNFM。

3.3資源池組網方案。

3.3.1相對于傳統(tǒng)網元的站點組網， 核心網NFV 資源池組網存在各類流量共用物理端口邏輯隔離、網元內部流量需要站點組網設備疏通等特點。

3.3.2核心網NFV 資源池組網與IT 資源池組網架構類似，采用層次化組網架構。網絡出口層負責網絡內部路由信息和外部路由信息轉發(fā)和維護。對外完成與外網設備高速互聯，對內負責與數據中心的核心層交換設備互聯。網絡核心層部署核心交換機，負責接入層交換設備的匯聚，核心交換機上聯網絡出口層路由設備，完成與外網設備高速互聯。接入層包括接入交換機和接入終端設備，接入終端設備包括機架式服務器、刀片式服務器以及存儲設備。資源池分層組網架構如圖9所示。

3.3.3IT 云資源池對于站點內流量一般分兩個物理平面：基礎設施平面、業(yè)務平面， 物理平面內的不同流量采用VLAN 隔離。但NFV 資源池相比IT 云資源池更復雜，除基礎設施流量、業(yè)務流量、存儲流量外，還有網元生命周期管理流量，且為保證電信級可靠性，核心網NFV 平面隔離要求比IT 云更嚴格。

3.3.4根據核心網NFV 站點內各類流量特點， 可分為以下幾類。

（1）基礎設施管理流量。

包括OpenStack 管理節(jié)點與各服務器上的代理通信的流量，對資源池虛擬資源進行管理，在管理流量中優(yōu)先級最高；另外還有硬件管理接口，也采用獨立的物理接口。

（2）其他管理流量。

包括VIM 與NFVO、VNFM 之間的資源管理接口；VNFM 與EMS、VNF、NFVO 之間的網元生命周期管理接口；EMS 與VNF、OSS 之間的網元應用層網管接口。管理流量的流量帶寬需求較小，實時性不高，但安全級別要高于業(yè)務流量，以便于業(yè)務端口發(fā)生異常時，可以從管理端口進行相應的維護操作。

（3）業(yè)務流量。

包括VNF 內部虛擬機之間、VNF 之間的流量，VNF 的計費和業(yè)務開通流量。業(yè)務流量的帶寬和實時性要求較高，且有信令監(jiān)測的需求。

（4）存儲流量。

包括VNF、MANO、EMS 與存儲設備之間的流量。流量帶寬在萬兆級別，實時性要求較高。

3.3.5管理流量、業(yè)務流量、存儲流量的特點不同，考慮電信網絡可靠性，為避免相互影響，建議進行平面物理隔離，每個平面采用獨立的服務器物理網口和交換機，平面內不同流量采用VLAN 邏輯隔離，平面之間通過防火墻或承載網進行互通。物理平面劃分示意如圖10 所示。

（1）管理平面：OpenStack 管理節(jié)點與各服務器上的代理通信的流量； 根據維護管理要求，MANO 和網管相關流量也可以走管理平面， 但需通過虛擬交換機，對于網元和虛擬層有配置要求；

（2）業(yè)務平面：虛擬機之間及虛擬機對外的業(yè)務流量；endprint

（3）存儲平面：虛擬機與存儲設備之間的流量。

進行物理平面隔離可以提升資源池組網的可靠性和安全性， 但也會增加服務器網口數量和交換機的配置數量，增加一定的組網復雜度。

4. 結束語

（1）傳統(tǒng)電信核心網引入NFV 實現云化， 將增強網絡功能和容量的靈活性， 以更好地應對市場和業(yè)務的快速變化。但對運營商來說，在技術、維護管理架構、管理流程等各方面都存在挑戰(zhàn)， 對于產業(yè)鏈也需要進行重新定位。

（2）NFV 技術和產品也在逐步成熟過程中， 運營商應先做好NFV 部署架構設計， 基于產品成熟度和業(yè)務驅動引入NFV，同時考慮云化網元和傳統(tǒng)網元長期共存下的組網方案；應根據具體部署和運營需求，積極推動NFV 相關技術標準的成熟；加強與產業(yè)鏈的合作，探索新的合作模式和商業(yè)模式。

參考文獻

[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]. 電信科學， 2014，30（8）： 13-18.

[9]翟振輝，邱巍，吳麗華，吳倩. NFV基本架構及部署方式. 電信科學，2017（6）：180-185.endprint