電信運(yùn)營(yíng)商和通信服務(wù)提供商(CSP)一直期待網(wǎng)絡(luò)功能虛擬化(NFV)和軟件定義網(wǎng)絡(luò)(SDN)能夠帶來(lái)的優(yōu)勢(shì),以幫助他們進(jìn)入快速部署新服務(wù),實(shí)現(xiàn)高度的網(wǎng)絡(luò)自動(dòng)化和動(dòng)態(tài)重新配置的領(lǐng)域,從而降低資本支出/運(yùn)營(yíng)成本,并且易于配置和管理。
業(yè)界為實(shí)現(xiàn)這一目標(biāo),紛紛推出了多種開源計(jì)劃。歐洲電信標(biāo)準(zhǔn)協(xié)會(huì)(ETSI)推出了開源NFV管理和編排(MANO)架構(gòu),吸引了大量的一級(jí)CSP和廠商的加入。其中一些CSP已經(jīng)進(jìn)行了現(xiàn)場(chǎng)試驗(yàn),甚至有些一級(jí)運(yùn)營(yíng)商已經(jīng)在現(xiàn)網(wǎng)中通過SDN和NFV部分實(shí)現(xiàn)虛擬化,解決方案廠商還創(chuàng)建了增強(qiáng)的NFV/SDN平臺(tái)和優(yōu)化的虛擬網(wǎng)絡(luò)功能(VNF)。
然而,業(yè)界因?yàn)檫@些紛繁復(fù)雜的開源項(xiàng)目變得很分散,因?yàn)槊總€(gè)開源項(xiàng)目都有自己的優(yōu)點(diǎn),因此導(dǎo)致了CSP的混亂。而潛在的影響SDN/NFV優(yōu)勢(shì)的問題也沒有得到解決。
現(xiàn)狀:多個(gè)開源SDN/NFV舉措導(dǎo)致混亂
目前在采用多個(gè)NFV/SDN開源路徑時(shí),CSP面臨“選擇障礙癥”,有Open-O、AT&T的ECOMP(ECOMP和Open-O目前已經(jīng)被Linux基金會(huì)合并為ONAP)ETSI的OSM,OPNFV可供選擇。雖然ECOMP和Open-O合并能否取得成功還有待觀察,但可以預(yù)見的是ONAP將和ETSI OSM在NFV管理和編排領(lǐng)域展開競(jìng)爭(zhēng)。同時(shí)諸如MEF LSO等新舉措正在受到業(yè)界的重視,包括與運(yùn)營(yíng)支撐系統(tǒng)(OSS)/業(yè)務(wù)支撐系統(tǒng)(BSS)更深層次的整合。在SDN方面,成熟的開源計(jì)劃包括ONOS和ODL。
這些開源項(xiàng)目都是一些業(yè)界權(quán)威的組織、社區(qū)、廠商和幾個(gè)一級(jí)CSP主導(dǎo)并驅(qū)動(dòng)的,這使得大多數(shù)CSP難以選擇一個(gè)開源項(xiàng)目或開源項(xiàng)目的組合。
CSP更希望的是通過開源的方式,避免廠商的鎖定,但是CSP更希望需要看到SDN/NFV帶來(lái)的更快的生產(chǎn)路徑,并保證性能、可擴(kuò)展性和長(zhǎng)期的支持的優(yōu)勢(shì)。
系統(tǒng)集成商在CSP采用SDN和NFV的過程中并不總是有幫助,有些系統(tǒng)集成商將CSP作為自己學(xué)習(xí)的研發(fā)實(shí)驗(yàn)室。通過支持多個(gè)開源計(jì)劃,系統(tǒng)集成商可能會(huì)嘗試在多個(gè)項(xiàng)目中分離一級(jí)用戶。
挑戰(zhàn):基本問題有待解決
CSP需要清楚并回答出以下問題,然后再去嘗試選擇SDN/NFV的道路:
1、NFV/SDN虛擬化網(wǎng)絡(luò)能否通過數(shù)據(jù)中心運(yùn)行的COTS硬件來(lái)滿足和擴(kuò)大網(wǎng)絡(luò)帶寬需求的增長(zhǎng)?
2、CSP能否采用一個(gè)或多個(gè)開源項(xiàng)目,并在短期內(nèi)以成本化的方式投入生產(chǎn)?
3、部署SDN/NFV系統(tǒng)時(shí),CSP是否可以訪問適當(dāng)?shù)臏y(cè)試系統(tǒng)和工具來(lái)驗(yàn)證并量化性能指標(biāo)?CSP甚至可以為NFV/SDN虛擬化網(wǎng)絡(luò)系統(tǒng)設(shè)定明確的規(guī)范,以滿足性能要求。
4、SDN/NFV是否與CSP的傳統(tǒng)網(wǎng)絡(luò)系統(tǒng)集成,并提供統(tǒng)一的儀表板和監(jiān)視視圖?傳統(tǒng)網(wǎng)絡(luò)工具和虛擬化網(wǎng)絡(luò)工具如何集成才能提供整個(gè)網(wǎng)絡(luò)的統(tǒng)一視圖?
5、CSP怎么保證選用的開源項(xiàng)目在未來(lái)的十年左右能夠不斷升級(jí)進(jìn)步?誰(shuí)來(lái)保證開源項(xiàng)目不斷升級(jí)進(jìn)步?系統(tǒng)集成商、組件供應(yīng)商、開源社區(qū)還是相關(guān)的開源組織?
6、SDN/NFV虛擬化網(wǎng)絡(luò)后期的支持、升級(jí)、托管服務(wù)的復(fù)雜性實(shí)際上低于現(xiàn)有的傳統(tǒng)系統(tǒng)?例如,目前管理私有云數(shù)據(jù)中心的安全性,其中NFV/SDN系統(tǒng)的托管管理比管理分布式網(wǎng)絡(luò)系統(tǒng)復(fù)雜得多,管理混合網(wǎng)絡(luò)比管理當(dāng)前的傳統(tǒng)網(wǎng)絡(luò)復(fù)雜性低一些嗎?
7、SDN/NFV系統(tǒng)如何滿足CSP在SLA、QoS、服務(wù)保障、高可用性和可靠性等方面的需求?相關(guān)的參數(shù)能夠在虛擬化/混合系統(tǒng)中量化嗎?如果不能,新的標(biāo)準(zhǔn)是什么?
8、不同廠商開發(fā)的單獨(dú)的VNF所使用的微服務(wù)、容器、DevOps、REST API規(guī)則能否與MANO接口規(guī)范保持一致性?
9、CSP能夠不面臨威脅地安心地運(yùn)行他們的SDN/NFV系統(tǒng)嗎?例如,SDN控制器的集中化實(shí)際上可能暴露出了更多的安全漏洞。以此類推,NFV堆棧有不同廠商創(chuàng)建的OS、管理程序和VNF。CSP是否需要全面分析各個(gè)層級(jí)的安全漏洞,并且對(duì)這些漏洞加以修復(fù)?
在傳統(tǒng)的硬件網(wǎng)絡(luò)中,CSP在十多年中實(shí)現(xiàn)了網(wǎng)絡(luò)帶寬的快速增長(zhǎng)。雖然傳統(tǒng)的系統(tǒng)管理變得非常復(fù)雜,但這些傳統(tǒng)的硬件能夠很可靠的運(yùn)行,CSP可以設(shè)置SLA。新的網(wǎng)絡(luò)設(shè)備解決方案還附帶了一系列網(wǎng)絡(luò)自動(dòng)化工具,便于配置和管理。NFV/SDN系統(tǒng)不僅要使系統(tǒng)更易于部署和管理,而且還能滿足所有性能指標(biāo)和未來(lái)網(wǎng)絡(luò)帶寬需求。
未來(lái)之路
在CSP作出最終決定之前,需要對(duì)開源社區(qū)、系統(tǒng)集成商和解決方案提供商的開源計(jì)劃的可持續(xù)發(fā)展、性能、規(guī)模等作出評(píng)估。CSP可能還需要咨詢能夠獨(dú)立測(cè)試和驗(yàn)證虛擬化/混合網(wǎng)絡(luò)的公司,同樣,解決方案提供商需要構(gòu)建測(cè)試架構(gòu)來(lái)驗(yàn)證虛擬化/混合網(wǎng)絡(luò)的性能指標(biāo)。開
源的舉措必須由目標(biāo)驅(qū)動(dòng),目標(biāo)是讓大多數(shù)CSP能夠?qū)⒅畱?yīng)用于生產(chǎn)環(huán)境。標(biāo)準(zhǔn)組織需要繼續(xù)專注于加強(qiáng)接口/API層,以實(shí)現(xiàn)各廠商組件的集成和互操作性。CSP同樣也要對(duì)廠商解決方案加以重視,這些解決方案是現(xiàn)場(chǎng)測(cè)試的、可擴(kuò)展的,并且已經(jīng)引入了網(wǎng)絡(luò)自動(dòng)化。
在未來(lái)幾年中,CSP網(wǎng)絡(luò)將不得不跟上帶寬需求的增長(zhǎng),需要達(dá)成硬件驅(qū)動(dòng)的網(wǎng)絡(luò)解決方案和基于NFV/SDN的虛擬化途徑的平衡,基于COTS硬件的NFV/SDN可能無(wú)法擴(kuò)展CSP的網(wǎng)絡(luò)以滿足不斷增長(zhǎng)的帶寬需求。
原文鏈接:https://www.sdxcentral.com/articles/contributed/nfvsdn-reality-challenges-guidance/2017/04/