SDN和NVF的思想和目標是利用現有網路和計算資源，基於Fabric架構實現業務和網路服務敏捷發放。SDN更加強調控制和管理有效分離，而NFV專注網元功能虛擬化。

      目前SND主要包括思科(強調基礎自己網路硬體)和Vmware(強調整合自己的NSX軟體)兩大陣營，當然還有其他SDN解決方案，下面分別詳細介紹一下。

      思科基於ACI(以應用為中心的基礎設施)，主要講網路資料平面和控制層面分離，北向介面實現應用對控制器策略可程式設計，南向介面實現不同物理交換機透明化集中管理，ACI架構基礎單元。

• 1）網路策略模型，即將網路裝置按容器式結構劃分以及描述裝置連線情況的組織原則；

• 2）APIC(應用基礎設施控制器/即SDN中的控制器)，提供所有配置策略的單獨管理點和資訊庫；

• 3）ACI架構，即組成ACI的所有物理和虛擬網路裝置的抽象概念。

      基於WMware的NSX主要由NSX管理器、NSX控制器、NSXEdge和NSX交換機組成。

      Open Networking Foundation(ONF) 標準化OpenFlow架構是通過在某個集中部件(比如控制器)進行軟體的邏輯執行，並通過使用南向協議/應用程式介面(API)對交換機(硬體商品)進行指令程式設計。

      Open vSwitch(OVS)是OpenFlow開源實現，由Nicira Networks

      Open Daylight是由思科、IBM領導的OpenFlow開源實現，隸屬於Linux基金會。

      開源ONOS(Open Network Operating System)是華為的SDN戰略方向，ONOS含有全域性網路檢視功能，在叢集中通過ONOS伺服器管理和共享網路狀態，在每個ONOS例項中發現的網路拓撲和狀態，如交換機埠、鏈路和主機資訊構成全域性網路檢視，並從全域性網路檢視中讀取應用程式確定轉發策略，然後將轉發策略依次寫到網路檢視中，當檢視資訊發生變化時，將變化訊息傳送到相應的OpenFlow控制器並下發到在指定的交換機上。

      IETF的SDN體系架構是基於I2RS(Interface to the Routing System)支援的SDN體系架構。I2RS主張在現有的網路層協議基礎上，增加外掛(Plug-in)，並在網路與應用層之間增加SDN Orchestrator進行能力開放的封裝，而不是直接採用OpenFlow進行能力開放，目的是儘量保留和重用現有的各種路由協議和IP網路技術。

      NFV主要是針對運營商業務，通過Hypervisor方法提供硬體虛擬化，在伺服器等虛擬化的基礎上實現虛擬網元vIMS、vEPC /vMSE、vFamily (vSTB /vAR /vRGW)功能，以虛擬交換機實現VMs和物理介面對接，實現管理自動化，提高資源使用率、可靠等訴求。

      NFV主要的標準組織有ETSI和OPNFV。ETSI(歐洲電信標準協會)發起一個網路功能虛擬化標準工作組(VFNISG)，OPNFV由華為，思科和愛立信主導。

      電信運營商和通訊服務提供商(CSP)一直期待網路功能虛擬化(NFV)和軟體定義網路(SDN)能夠帶來的優勢，以幫助他們進入快速部署新服務，實現高度的網路自動化和動態重新配置的領域，從而降低資本支出/運營成本，並且易於配置和管理。

      業界為實現這一目標，紛紛推出了多種開源計劃。歐洲電信標準協會(ETSI)推出了開源NFV管理和編排(MANO)架構，吸引了大量的一級CSP和廠商的加入。其中一些CSP已經進行了現場試驗，甚至有些一級運營商已經在現網中通過SDN和NFV部分實現虛擬化，解決方案廠商還建立了增強的NFV/SDN平臺和優化的虛擬網路功能(VNF)。

      然而，業界因為這些紛繁複雜的開源專案變得很分散，因為每個開源專案都有自己的優點，因此導致了CSP的混亂。而潛在的影響SDN/NFV優勢的問題也沒有得到解決。

現狀：多個開源SDN/NFV舉措導致混亂

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

      這些開源專案都是一些業界權威的組織、社群、廠商和幾個一級CSP主導並驅動的，這使得大多數CSP難以選擇一個開源專案或開源專案的組合。

      CSP更希望的是通過開源的方式，避免廠商的鎖定，但是CSP更希望需要看到SDN/NFV帶來的更快的生產路徑，並保證效能、可擴充套件性和長期的支援的優勢。

      系統整合商在CSP採用SDN和NFV的過程中並不總是有幫助，有些系統整合商將CSP作為自己學習的研發實驗室。通過支援多個開源計劃，系統整合商可能會嘗試在多個專案中分離一級使用者。

挑戰：基本問題有待解決

      CSP需要清楚並回答出以下問題，然後再去嘗試選擇SDN/NFV的道路。NFV/SDN虛擬化網路能否通過資料中心執行的COTS硬體來滿足和擴大網路頻寬需求的增長?

• CSP能否採用一個或多個開源專案，並在短期內以成本化的方式投入生產?

• 部署SDN/NFV系統時，CSP是否可以訪問適當的測試系統和工具來驗證並量化效能指標? CSP甚至可以為NFV/SDN虛擬化網路系統設定明確的規範，以滿足效能要求。

• SDN/NFV是否與CSP的傳統網路系統整合，並提供統一的儀表板和監視檢視? 傳統網路工具和虛擬化網路工具如何整合才能提供整個網路的統一檢視?

• CSP怎麼保證選用的開源專案在未來的十年左右能夠不斷升級進步?誰來保證開源專案不斷升級進步? 系統整合商、元件供應商、開源社群還是相關的開源組織?

• SDN/NFV虛擬化網路後期的支援、升級、託管服務的複雜性實際上低於現有的傳統系統? 例如，目前管理私有云資料中心的安全性，其中NFV/SDN系統的託管管理比管理分散式網路系統複雜得多，管理混合網路比管理當前的傳統網路複雜性低一些嗎?

• SDN/NFV系統如何滿足CSP在SLA、QoS、服務保障、高可用性和可靠性等方面的需求? 相關的引數能夠在虛擬化/混合系統中量化嗎? 如果不能，新的標準是什麼?

• 不同廠商開發的單獨的VNF所使用的微服務、容器、DevOps、REST API規則能否與MANO介面規範保持一致性?

• CSP能夠不面臨威脅地安心地執行他們的SDN/NFV系統嗎? 例如，SDN控制器的集中化實際上可能暴露出了更多的安全漏洞。以此類推，NFV堆疊有不同廠商建立的OS、管理程式和VNF。CSP是否需要全面分析各個層級的安全漏洞，並且對這些漏洞加以修復?

      在傳統的硬體網路中，CSP在十多年中實現了網路頻寬的快速增長。雖然傳統的系統管理變得非常複雜，但這些傳統的硬體能夠很可靠的執行，CSP可以設定SLA。新的網路裝置解決方案還附帶了一系列網路自動化工具，便於配置和管理。NFV/SDN系統不僅要使系統更易於部署和管理，而且還能滿足所有效能指標和未來網路頻寬需求。

SDN/NFV未來之路

      在CSP作出最終決定之前，需要對開源社群、系統整合商和解決方案提供商的開源計劃的可持續發展、效能、規模等作出評估。CSP可能還需要諮詢能夠獨立測試和驗證虛擬化/混合網路的公司，同樣，解決方案提供商需要構建測試架構來驗證虛擬化/混合網路的效能指標。

      開源的舉措必須由目標驅動，目標是讓大多數CSP能夠將之應用於生產環境。標準組織需要繼續專注於加強介面/API層，以實現各廠商元件的整合和互操作性。CSP同樣也要對廠商解決方案加以重視，這些解決方案是現場測試的、可擴充套件的，並且已經引入了網路自動化。

      在未來幾年中，CSP網路將不得不跟上頻寬需求的增長，需要達成硬體驅動的網路解決方案和基於NFV/SDN的虛擬化途徑的平衡，基於COTS硬體的NFV/SDN可能無法擴充套件CSP的網路以滿足不斷增長的頻寬需求。

相關閱讀

溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”下面二維碼關注公眾號，獲取更多精彩內容。

聽說點贊和分享的朋友都已走上人生巔峰