軟件定義網絡吸引了很多云和網絡提供商的興趣，但是很多提供商卻由于SDN技術的現狀而感到沮喪。大多數大型提供商能夠至少運行小范圍的SDN小規模測試或者實驗，但是都遭遇了大范圍部署的問題。那么SDN中缺少了什么?提供商如何識別這些缺失的元素，以便他們能夠完全的利用這項技術?

1、缺少全設備控制標準

妨礙SDN采用最顯著的障礙就是缺少對于所有設備的控制標準。OpenFlow框架是現在使用的一種事實SDN標準，這是一種單項轉發表升級協議，不提供確定設備狀態的機制，不允許程序接口或者外線接口。無法處理非封包流，比如波長流。有人可能會說OpenFlow的這個框架是一些受限實驗的副產品，而不是一種機制，旨在支持通用的網絡服務創建。

很多人已經指出OpenFlow并不能完成基本的設備安裝，這也意味著更多傳統管理標準，比如簡單網絡管理協議(SNMP)，就必須應用來實現這個目標。這里的問題在于傳統管理標準需要完全同這些設備連接。這也回到問題的實質：在每一個路由器必須單獨建立時，如何使用?

2、缺少服務控制軟件

SDN技術第二大的問題在于服務控制軟件，這項技術實際上在軟件定義網絡中構建了路由和控制流量。不管提供商考慮的SDN模型是什么，都需要軟件鏈接應用服務到SDN基礎架構中。對于云計算而言，這通常是一個和云虛擬網絡控制(OpenStack的Quantum)或者DevOps工具相關關聯的插件，用于分配云資源。

即使有OpenFlow和SDN控制器，每一個SDN實現都需要服務控制軟件來創建虛擬網絡。這是因為SDN控制器僅將路由需求翻譯成了一系列轉發表變化;他們本身不能創建路由。然而，SDN控制器有時候提供北向應用程序接口，這個服務控制軟件可以被連接，一些廠商甚至至少提供了這個軟件的基本版本，對于沒有基于OpenFlow的SDN實現，每一個網絡設備廠商必須提供必要的服務控制軟件。這個領域通過互聯網工程任務組(IETF)的一些工作在應用層流量優化開發(ALTO)中表現。

3、多廠商網絡控制成應用障礙

上面提到的也為我們引入了SDN采用的第三個障礙：多廠商網絡控制。服務控制軟件可以在多個廠商網絡之上執行控制，通過 OpenFlow、Border Gateway Patrol (BGP)和Multiprotocol Label Switching實現，提供了給軟件，讓其了解網絡情況，按需調整路由的策略。

對于集中化和分布式的SDN模型，控制軟件知道所有網絡設備和中繼線的狀態很重要，不管包含什么設備。協議和標準如SNMP和遠程網絡監控或者RMON，可以協助收集一些信息，IETF增強功能(BGP-LS)到BGP，還有一些舉措，比如基礎架構到應用信息暴露或者i2aex，可以提供替代資源。在一些案例中，網絡中的示例部署并鏈接到中央控制軟件工具可以提供更多數據。SDN網絡狀態的遙感測試需求已經推進了一股收購和并購浪潮，因此SDN廠商很可能在這個領域增加產品。

4、集中化網絡中管理控制流量

服務控制軟件和多廠商網絡遙感技術的結合也闡明了SDN的第四種缺失：在集中化網絡中控制流量管理。網絡云營商已經指出來自一些應用的網絡探頭的遙感流量快要超過實際的應用流量了。在任何SDN模型中，信息在哪里收集起來支持中央網絡行為監控，就應該在這些價值和交付過多信息給中央點之間有一個平衡。

網絡運營商早就提出虛擬化網絡功能，會進一步增加網絡中的控制流量總量。但是網絡功能虛擬化也創造了SDN的替代架構，分層分布流程的混合物，關注與沒有集中化流量和失敗點的決策。

5、需要邊界功能

最后的SDN缺失也許最為陰暗，因為很可能影響所有實際的SDN部署。企業和網絡運營商最可能在單獨的網絡領域發布SDN，而不是在全球范圍內。沒有具體模型的服務控制軟件，軟件定義網絡要多久才能夠擴展還不明朗。如果SDN區域包圍在遺留網絡中，如何處理邊界功能?內部SDN實現一個IP網絡為例，必須提供IP網絡和發現信息，必須從遺留網絡中獲得可到達能力和拓撲數據，從而讓服務控制軟件來管理SDN路由。網絡如何提供這些信息?多種SND包圍的區域如何互聯?IETF在草案中考慮了后一個問題，旨在進行SDN互聯，或者SDNi。

彌補SDN代溝

這些缺失的內容導致了早起SDN應用受限：數據中心。如果SDN取代了數據中心以太網交換機，明確規定每一個路由變得很實際，甚至是創建一個單獨的網絡控制來鏈接設備管理鏈接。隨著其采用逐漸擴展到數據中心之外，SDN需要支持臨近的遺留網絡組建和描述自己服務的架構框架。提供這種擴展需要分辨所有的SDN缺失鏈接。

提供商想要修復這些缺失部分需要根據他們選擇的SDN模型選出最佳的方法。對于那些對于集中化、基于OpenFlow的SDN模型感興趣的人來說，標準的最佳信息源就是Open Networking Foundation網站和相關會議。