SDN和OpenFlow是兩件事。SDN(Software Defined Network,軟件定義網絡)具備靈活的集中控制和云化的應用感知能力,是靠譜的下一代IP網絡管理架構設計思路;而Openflow因管理顆粒度不完整和架構缺乏網管網設計,算得上是一種不靠譜的協議。
SDN是下一代IP網絡管理架構設計的代表,這種思路強調拆分控制層面與轉發層面,用“流交換”替換“包轉換”,用“集中管理”取代單獨配置。OpenFlow則是實現這種思路時,用網絡集中管理平臺的流表(Flow Table,更通用的詞是NIB,即Network Information Base)取代網絡設備路由表(RIB,Routing Information Base)的協議。
學術界當初因OpenFlow提出了SDN,基于可以理解的動機,這兩個概念被有意地模糊。但事實上,從理論體系的完善性和具體實踐看,這兩者有著巨大的區別。
為什么說SDN靠譜呢?
我們先看網絡的現狀。信息如同資金,要有流動性才能發揮價值。于是,隨著IT的重要性提升和體量增長,網絡作為信息流動的平臺,其規模越來越大。伴隨著規模的擴張,用戶發現了兩個現象。一是,其平均端口建設成本和管理成本不但沒有按規模遞減,反而更貴了;二是,不同應用對網絡的要求很不一樣,既有IP網絡根本無法實現針對性的管理。
第一個現象產生了集中控制的需求;第二個現象則是要求網絡能夠實現應用感知。SDN初始的架構設計,以及經谷歌、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各種上行和下行管理報文在規?;渴鸬膱鼍跋拢欢〞霈F問題。集中控制本身就意味把雞蛋放在一個籃子里。如果無法保證籃子的可靠性,任何設計都是“對策比問題更糟糕”。
因此,這就不難解釋互聯網界對這兩者的態度了。比如,谷歌在ONF 2012(Open Networking Foundation,開放網絡基金會)上,熱情洋溢地將提高自身廣域網100%利用率的功勞歸于SDN,而對OpenFlow謹慎地使用了“Infancy”(嬰兒期)的詞匯。同時,谷歌還在公開場合將OpenFlow形容為“Improvise”(湊合)。
相比谷歌這樣的互聯網大佬,廠商界則有更強勁的理由追捧SDN和抨擊Openflow。比如,思科目前的官方態度是“看好SDN,但不表示看好OpenFlow”。SDN是由學術界發起的,大勢已成,廠商們只能跟牌;同時,順勢而為還能省下大筆教育客戶的成本。而前文分析到OpenFlow的管理顆粒度不完整這一缺陷,廠商實際可以從根本上解決。解決方法也很簡單,就是直接修改網絡操作系統,讓Openflow的管理數據來源從TCAM延伸到ASIC、CPU、FPGA。甚至于說,廠商可以將原操作系統 API化,讓集中控制引擎直接調用操作系統,實現更為精細的控制。
近十幾年來,除端口速率、每端口成本、每設備端口密度等偏向制造能力驅動的創新外,IP網絡業已沉靜太久,而SDN是最佳攪局者。這次,會真的不同。