你知道 OpenFlow 為何不及 SDN 嗎？

今天愚人節，祝大家愚人節不被愚：）首先第一篇文章想先說說 SDN 和 OpenFlow。SDN 全名是軟件定義網路，它具備靈活的集中控制和雲應用感知能力，是下一代 IP 網路管理架構設計思路。SDN 是下一代 IP 網路管理架構設計的代表，這種思路強調拆分控制層面與應用數據層面，用集中管理取代分散配置。OpenFlow 則在實現這種思路時，用網路集中管理平台的 Flow Table 或 NIB(Network Information Base) 並取代網路設備路由表 Routing Information Base 的協議。學術界當初因 OpenFlow 提出了 SDN，基於可以理解的動機，這兩個概念被有意地模糊。但事實上，從理論上完善性和具體實踐看，這兩者有著很大的分別。

SDN 比 OpenFlow 可靠之處

我們先看網路的現狀：資訊如同資金，要有流動性才能發揮價值。於是，隨著 IT 的重要性提升，網路作為資訊流動的平台，其規模越來越大。伴隨著規模的擴張，使用者發現了兩個現象。一是，其建設成本和管理成本不但沒有按規模遞減，反而更貴了；二是，不同應用對網路的要求很不一樣，現有的 IP 網路根本無法實現針對性的管理。

第一個現象產生了集中控制的需求；第二個現象則是要求網路能夠實現應用感知。SDN 初始的架構設計，以及經 Google、Facebook 等公司的實踐改進，恰好能夠實現靈活的集中控制和雲應用感知。SDN 的靈活性在於提供集中控制的 NIB 表、將 NIB 打包成服務的 API，再將 API 網管策略邏輯化。建表目前主要還是 OpenFlow，打包 API 的包括 Onix，控制引擎包括 Ethane 和 Google 使用 FML(Flow-based Management Language)自建的安全平台等。這幾種技術和軟體配合，可完整實現以流動的方式管理流量。而 SDN 雲應用感知不僅在 NIB 表可以做到 4～7 層，更重要的是，可以在控制引擎中直接輸入應用狀態控制策略。例如，當應用在不同數據中心遷移時，其包括 IP 位址在內的網路屬性也可以跟著移動。

Openflow 缺憾仍然多

管理細緻度不完整是 OpenFlow 面臨的第一大問題，OpenFlow 形成流表的來源資料來源只是 TCAM (Ternary Content Addressable Memory)。而為實現管理目標，既有網路設備還有大量其他技術方式。例如，對 MAC 位址的過濾是通過埠 ASIC 晶片直接完成的；SNMP Community 管理是通過 CPU 實現；線速交換控制是通過 FPGA (Field Programmable Gate Array)實現。管理不完整還意味著不同管理機制間無法協調，這讓 Openflow 完全不可用。而基於 TCAM 所導致的另一問題是網路規模不可能太大。因為，畢竟廠商提供 TCAM 的初衷只是針對一台設備，而非整個網路。

第二個問題是架構缺陷，即缺乏網管網的設計。所謂網管網，就是網路管理平台為了完成與網路設備通訊本身需要而建設一管理網。這網管網，如何跟業務網(也就是跑其他應用的網路)分開，是外還是內？是靜態協定還是動態協定？OpenFlow 的架構中沒有設計。沒有網管網的架構設計，OpenFlow 各種上行和下行在具規模的部署場景下，一定會出現問題。集中控制本身就意味著把雞蛋放在一個籃子裡，如果無法保證籃子的可靠性，任何設計都是「不提也罷」！

因此，這就不難解釋互聯網界對這兩者的態度了。例如，Google 在 ONF 2012 上將提高本身 WAN 100% 使用率的功勞歸於 SDN，而對 OpenFlow 的貢獻便只使用了 Infancy、Improvise 等詞來形容。

而其他廠商如 Cisco 目前的官方態度是看好 SDN，但不表示看好 OpenFlow。SDN 是由學術界發起的，大勢已成，得到廠商們的支持，順勢而為還能省下大筆教育客戶的成本。而 OpenFlow 的管理不完整這一缺陷，廠商實際可以從根本上解決，就是直接修改網路作業系統，讓 Openflow 的管理資料來源從 TCAM 延伸到 ASIC、CPU、FPGA。甚至廠商可以將原作業系統 API 化，讓集中控制引擎直接引用作業系統，實現更精細的控制。

互聯網技術發展到今日，很需要一些新突破，SDN 必然是這改革者的重要武器。