電子發燒友App
軟件定義網絡（Software-defined networking，SDN），一種新的網絡架構。SDN 提出的控制與轉發平面分離、網絡狀態集中控制、支持軟件編程等理念并不是什么新鮮事，但是長久以來一直沒有非常突破性的進展。
目前 SDN 引起廣泛關注得益于網絡需求側翻天覆地的變化：云計算業務（服務器虛擬化技術為代表）成為主流，移動互聯網催生的大數據技術日益普及，包括網絡在內的資源快速配置、彈性擴容、按需調用需求強烈。傳統模式的弊端顯現：網絡設備硬件、操作系統和網絡應用三部分緊耦合在一起，組成一個封閉系統，這三部分相互依賴、每一部分的創新和演進都要求其余部分做出同樣的升級。
越來越多的網絡新協議和新算法使得網絡控制平面變得越來越復雜，但是現在的網絡用戶卻對網絡的易用性有更高的要求，希望網絡具有更多的可編程能力，從而自動化、智能化網絡管理。正如 SDN 的倡導者 Scott Shenker,U.C. Berkeley Professor 所言，網絡發展目前還處于“管理復雜性”階段，這樣的架構嚴重阻礙了網絡創新進程的開展。
SDN Solutions
如何解決從“管理復雜性”階段轉變到“提取簡單性”階段呢？最先取得成功商用經驗的是互聯網企業Google。
Google 的 SDN 實踐
Google 基于 SDN 技術改造其骨干網 G-scale（Backbone Network，也稱WAN網）。WAN網的主要任務是負責全球12個數據中心之間的互聯，數據流量的內容包括：1. 用戶數據備份，例如視頻、圖片、語音等；2. 跨數據中心存儲訪問，例如計算資源和存儲資源分布不同；3. 大規模的數據同步。WAN 網成本高昂（包括很多海底光纜），而且存在數據流量大但是鏈路帶寬利用率低的問題：為了實現負載均衡，同時避免大流量都被分發到同一個鏈路上導致丟包，Google不得不使用過量鏈路，提供比實際需要多得多的帶寬，實際鏈路帶寬利用率只有30%~40%，而且仍不可避免有的鏈路很空閑，有的鏈路產生擁塞，設備必須支持很大的包緩存，成本高。
為了增強網絡的可管理性，Google 首先在帶寬分配和路徑計算方面嘗試。解決思路是當一個新的數據要開始傳輸時，應用程序會評估所需要耗用的帶寬，為它選擇一條最優路徑（如負載最輕但非最短路徑，雖不丟包但延時大），然后把這個應用對應的策略通過控制器（Controller）下發到定制的交換機中，跟選擇的路徑綁定在一起，從而整體上使鏈路帶寬利用率達到最優。
SDN 架構中最顯著的一個特點就是采用集中式控制器（Controller）：
SDN 世界的兩大山頭
SDN 技術體系目前還處于激烈競爭階段，相關新產品和新技術層出不窮，如果要梳理大致可以分為兩個流派：
ONF(Open Networking Foundation，開放網絡基金會 )
董事會成員：德國電信（DT）、Facebook、 Google, Microsoft、Verizon、Yahoo!、日本 NTT 電信、高盛公司
特點：面向用戶
傳統巨頭大聯盟（通過Linux基金會(Linux Foundation)合作）
成員：思科（Cisco）、IBM、 微軟、Big Switch、博科、思杰、戴爾、愛立信、富士通、英特爾、瞻博網絡、微軟、NEC、惠普、紅帽和VMware
協作項目：OpenDaylight（20130408）
特點：大廠控制“嫌疑”
SDN 標準化組織
IETF（Internet Engineering Task Force，互聯網工程任務組）
相對 ONF 而言，更多是由網絡設備廠商主導，已經發布了多篇 RFC 文稿，內容涉及需求、框架、協議、轉發但愿模型及 MIB 等。
ETSI NFV(Network Functions Virtualisation)
成員：歐洲電信標準協會（European Telecommunications Standards Institute，ETSI）包括 AT&T, 英國電信（BT）, 德國電信等
特點：主要工作成果是 “網絡功能虛擬化白皮書”，對NFV的定義、應用場景、基本功能，以及SDN等技術的關系等內容進行描述。
ITU-T （國際電信聯盟通信標準化組織）
由 ITU-T 指定的國際標準通常被稱為建議（Recommendations）,2012年開始 SDN 與電信網絡結合的標準研究。
SDN Architecture
SDN在應用中大體上可以可以劃分為三層體系結構：
- 應用層（Application Layer）
- 控制層（Control Layer）
- 基礎設施層（Infrastructure Layer）
不同層次之間通過接口通訊：
- 北向接口（Northbound interface）
- 南向接口（Sorthbound interface）
控制層（ Control Layer ）
控制層是 SDN 控制器管理網絡的基礎設施，可以根據需要靈活選擇多種控制器。
在這一層中，控制器中包含大量業務邏輯，以獲取和維護不同類型的網絡信息、狀態詳細信息、拓撲細節、統計詳細信息等。
由于 SDN 控制器是用于管理網絡的，所以它必須具有用于現實世界網絡使用情況的控制邏輯，如交換、路由、二層VPN、三層VPN、防火墻安全規則、DNS、DHCP和集群，網絡供應商和開源社區需要在自己的 SDN 控制器中實現自己的服務。這些服務會向上層（應用層）公開自己的API（通常是基于 REST ，這使網絡管理員可以方便地使用應用程序上的 SDN 控制器的配置、管理和監控網絡。
目前市場上的 SDN 控制器解決方案大致可以分為兩類：大型網絡設備廠商提供商業方案，例如 Cisco Open SDN controller, Juniper Contrail, Brocade SDN controller, 和來自 NEC 公司的 PFC SDN controller ；社區組織提供的開源方案，例如 OpenDaylight, Floodlight, Beacon, Ryu 等等。
Commercial Solutions:
Cisco Open SDN Controller
Juniper Contrail
Brocade SDN controller
PFC SDN controller(From NEC)
Open Source Solutions:
Beacon：由斯坦福大學開發，Java語言編寫
Floodlight：源于Beacon，Big Switch Networks開發，Java語言編寫，Apache許可證
OpenDaylight：
Ryu：由 NTT 開發，Python 編寫，能夠與 OpenStack 平臺整合，控制器API豐富
Mul: 由 Kulcloud 開發，內核采用 C 語言實現的多線程架構
NodeFlow: 由 Cisco 開發，基于 Node.js 的 OpenFlow 控制器，JavaScript 編寫
Trema: 由 NEC 開發，Ruby/C 編寫
NOX: 由 Nicira 開發，C++/Python編寫，業界第一款 OpenFlow 控制器
POX: 由 Nicira 開發，是 NOX 的純 Python 實現版本，目的是提供跨平臺部署的便利性
基礎設施層（ Infrastructure Layer ）
基礎設施層，由各種網絡設備構成。它可以是數據中心的一組網絡交換機和路由器。控制層負責管理底層物理網絡，物理層的實現可以是支持 OpenFlow 的硬件交換機，隨著虛擬化技術的完善，SDN 交換機可以是軟件形態，例如 Open vSwitch (OVS) 就是一款基于開源技術實現的、能夠與服務器虛擬化（Hypervisor）集成，具備交換機的功能，可以實現虛擬化組網。另外，OVS 支持傳統的標準管理接口，例如 NetFlow 、sFlow 等，監測虛擬環境中的流量情況，詳見 《淺談基于數據分析的網絡態勢感知》 。
應用層（ Application Layer ）
應用層對于開發者來說是開放區域，鼓勵開發盡可能多的創新應用。包括網絡的可視化：拓撲結構、網絡狀態、網絡統計等；網絡自動化相關應用：網絡配置管理，網絡監控，網絡故障排除，網絡安全策略等。SDN 應用程序可以為企業和數據中心網絡提供各種端到端的解決方案。
例如，Brocade 應用實例：
- Brocade Flow Optimizer
- Brocade Virtual router
- Brocade Network advisor
HPE 應用實例：
- HPE Network Optimizer
- HPE Network protector
- HPE Network visualizer
- NEC UNC for HP SDN VAN Controller
- Aricent SDN Load balancer
- TechM smart flow steering
- TechM server load balancer
南向接口（ Southbound interface ）
控制層到基礎設施層（網絡交換機）通訊需要經過南向接口，目前主要的協議是 OpenFlow , NetConf，OVSDB 。 OpenFlow 協議是事實上的國際行業標準，NOX 、Onix 、Floodlight 等都是基于 OpenFlow 控制協議的開源控制器。作為一個開放的協議，OpenFlow 突破了傳統網絡設備廠商各自為政形成的設備能力接口壁壘。
北向接口（ Northbound interface ）
北向接口：應用層 通過 API 的方式 與 SDN 控制器通訊。與南向接口不同，現在北向接口還缺少業界公認的標準，實現方案思路有的從用戶角度出發、有的從運營商角度出發、有的從產品能力角度出發。技術風格上，部分傳統的網絡設備廠商傾向于在現有的設備上提供編程接口供業務App調用，許多上層應用的開發者也比較傾向于采用 REST API 接口的形式。
審核編輯：郭婷
工商網監
評論