SDN/NFV：現狀，挑戰和未來(lái)

　　電信運營(yíng)商和通信服務(wù)提供商(CSP)一直期待網(wǎng)絡(luò )功能虛擬化(NFV)和軟件定義網(wǎng)絡(luò )(SDN)能夠帶來(lái)的優(yōu)勢，以幫助他們進(jìn)入快速部署新服務(wù)，實(shí)現高度的網(wǎng)絡(luò )自動(dòng)化和動(dòng)態(tài)重新配置的領(lǐng)域，從而降低資本支出/運營(yíng)成本，并且易于配置和管理。

　　業(yè)界為實(shí)現這一目標，紛紛推出了多種開(kāi)源計劃。歐洲電信標準協(xié)會(huì )(ETSI)推出了開(kāi)源NFV管理和編排(MANO)架構，吸引了大量的一級CSP和廠(chǎng)商的加入。其中一些CSP已經(jīng)進(jìn)行了現場(chǎng)試驗，甚至有些一級運營(yíng)商已經(jīng)在現網(wǎng)中通過(guò)SDN和NFV部分實(shí)現虛擬化，解決方案廠(chǎng)商還創(chuàng )建了增強的NFV/SDN平臺和優(yōu)化的虛擬網(wǎng)絡(luò )功能(VNF)。

　　然而，業(yè)界因為這些紛繁復雜的開(kāi)源項目變得很分散，因為每個(gè)開(kāi)源項目都有自己的優(yōu)點(diǎn)，因此導致了CSP的混亂。而潛在的影響SDN/NFV優(yōu)勢的問(wèn)題也沒(méi)有得到解決。

　　現狀：多個(gè)開(kāi)源SDN/NFV舉措導致混亂

　　目前在采用多個(gè)NFV/SDN開(kāi)源路徑時(shí)，CSP面臨“選擇障礙癥”，有Open-O、AT&T的ECOMP(ECOMP和Open-O目前已經(jīng)被Linux基金會(huì )合并為ONAP)ETSI的OSM，OPNFV可供選擇。雖然ECOMP和Open-O合并能否取得成功還有待觀(guān)察，但可以預見(jiàn)的是ONAP將和ETSI OSM在NFV管理和編排領(lǐng)域展開(kāi)競爭。同時(shí)諸如MEF LSO等新舉措正在受到業(yè)界的重視，包括與運營(yíng)支撐系統(OSS)/業(yè)務(wù)支撐系統(BSS)更深層次的整合。在SDN方面，成熟的開(kāi)源計劃包括ONOS和ODL。

　　這些開(kāi)源項目都是一些業(yè)界權威的組織、社區、廠(chǎng)商和幾個(gè)一級CSP主導并驅動(dòng)的，這使得大多數CSP難以選擇一個(gè)開(kāi)源項目或開(kāi)源項目的組合。

　　CSP更希望的是通過(guò)開(kāi)源的方式，避免廠(chǎng)商的鎖定，但是CSP更希望需要看到SDN/NFV帶來(lái)的更快的生產(chǎn)路徑，并保證性能、可擴展性和長(cháng)期的支持的優(yōu)勢。

　　系統集成商在CSP采用SDN和NFV的過(guò)程中并不總是有幫助，有些系統集成商將CSP作為自己學(xué)習的研發(fā)實(shí)驗室。通過(guò)支持多個(gè)開(kāi)源計劃，系統集成商可能會(huì )嘗試在多個(gè)項目中分離一級用戶(hù)。

　　挑戰：基本問(wèn)題有待解決

　　CSP需要清楚并回答出以下問(wèn)題，然后再去嘗試選擇SDN/NFV的道路：

　　1、NFV/SDN虛擬化網(wǎng)絡(luò )能否通過(guò)數據中心運行的COTS硬件來(lái)滿(mǎn)足和擴大網(wǎng)絡(luò )帶寬需求的增長(cháng)?

　　2、CSP能否采用一個(gè)或多個(gè)開(kāi)源項目，并在短期內以成本化的方式投入生產(chǎn)?

　　3、部署SDN/NFV系統時(shí)，CSP是否可以訪(fǎng)問(wèn)適當的測試系統和工具來(lái)驗證并量化性能指標?CSP甚至可以為NFV/SDN虛擬化網(wǎng)絡(luò )系統設定明確的規范，以滿(mǎn)足性能要求。

　　4、SDN/NFV是否與CSP的傳統網(wǎng)絡(luò )系統集成，并提供統一的儀表板和監視視圖?傳統網(wǎng)絡(luò )工具和虛擬化網(wǎng)絡(luò )工具如何集成才能提供整個(gè)網(wǎng)絡(luò )的統一視圖?

　　5、CSP怎么保證選用的開(kāi)源項目在未來(lái)的十年左右能夠不斷升級進(jìn)步?誰(shuí)來(lái)保證開(kāi)源項目不斷升級進(jìn)步?系統集成商、組件供應商、開(kāi)源社區還是相關(guān)的開(kāi)源組織?

　　6、SDN/NFV虛擬化網(wǎng)絡(luò )后期的支持、升級、托管服務(wù)的復雜性實(shí)際上低于現有的傳統系統?例如，目前管理私有云數據中心的安全性，其中NFV/SDN系統的托管管理比管理分布式網(wǎng)絡(luò )系統復雜得多，管理混合網(wǎng)絡(luò )比管理當前的傳統網(wǎng)絡(luò )復雜性低一些嗎?

　　7、SDN/NFV系統如何滿(mǎn)足CSP在SLA、QoS、服務(wù)保障、高可用性和可靠性等方面的需求?相關(guān)的參數能夠在虛擬化/混合系統中量化嗎?如果不能，新的標準是什么?

　　8、不同廠(chǎng)商開(kāi)發(fā)的單獨的VNF所使用的微服務(wù)、容器、DevOps、REST API規則能否與MANO接口規范保持一致性?

　　9、CSP能夠不面臨威脅地安心地運行他們的SDN/NFV系統嗎?例如，SDN控制器的集中化實(shí)際上可能暴露出了更多的安全漏洞。以此類(lèi)推，NFV堆棧有不同廠(chǎng)商創(chuàng )建的OS、管理程序和VNF。CSP是否需要全面分析各個(gè)層級的安全漏洞，并且對這些漏洞加以修復?

　　在傳統的硬件網(wǎng)絡(luò )中，CSP在十多年中實(shí)現了網(wǎng)絡(luò )帶寬的快速增長(cháng)。雖然傳統的系統管理變得非常復雜，但這些傳統的硬件能夠很可靠的運行，CSP可以設置SLA。新的網(wǎng)絡(luò )設備解決方案還附帶了一系列網(wǎng)絡(luò )自動(dòng)化工具，便于配置和管理。NFV/SDN系統不僅要使系統更易于部署和管理，而且還能滿(mǎn)足所有性能指標和未來(lái)網(wǎng)絡(luò )帶寬需求。

　　未來(lái)之路

　　在CSP作出最終決定之前，需要對開(kāi)源社區、系統集成商和解決方案提供商的開(kāi)源計劃的可持續發(fā)展、性能、規模等作出評估。CSP可能還需要咨詢(xún)能夠獨立測試和驗證虛擬化/混合網(wǎng)絡(luò )的公司，同樣，解決方案提供商需要構建測試架構來(lái)驗證虛擬化/混合網(wǎng)絡(luò )的性能指標。開(kāi)

　　源的舉措必須由目標驅動(dòng)，目標是讓大多數CSP能夠將之應用于生產(chǎn)環(huán)境。標準組織需要繼續專(zhuān)注于加強接口/API層，以實(shí)現各廠(chǎng)商組件的集成和互操作性。CSP同樣也要對廠(chǎng)商解決方案加以重視，這些解決方案是現場(chǎng)測試的、可擴展的，并且已經(jīng)引入了網(wǎng)絡(luò )自動(dòng)化。

　　在未來(lái)幾年中，CSP網(wǎng)絡(luò )將不得不跟上帶寬需求的增長(cháng)，需要達成硬件驅動(dòng)的網(wǎng)絡(luò )解決方案和基于NFV/SDN的虛擬化途徑的平衡，基于COTS硬件的NFV/SDN可能無(wú)法擴展CSP的網(wǎng)絡(luò )以滿(mǎn)足不斷增長(cháng)的帶寬需求。

　　原文鏈接：https://www.sdxcentral.com/articles/contributed/nfvsdn-reality-challenges-guidance/2017/04/