城域網(wǎng)邁向NFV需過幾道技術(shù)坎

福建電信│王福榮 鄭凱 林實踐

城域網(wǎng)邁向NFV需過幾道技術(shù)坎

福建電信│王福榮 鄭凱 林實踐

NFV引入后，網(wǎng)絡(luò)設(shè)備商的商業(yè)模式從“系統(tǒng)設(shè)備+服務(wù)”變成“軟件+服務(wù)”。對于運營商和設(shè)備商而言，都是巨大的轉(zhuǎn)變，如果商業(yè)模式理不清或者不能被雙方所認同，那么NFV就無法實質(zhì)性地商業(yè)化。

隨著NFV各種相關(guān)技術(shù)標準的成熟，NFV的技術(shù)理念和帶來的種種好處也日益被業(yè)界所認同。但是到目前為止，NFV在城域網(wǎng)中的實際應(yīng)用案例基本還是空白，沒有進入實質(zhì)階段。NFV要想在城域網(wǎng)破冰，有幾個關(guān)鍵問題亟待解決。

NFV的切入點

NFV的理念是將硬件和軟件進行分離，目前X86+DPDK的轉(zhuǎn)發(fā)表現(xiàn)(吞吐量、無丟包轉(zhuǎn)發(fā))遠遜色于傳統(tǒng)的ASIC轉(zhuǎn)發(fā)芯片。但是X86架構(gòu)服務(wù)器的優(yōu)勢是計算能力遠大于傳統(tǒng)的網(wǎng)絡(luò)設(shè)備，并且在內(nèi)存上幾乎沒有限制，那么城域網(wǎng)NFV化必定是面向業(yè)務(wù)的，而不是面向轉(zhuǎn)發(fā)。城域網(wǎng)的NFV化必定是從對CPU計算能力要求高、內(nèi)存占用大，同時轉(zhuǎn)發(fā)壓力較小，或者設(shè)備瓶頸在CPU和內(nèi)存(由于CPU和內(nèi)存的限制，轉(zhuǎn)發(fā)利用率較低)的網(wǎng)絡(luò)設(shè)備開始，例如BRAS、CGN、LNS、RR等設(shè)備都適合NFV化。

另外，在NFV中軟件和硬件是獨立發(fā)展的，一般軟件的開發(fā)周期遠小于硬件的開發(fā)周期，軟硬件解耦后，業(yè)務(wù)快速推出到市場變得可能。基于客戶需求進行設(shè)備定制化，尤其是企業(yè)網(wǎng)應(yīng)用中，傳統(tǒng)設(shè)備響應(yīng)時間很慢，越來越不能滿足互聯(lián)網(wǎng)時代的訴求。由于NFV只涉及軟件的開發(fā)和調(diào)試，無論是在時間上還是在成本上都有極大的優(yōu)勢，如CPE、策略服務(wù)器等。

整體集成難度

按照ETSINFV的架構(gòu)，每個function block（功能塊）都遵循標準的接口，他們之間是各自獨立的，并且每個function block按照標準的接口對外提供服務(wù)，理論上講，NFV不依賴于任何特定廠商的實現(xiàn)。

但是目前各個廠商之間還沒有開始進行大規(guī)模的互通性驗證，缺乏互通性驗證使得當前NFV很難按照ETSI的架構(gòu)進行有效集成。如果NFV無法擺脫特定廠商的約束，網(wǎng)絡(luò)開放性會受到很大的影響，如果沒有足夠多的廠商進入NFV領(lǐng)域，那么業(yè)務(wù)的創(chuàng)新能力也會大打折扣，不如預(yù)期想象的那么美好。

另外原本由一個廠商提供的設(shè)備和服務(wù)現(xiàn)在拆分成多個廠商提供的服務(wù)，或者以前由一個PNF（Physical Network Function，物理網(wǎng)絡(luò)功能、模塊）提供的服務(wù)現(xiàn)在由多個VNFs提供，整體NFV集成的難度和工作量、時間也會極大地增加。

安全性要求

NFV將虛擬化技術(shù)和網(wǎng)絡(luò)技術(shù)結(jié)合到一起，使得NFV的安全問題和傳統(tǒng)網(wǎng)絡(luò)設(shè)備的安全大不一樣：除了傳統(tǒng)的網(wǎng)絡(luò)安全問題之外，還需要考慮虛擬化帶來的安全問題，尤其是虛擬化和網(wǎng)絡(luò)結(jié)合帶來的新問題。

另外NFV是一個層次化的架構(gòu)，上層嚴重依賴底層提供的服務(wù)，而且由不同的廠商提供，為避免各層之間的攻擊行為，就要求它們之間能相互認證。考慮到知識產(chǎn)權(quán)和信息安全，各層之間只能暴露有限的信息，NFV引入了一系列的預(yù)防手段，這些目前都還沒有得到有效的驗證，一旦NFV需要啟動商用，安全性問題的解決和實施方案迫在眉睫。

可靠性要求

傳統(tǒng)的電信網(wǎng)絡(luò)要求設(shè)備的可靠性達到6個9，遠高于IT技術(shù)中的要求。ETSI規(guī)定一系列的可靠性需求：NFV的業(yè)務(wù)不中斷(用戶不感知)；VNFs和VMs發(fā)生遷移后，業(yè)務(wù)的SLA不發(fā)生改變；VNFs的遷移對其余相關(guān)聯(lián)VNFs是透明的；這些相比傳統(tǒng)設(shè)備的可靠性技術(shù)，極大地依賴云技術(shù)，涉及NFV多個function block和多個廠商，復(fù)雜度大大增加。

目前來看使用云技術(shù)可以隔離硬件的故障，但是要想達到ETSI的愿景，還有很多工作需要做。

自動化部署

NFV中引入了Orchestrator（編排器）來實現(xiàn)業(yè)務(wù)的自動化編排，以降低運營商的OPEX。但是如何定義業(yè)務(wù)、業(yè)務(wù)需要多少NFs參與、每個NF（網(wǎng)絡(luò)功能）怎樣分工、NF之間的關(guān)系、業(yè)務(wù)如何映射到各個NFs，以及上述工作如何實現(xiàn)自動化部署，目前也仍然沒有一個比較好的實施方案。

動態(tài)scale-in/out

NFV另外一個吸引人的地方是硬件資源池化，NFs可以根據(jù)負載情況進行快速的動態(tài)scale-in/out。但是目前來看，MANO系統(tǒng)雖然可以監(jiān)控VMs的CPU和內(nèi)存利用率，但是要將VNFs從一個VM（虛擬機）熱遷移到另外一個VM，業(yè)務(wù)狀態(tài)的同步、流量聯(lián)動倒換等方面還存在許多不足。另外一個方面，各個廠家對自己vNFs的業(yè)務(wù)負載監(jiān)控實現(xiàn)也不完善，并且在實現(xiàn)上也沒有統(tǒng)一的標準，MANO無法有效監(jiān)控到vNFs的業(yè)務(wù)負載，當前還無法按照vNFs的負載進行動態(tài)scale-in/out。其次，網(wǎng)絡(luò)中應(yīng)該如何scale-in/out目前只有一個感性的共識，還沒有進行深入地探討，比如切換的模式和閾值等。

廠商參與度

NFV引入后，網(wǎng)絡(luò)設(shè)備商的商業(yè)模式從“系統(tǒng)設(shè)備+服務(wù)”，變成“軟件+服務(wù)”。對于運營商和設(shè)備商都是一個巨大的轉(zhuǎn)變，如果商業(yè)模式理不清或者不能被雙方所認同，那么NFV就無法實質(zhì)性地商業(yè)化，也就無法吸引傳統(tǒng)設(shè)備廠商和新的廠商進入這個領(lǐng)域，NFV進展就會非常緩慢，商業(yè)化也會遙遙無期。

從技術(shù)和理念上看，NFV無疑會成為未來城域網(wǎng)架構(gòu)中非常重要的構(gòu)成部分，它可以幫助運營商提供更加高效、靈活、面向業(yè)務(wù)的網(wǎng)絡(luò)。雖然NFV已經(jīng)走在城域網(wǎng)商用的路上，但是還有很長的一段路要走。

編輯｜刁興玲 diaoxingling@bjxintong.com.cn