本是同根生　OpenFlow為何不及SDN

SDN和OpenFlow是兩件事。SDN軟體定義網路具備靈活的集中控制和雲化的應用感知能力，是下一代IP網路管理架構設計思路；而Openflow因管理細緻度不完整和架構缺乏網管網設計。

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上將提高自身廣域網路100%利用率的功勞歸於SDN，而對OpenFlow謹慎地使用了Infancy、Improvise等詞來形容。

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

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