- SDN 將控制平面與資料平面分離，因此可使用 OpenFlow 等開放控制器和 API 對網路進行程式設計。
- 與傳統網路相比，軟體定義網路簡化了管理，提高了可見度和可擴展性，並降低了資本支出和營運支出。
- 其架構基於 SDN 應用、集中式邏輯控制器和可程式資料路徑，並透過南北介面進行協調。
- ONF 和其他參與者正在推動涵蓋企業廣域網路、資料中心、雲端、大數據和物聯網的標準和實際用例。
軟體定義網路 (SDN)徹底改變了通訊基礎架構的設計、部署和管理方式。曾經由實體設備和手動配置構成的僵化框架，現在可以像編寫程式碼一樣進行管理，速度更快、更靈活，並且能夠更清晰地了解網路各個角落的運作狀況。
這種新方法並非憑空而來：它是數十年研究和多項技術里程碑的成果，從20世紀90年代的活躍網路到OpenFlow的標準化，再到控制器、API和應用程式等完整生態系統的建構。讓我們一步步了解它的發展歷程，SDN解決了哪些問題，它的內部運作原理，以及它如今在哪些實際應用場景中發揮作用。
軟體定義網路（SDN）的起源和歷史
SDN 的故事始於大約20 年前，商業互聯網的萌芽時期。當時，全球網路的成功表明，通訊基礎設施需要能夠更輕鬆地進行修改和演進。從那時起，我們可以區分出三個主要階段，它們為我們今天所說的 SDN 鋪平了道路。
第一階段對應於活躍網絡（約在 1995 年至 2000 年）。其理念是將網路開放給編程，類似於對 PC 進行編程的方式，但應用於每個通訊節點。為了實現這一目標，網路設備中定義了一個 API ，該 API 公開了運算能力、儲存空間、封包佇列和處理功能等資源，從而允許載入程式碼，為特定的流量應用自訂行為。
這種方法與那些認為網路要擴展並保持正常運作的唯一方法是盡可能簡化網路的人的觀點相悖。即便如此，積極的網路計畫仍然推動了關鍵性的進步：運算成本的降低、程式語言的改進、虛擬機器的興起，以及最重要的，將網路視為可程式平台而非僅僅是一系列封閉設備的集合這一理念。
那個時代的一個重要催化劑是DARPA等機構的支持，DARPA啟動了「主動網路計畫」，該計畫從90年代中期一直持續到2000世紀初。儘管主動網路從未實現大規模部署，但它們播下了後來成為SDN基礎的概念：網路中的可編程功能、資源虛擬化以及對不同設備（防火牆、IDS、NAT等）的統一視圖。
隨著十年的到來和流量的爆炸性增長，第二階段開始了，其重點是控制平面和資料平面的分離（2001-2007 年）。傳統的路由器和交換器將控制邏輯（路由選擇、路由協定）和資料平面（實際的資料包轉送）整合在同一設備中，這使得偵錯錯誤、調整流量工程或引入新服務變得非常困難。
為了應對這種情況，營運商開始在專用硬體上實現封包轉發，同時控制功能保持相對獨立。同時，他們也在尋求管理日益龐大和複雜的網路的方法，例如VPN和其他高級功能。由此產生了兩條創新路線：一方面是控制和轉發之間的開放接口，例如ForCES（IETF）或Linux上的Netlink；另一方面是具有集中式邏輯控制的架構，例如RCP、SoftRouter或PCE協議，這些架構允許從全局視角做出路由決策。
第三階段隨著Project 4D 和後續的 Ethane 的出現而到來，它們將中央邏輯控制器的概念具體化，該控制器具有四個清晰定義的平面：資料平面（根據規則處理資料包）、發現平面（收集拓撲和流量資訊）、分發平面（部署處理規則）和決策平面（將全局策略轉換為具體規則）。 Ethane 已部署在史丹佛大學等實際環境中，其極其簡潔的交換器設計已成為我們今天所知的OpenFlow的基礎。
同時，實驗生態系統也在不斷發展：PlanetLab 和 Emulab 等基礎設施、GENI 和歐洲 FIRE 項目等項目，以及史丹佛大學的 Clean Slate 項目，都促進了對各種替代網路架構的大規模測試。正是在這種環境下，OpenFlow 應運而生，成為利用標準 API 將交換器轉送功能暴露給外部控制器的實用方法。
Avaya 在 2014 年的展示是業界的一個重要里程碑，它將最短路徑橋接與 OpenStack 相結合，建立了只需極少人工配置的軟體定義網路。此外，由於簡單的韌體更新，許多商用交換器也逐漸開始支援 OpenFlow，而無需進行硬體變更。
SDN 解決了傳統網路的哪些問題？
傳統網路幾乎完全基於獨立配置的實體設備，在應對企業、服務提供者和最終用戶當前的需求時，其效能已接近極限。其主要弱點在於多年累積的複雜性。
為了涵蓋所有可能的情況，業界不斷添加越來越具體的網路協定來解決特定問題（例如安全性、效率、冗餘性等），但這些協定通常是獨立設計的。結果是形成了一個錯綜複雜的機製網絡，必須手動協調，缺乏一個通用的抽象層來簡化整體。
當組織希望在整個網路中實施一致的策略時——例如，確定哪些使用者可以存取哪些資源——管理員必須修改數百或數千台設備。即使是增加一台新的虛擬機器這樣簡單的操作，也可能需要修改散佈在整個環境中的大量存取控制清單 (ACL)，這不僅存在人為錯誤的風險，還會導致數小時的延誤。
缺乏可擴展性是另一個嚴峻的問題。資料中心的興起、使用者的成長以及流量的增加，都要求增加越來越多的設備。每增加一台設備，就意味著更多的配置、更多的管理以及更多的潛在故障點。要讓這一切都與業務需求保持一致，簡直難如登天。
從經濟角度來看，企業嚴重依賴製造商的產品週期。如果需要新的網路功能，僅僅更新軟體往往是不夠的：企業必須等待供應商發布合適的型號，完成內部認證，採購設備，進行部署——這個過程可能需要數年時間，並扼殺創新。
更糟的是，近期的趨勢使情況更加複雜：流量模式呈現出更加多樣化的趨勢，包括機器間通訊、分散式資料庫、微服務，以及使用者隨時隨地使用手機、平板電腦和筆記型電腦進行連線。隨著傳統網路邊界的逐漸消失，管理員的工作量也隨之增加，他們需要在保護敏感資料的同時，應對日益嚴峻的挑戰。
此外，雲端服務（SaaS、IaaS、PaaS）的快速發展也帶來了新的挑戰，這些服務需要快速部署、動態擴展運算、儲存和網路資源，以及更複雜的安全要求。大數據時代的到來需要跨越數千台伺服器的海量頻寬和傳輸容量，而傳統網路往往難以滿足這項需求。
SDN 究竟是什麼？它如何解決問題？
軟體定義網路（SDN）作為一種新型架構應運而生，旨在為網路提供靈活性、集中控制和可程式性，將複雜性從硬體轉移到軟體層面。它不再是單獨管理每個設備，而是從更高的邏輯層定義所需的網路行為。
其核心原則是將控制平面和資料平面分開。資料平面負責在端點之間高速傳輸資料包；控制平面則決定這些資料包的傳輸方式和路徑，並應用策略、路由和規則。在軟體定義網路（SDN）中，這兩個平面是解耦的，控制權集中在一個或多個邏輯控制器中。
兩者之間會建立一個定義明確的接口，通常透過像 OpenFlow 這樣的標準協定來實現。借助這個接口，控制器可以安裝、修改或刪除交換器和路由器上的轉送規則，使它們能夠像可程式設備一樣運行，而不是封閉的系統。 OpenFlow 並非唯一可用的協議，但它是應用最廣泛的，並且已經成為事實上的標準。
在控制器之上，SDN 應用程式使用北向 API 來表達它們需要從網路獲得的行為：優先處理某些流量、劃分部門、負載平衡、提高服務品質、應對拒絕服務攻擊等等。控制器將這些進階請求轉換為在資料平面中應用的具體轉送規則。
換句話說，SDN 將網路轉變為一個平台，應用程式和服務可以像開發純軟體一樣進行開發，而無需關注每個設備型號或底層協議的細節。這種抽象化有助於自動化，減少錯誤，並能更快適應需求變化。
SDN架構：控制器、API與關鍵元件
典型的SDN網路由多個邏輯層和功能明確的元件所構成。其核心是SDN控制器，它充當網路的大腦，從資料平面收集資訊並執行應用決策。
控制器維護網路的抽象視圖：拓樸結構、每個設備的功能、流量統計資訊、連結狀態等。憑藉這些信息，並依靠可以啟動或停用的插件模組（庫存管理、統計資訊收集、安全模組、負載平衡等），它做出決策，並透過南向 API（通常是 OpenFlow 或其他協議，例如 OVSDB 或 Cisco OpFlex）將這些決策傳達給設備。
資料平面設備——包括實體交換器、虛擬交換器和路由器——實現了 ONF 所稱的SDN 資料路徑：一組邏輯上公開的轉送引擎和流量處理功能。每個資料路徑中都有一個控制介面處理代理程式（CDPI 代理程式），它接收來自控制器的指令，並將其轉換為流程表中的規則或特定的硬體操作。
架構的頂層是SDN應用。這些程式透過北向API（NBI）與控制器通信，並表達業務或技術需求，例如：IP位址管理（IPAM）、服務編排、服務品質（QoS）控制、DoS攻擊防禦系統、進階分析工具等。每個應用程式都包含自身的邏輯以及一個或多個用於與控制器互動的NBI。
在這些模組之間是控製到資料平面介面 (CDPI)，它負責提供轉送可程式性、通告裝置功能、公開統計資料以及通知事件。控制器實現此介面的驅動程序，設備實現代理，因此每個驅動程序/代理對都建立了物理基礎架構和應用程式之間的特定關係。
除了這三個主要層之外，ONF 還定義了一個管理和行政層，該層涵蓋更多靜態任務：為客戶端分配資源、實體設備的基本配置、憑證管理以及邏輯實體和實體實體之間的關聯。這些任務通常在動態流量控制週期之外進行管理。
南北介面與流量規劃模型
南向 API 將控制器連接到硬體或資料路徑。 OpenFlow 是第一個被廣泛採用的介面：它定義了控制器如何在交換器的流程表中添加條目、如何收集統計資料、如何報告諸如資料包不匹配之類的事件等等。其他替代方案，例如 Cisco OpFlex，提出了不同的模型，但其基本想法相同，即允許中心元素影響設備行為。
北向 API允許應用程式與控制器通訊並接收網路的抽象視圖。這裡沒有像 OpenFlow 那樣成熟的標準：在協議棧的不同層級（REST、gRPC、特定 SDK、基於意圖的模型等）存在許多提案和庫，正因如此，ONF 才如此重視定義最佳實踐並朝著兼容的方法靠攏。
在運作層面，控制器可以採用主動式、被動式或混合式模型在設備上實施流規則。在被動式模型中，當交換器收到一個與其規則表中任何條目都不匹配的資料包時，它會向控制器發出查詢；控制器會回應指令，並在必要時為未來類似的資料包建立新規則。
在主動式模型中，控制器會預先安裝預期流量的規則，類似傳統路由表的填滿方式。這可以最大限度地減少即時查詢，並降低初始通訊的延遲。許多實際部署都結合了這兩種模型，既能應對不可預測的流量，又能主動處理已知的流量。
SDN 的真正優勢在於這些開放 API 提供的可程式性。由於這些 API，可以根據負載動態調整路由，優先處理關鍵流量，自動回應故障或安全事件，甚至允許應用程式本身與網路協商所需的條件（頻寬、最大延遲、冗餘等級等）。
SDN中可程式性的應用案例
為了闡明網路可程式性的概念，通常會討論三個主要用例來展示軟體定義網路 (SDN) 在實踐中的應用。第一個用例是流量微調：借助 OpenFlow 等協議，控制器幾乎可以即時決定特定類型流量的傳輸路徑，從而實現鏈路間的負載平衡、避免擁塞，或在必要時應用更嚴格的安全策略。
第二個主要方面在於高階應用支援。網路不再對應用程式的運作一無所知，而是可以公開其需求（例如，語音或視訊的低延遲、特定傳輸的高頻寬、用戶端之間的嚴格隔離），控制器會相應地調整配置以滿足這些需求。此外，自動化部署——尤其是在雲端和大規模虛擬化環境中——可以實現新服務的快速部署，而無需管理員手動更改參數。
第三個關鍵要素是網路維運的自動化。在設計良好的軟體定義網路（SDN）場景中，網路可以自主回應多種事件：連結故障時，路由會自動重新計算；出現可疑流量模式時，應用阻塞規則或將流量重新導向至分析系統；新應用程式啟動時，網路自動分配資源。管理員的角色也從簡單的“修改命令”轉變為定義高級策略並確保其合規性。
SDN 對組織的優勢
SDN 的價值主張為企業和服務提供者帶來了一系列顯而易見的優勢。其中最顯著的優勢之一是集中式管理：透過控制器，可以對整個網路定義存取策略、安全規則、流量優先順序和服務配置，而無需單獨管理每個設備或依賴各廠商的特定介面。
在可擴充性方面，SDN 提供了極高的靈活性。管理員可以近乎即時地新增或移除虛擬設備、分割網路、連接分公司或資料中心，並調整路由，這些操作通常與雲端編排平台整合。所有這些操作對底層實體基礎設施的影響都極小，使其保持相對穩定。
另一個重要優勢在於對網路行為的全面可視性。透過將資訊集中在控制器或一組協同控制器中，可以全面了解網路效能、瓶頸、活躍流量和潛在威脅。這種可視性不僅有助於日常運維，還有助於容量規劃和早期問題檢測。
從經濟角度來看，SDN有助於降低資本支出（CAPEX）和營運支出（OPEX）。一方面，由於許多交換器只需簡單的韌體更新即可啟用SDN功能，因此可以重複利用大部分現有硬體。另一方面，自動化減少了員工在重複性配置任務上花費的時間，降低了人為錯誤，並簡化了維護和升級。
最後一組主要優勢與創新和反應速度有關。透過將硬體和軟體分離，企業可以創建新服務、嘗試不同的商業模式，或使網路適應新的需求（混合雲、物聯網、邊緣運算、大數據），而無需受限於特定製造商的產品發布計劃。
SDN網路的缺點與挑戰
SDN並非萬能靈藥，在設計和運行此類網路時，也存在一些必須考慮的挑戰。其中最常被提及的挑戰之一是控制器的潛在脆弱性：由於控制器集中了大量的邏輯和決策功能，它成為了一個關鍵節點，其故障或被攻破都可能導致整個系統崩潰。
這就需要部署高可用性、冗餘和故障轉移機制，以及非常嚴格的存取控制。例如，必須具備足夠的容量來緩解針對控制器的拒絕服務 (DDoS) 攻擊，以防止網路對關鍵事件「視而不見」。
另一個挑戰是，隨著設備和資料流數量的增長，延遲和複雜性可能會增加。如果控制器需要處理過多的資料平面交互，則可能會過載。一個設計良好的SDN架構應該分散式處理功能，在適當的時候（例如，為了快速從本地故障中恢復）對分散式元素保持一定的控制，並且能夠橫向擴展控制器。
在安全性方面，雖然SDN提供了更佳的可見性，但它也缺乏一些先前整合在傳統路由器、交換器或實體防火牆中的機制。保護控制器、應用程式和設備之間的通信，確保通訊的真實性和完整性，並設計一個強大的策略環境來驗證策略是否按預期執行，這一點至關重要。
此外，建立網路取證流程至關重要：包括詳細的事件日誌記錄、變更追蹤以及在事件發生時重現事件經過的能力。所有這些都必須與軟體定義網路（SDN）固有的動態性相容，既要防止安全性成為瓶頸，也要確保不存在任何漏洞。
ONF 和其他參與者在 SDN 生態系統中的角色
開放網路基金會（ONF）在軟體定義網路（SDN）的發展演進中發揮基礎性作用。它是一個由最終用戶（營運商、大型企業）驅動的組織，旨在透過開放標準和協作流程來促進軟體定義網路的普及應用。
ONF 一直負責定義、維護和發展 OpenFlow 標準，這是第一個被認可的 SDN 標準，至今仍是許多架構的核心要素。但 ONF 的工作遠不止於此：它領導多個工作小組，分析商業部署的需求，提出新的介面、資料模型和術語，並促進多廠商生態系統的發展。
同時，科技公司和設備製造商也開發了自己的SDN平台和混合方案。其中一些方案，例如基於邏輯集中式控制器的解決方案（如Ciena的Blue Planet），將集中式功能（端對端可見性、策略、頻寬）與跨網路元素的分散式功能相結合，用於故障恢復、本地監控或安全防護。
這種混合方法反映了一種實際情況：並非所有控制都必須放在中央控制器上，某些快速反應機制可以方便地靠近交通，而更複雜的智能和協調則以集中式和可編程的方式進行管理。
SDN、網路虛擬化與實際應用案例
在許多組織中，軟體定義網路 (SDN) 與網路虛擬化技術結合使用，在現有實體基礎架構之上建構疊加網路。這些虛擬網路可以利用相同的底層硬體來劃分不同的環境（生產環境、開發環境、不同客戶環境），或者可以將多個實體網路互連，就像它們是同一個邏輯實體一樣。
當與SaaS、IaaS 和 PaaS 等雲端運算服務整合時，這種方法尤其強大。軟體定義網路與編排平台協調運作，從而能夠以一致、快速和自動化的方式執行整個配置週期——包括虛擬機器、儲存、網路和安全，通常透過 API 實現。
在大型企業和營運商中，SDN 用於建立更智慧的企業廣域網路 (WAN)，從而對總部、資料中心和公有雲之間的流量進行精細化管理。例如，Google多年來一直使用 SDN 來互連其全球資料中心，並與 ONF 合作定義了除 OpenFlow 之外的新型控制介面。
在資料中心環境中，SDN 是實現快速高效擴展的關鍵元件：它能讓新的資料中心在數小時內投入運營，並在數分鐘內完成網路資源的配置。此外，它還能簡化大規模物聯網環境的部署，輕鬆管理數千個分散式設備和感測器，而無需面對過於複雜的系統。
最後，SDN 是軟體定義基礎設施這一更廣泛趨勢的一部分，在這種趨勢下，不僅是網絡，儲存（SDS）和其他資源也由邏輯控制平面進行控制，而無需依賴特定的硬體。這賦予了企業更高的可移植性、敏捷性，以及根據需要將工作負載在雲端和本地遷移的能力。
憑藉這些歷史、技術和實踐背景，SDN 正在鞏固自身作為一種不同的網路理解方式的地位：它更接近軟體世界，專注於自動化和可編程性，並且能夠應對流量增長、雲端運算、大數據和物聯網的挑戰，而無需無限增加硬體或營運複雜性。
