網(wǎng)絡(luò)功能虛擬化(NFV)技術(shù)的目標(biāo)是在標(biāo)準(zhǔn)服務(wù)器上提供網(wǎng)絡(luò)功能，而不是在定制設(shè)備上。雖然供應(yīng)商和網(wǎng)絡(luò)運營商都急于部署NFV，但歐洲電信標(biāo)準(zhǔn) 協(xié)會(ETSI)要到2015年1月才會發(fā)布規(guī)范。因此，早期NFV部署將不得不利用更廣泛的原則，隨著更多細(xì)節(jié)信息浮出水面，這些原則將會逐漸被部署。

為了在短期內(nèi)實現(xiàn)NFV部署，供應(yīng)商需要作出四個關(guān)鍵決策：部署云托管模式，選擇網(wǎng)絡(luò)優(yōu)化的平臺，基于TM論壇的原則構(gòu)建服務(wù)和資源以促進(jìn)操作整合，以及部署靈活且松耦合的數(shù)據(jù)/流程架構(gòu)。

為NFV尋找通用管理框架：選擇OpenStack?

從理論上講，NFV可以存在于專用物理服務(wù)器上，也可以運行在云計算中的虛擬服務(wù)器中。但在實踐中，由于沒有涵蓋所有這些選項的統(tǒng)一管理框架，因此很難提供如此廣泛的部署選擇。

為了解決這個問題，我們可以將虛擬功能放在云中，并使用OpenStack作為云軟件平臺。OpenStack有著廣泛的行業(yè)支持，并且它有一個網(wǎng)絡(luò)即服 務(wù)框架，Neutron(以前被稱為Quantum)，其插件能夠支持大部分主流SDN技術(shù)，甚至還能支持一些專有網(wǎng)絡(luò)管理系統(tǒng)(NMS)。然 而，Neutron正在逐漸發(fā)展為滿足云計算的需求，而不是滿足網(wǎng)絡(luò)運營商更廣泛的需求，因此，早期NFV部署將需要為運營商網(wǎng)絡(luò)擴展Neutron，以 涵蓋云計算中不存在的傳統(tǒng)的端到端連接等功能。在這種情況下，開發(fā)人員需要增強Neutron，或者繞過它不支持的模型。

為NFV部署優(yōu)化商用服務(wù)器

NFV和托管虛擬功能的成功取決于這些功能是否可用以及是否能根據(jù)需要來執(zhí)行。ETSI NFV行業(yè)規(guī)范組(ISG)的目標(biāo)就是在商用服務(wù)器上實現(xiàn)這些功能，但這需要通過硬件和軟件進(jìn)行網(wǎng)絡(luò)優(yōu)化。在從網(wǎng)絡(luò)接口到虛擬機的數(shù)據(jù)路徑連接的情況下， 這種優(yōu)化尤其重要。畢竟，根據(jù)網(wǎng)絡(luò)設(shè)備預(yù)期處理的流量以及它們提供的可靠性的不同，網(wǎng)絡(luò)設(shè)備各有不同。NFV主機也是相同的情況，所以相同的優(yōu)化是必要 的。

尋找NFV管理模式：看看TM論壇

部署NFV的第三個問題是管理過程。這需要基于數(shù)據(jù)模型來描述服務(wù)和資源。在NFV出現(xiàn)之前，TM論壇(TMF)就提供了一個合適的(也許是理想的)數(shù)據(jù) 模型：(SID)GB 922。雖然這種模型可能需要進(jìn)行擴展，才能支持虛擬功能和云資源，但這種擴展將是很小范圍的，并且，GB922提供了豐富的模型用于描述服務(wù)(包含虛擬 功能)以及(承載這些功能的)資源。

這個TMF模型極大地簡化了資源和服務(wù)的構(gòu)建和管理，同時，NFV自身的虛擬功能管理理念也可能融入這個較大的TMF模型。

此外，TMF模型可以很容易地部署，不僅能管理從虛擬功能新組成的服務(wù)，而且可以管理傳統(tǒng)配置的服務(wù)，甚至合作伙伴提供的那些服務(wù)。通過一個共同的架構(gòu)來管理所有這些服務(wù)，當(dāng)很多傳統(tǒng)網(wǎng)絡(luò)設(shè)備仍然繼續(xù)使用時，這種模型將允許運營商管理到NFV的過渡。

NFV部署需要非傳統(tǒng)數(shù)據(jù)模型

管理集成和服務(wù)建模代表著最大和最后的NFV部署決策(數(shù)據(jù)模型)。NFV觸及現(xiàn)有網(wǎng)絡(luò)OSS/BSS，以及NMS，云管理系統(tǒng)以及虛擬功能本身的管理。它將需要管理所有用于托管NFV的設(shè)備以及所有周圍的網(wǎng)絡(luò)設(shè)備。

在確定托管功能的最佳位置以及最佳連接方式時，我們需要考慮虛擬化、虛擬功能的機器映像、虛擬網(wǎng)絡(luò)SDN連接和流量模式。這種優(yōu)化任務(wù)很巨大，但真正的挑 戰(zhàn)在于簡單地傳達(dá)這些政策來指導(dǎo)部署，以及收集所需要的管理數(shù)據(jù)。對于這一點，NFV部署需要站在傳統(tǒng)數(shù)據(jù)模型之外來思考。

現(xiàn)代數(shù)據(jù)驅(qū)動的過程模型將數(shù)據(jù)存儲從數(shù)據(jù)/信息模型分離出來，并且，它們使用語義層來描述解譯和關(guān)系。這些可以很容易地適應(yīng)收集器接口來從設(shè)備和功能收集 遙測信息，以及分布接口來以管理系統(tǒng)需要的形式可視化數(shù)據(jù)。IETF已經(jīng)提出使用數(shù)據(jù)倉庫來收集資源信息，用以分布到虛擬功能或者其基礎(chǔ)架構(gòu)到應(yīng)用程序的 信息傳輸(i2aex)架構(gòu)內(nèi)的管理流程。這種語義建模方法還可以讓我們很容易地對NFV ISG指定的接口進(jìn)行準(zhǔn)標(biāo)準(zhǔn)部署。

在NFV部署中，我們是否需要現(xiàn)成的云應(yīng)用?

除了這些基本部署點，我們還需要考慮一些基本問題，例如虛擬功能實際來自哪里。

如果虛擬功能必須被定制開發(fā)為在NFV部署中運行，那么，在功能可用性方面可能存在潛在的延遲。畢竟，開發(fā)人員必須致力于新環(huán)境，這可能導(dǎo)致多個平臺具有 不同的需求集。而在NFV托管云應(yīng)用或網(wǎng)絡(luò)組件的能力將幫助解決這個功能可用性問題，但現(xiàn)成的云應(yīng)用或網(wǎng)絡(luò)功能組件不能利用任何特殊管理、可用性或性能工 具(這些可能被構(gòu)建到NFV規(guī)范中)。正確的答案可能是同時支持現(xiàn)成的應(yīng)用以及具有NFV優(yōu)化行為的定制化應(yīng)用。然后，市場可以自己作出選擇。

在規(guī)范出現(xiàn)之前，我們肯定會看到很多NFV部署。事實上，ISG的工作目標(biāo)并不是描述或者限制部署過程和供應(yīng)商，NFV用戶將在不同的功能和特性上放置不同的價值。隨著部署逐漸展開，我們將看到NFV可以做什么，到時候，我們將能夠判斷這會是怎樣的一場革命。