何曉明,冀 暉,毛東峰,唐 宏
(1.中國電信股份有限公司廣東研究院 廣州510630;2.中國電信集團公司 北京100032)
電信IP網絡從最初僅能滿足互聯網應用的“盡力而為”網絡發展到今天能夠提供具有服務質量保證的語音、視頻、文本等多媒體業務的融合承載網,IP網絡的功能和性能發生了巨大的變化。支撐IP網絡飛速發展的TCP/IP技術體系也在不斷地 “做加法”,變得日趨龐大和復雜,IETF組織正式發布的RFC文檔目前已超過7 000個。然而,這種基于分布式路由計算的網絡架構并未發生本質的變化。今天的IP網絡就像得了肥胖癥,并伴生出多種難以治愈的并發癥,如網絡設備更具多樣性和復雜性,由此導致的網絡運維將不堪重負;網絡不能適應快速變化的業務和應用需求等。下面從這些方面分別進行闡述。
最初的IP組網設備僅有交換機和路由器兩種設備形態,設備廠商也較為單一,基本上維持Cisco設備一統天下的局面。隨著IP技術發展以及市場競爭的加劇,越來越多的公司加入網絡設備研發隊列;與此同時,電信運營商也需要更多地考慮建設網絡基礎設施的經濟性和網絡運營的安全性,多廠商設備組網已成為各大運營商共識。另一方面,豐富多彩的網絡應用也催生出更多的設備形態和種類,像以太網交換機、路由器、網關設備、寬帶接入服務器、防火墻、網絡地址轉換(NAT)設備、負載均衡設備這些標準化程度較高的設備都已廣泛部署在各大運營商網絡。這些為滿足不同功能、運行多種不同協議的設備組成的異構網絡需要通過TCP/IP互聯起來,共同構筑今天通達全球的信息高速公路。
過去30多年來,IP技術在不斷滿足人類信息需求的過程中取得了巨大的成功,這種成功建立在對TCP/IP技術體系不斷豐富完善的基礎之上。層出不窮的網絡應用對IP網絡的傳輸容量、可靠性和擴展性、安全性提出了新的要求。每當一個新的功能和性能需求提出時,需要有一種新的網絡協議與之相適應。比如說,設備需要支持區分服務(DiffServ)或綜合服務(IntServ)協議以支撐網絡的差異化的QoS服務;設備需要支持PIM(protocol independent multicast,協議無關多播)協議以提供網絡多播服務;設備需要支持標簽分發協議(LDP)和多協議邊界網關協議(M-iBGP),才能提供二、三層MPLS/VPN服務。每一次設備功能和性能的增強都是以設備復雜度的增加作為代價,網絡設備就在人們對網絡應用需求永無止境的追求中積累著難以承受的復雜度。這種IP網絡和設備的復雜性根源于傳統分布式路由計算的網絡架構,只要傳統IP網絡架構不發生革命性的變化,IP網絡和設備的復雜性就將會與日俱增。
電信IP網絡的多廠商、多設備形態、多版本的設備組網特點帶給網絡運維的復雜性不言而喻。不同設備形態、不同廠商、不同軟硬件版本的設備存在功能和性能差異,配置命令也互不相同,網絡運維人員需要耗費大量時間和精力熟悉多種設備的技術特點和配置命令。在實際網絡運維中,運維部門通常按照設備廠商、設備形態或版本型號配置相應的技術人員,通過對管理界面適度分工的方式來緩解運維壓力。這種分工協作的運維管理模式也滋生出一種副作用,那就是負責不同廠商設備的專業技術人員難以就設備互聯互通問題進行有效的溝通,導致業務開通及網絡排障的時效性差,飽受用戶和客戶詬病。
與此同時,IP技術發展日新月異,設備需要同時運行多種信令協議來支持不同的網絡應用,網絡技術人員需要不斷熟悉和掌握IP新技術,這也對網絡運維人員的專業技能提出了更高要求。今天網絡的配置工作正變得日益繁重,通常需要在大型運營商網絡設備上手工完成上千行配置命令,這對技術人員來說,是一件望而生畏的工作。隨著移動互聯網、云計算的廣泛應用,網絡更趨向于動態化,相比于過去的靜態網絡,今天網絡中的參數和配置命令更需要進行動態配置和修改,比如說,網絡中增加、刪除或移動某臺設備時,運維人員需要使用設備級的管理工具調整相關聯設備如交換機、路由器、防火墻、AAA認證系統的網絡參數,更新相關設備的訪問控制列表(ACL)、VLAN、QoS等配置命令。服務器虛擬化極大地增加了網絡互聯的主機數目,虛擬機(VM)遷移對傳統網絡的諸多方面提出了挑戰,從尋址方案、命名空間到網絡分段和路由設計等,都對網絡的動態配置提出了很高的要求。由于應用需求的動態變化、主機位置的移動、設備的添加和刪除隨時都可能發生,網絡配置也需要適應這種動態變化的環境。傳統網絡基于設備級的手工配置方法不能適應當前動態變化的網絡環境,網絡配置的自動化更能適應快速變化的業務和應用需求,并能從根本上把網絡技術人員從繁重的運維工作中解脫出來。
移動設備、存儲和服務器虛擬化的爆發以及云服務的興起迫使網絡工業重新審視傳統IP網絡架構。傳統靜態的IP網絡架構能較好地適應以客戶機/服務器模式為主的網絡應用,然而,這種靜態架構不能很好地適配今天云數據中心對動態計算和存儲的需要。下面幾個關鍵因素正驅動著傳統網絡架構的變革。
(1)流量模型的變化
今天的云數據中心,其流量模型正在發生重大變化。對比過去占統治地位的客戶機/服務器應用,數據中心流量流向主要以南北向為主。在云計算環境下,用戶對前端服務器訪問請求,會引起大量后端服務器的分布式計算,這種后端服務器群組的協同計算產生巨大突發的東西向流量。同時,以社交網絡和即時通信為代表的移動互聯網應用的爆發正在改變著互聯網的流量模型,永遠在線的移動終端無時無刻不在制造并向網絡注入海量內容,改變了過去互聯網上下行流量嚴重不對稱現象。再者,許多企業數據中心的管理者正在考慮把傳統的企業數據中心轉變成私有云、公有云或混合云,這將產生更多的跨越廣域網的流量。
(2)云服務的興起
企業開始關注并對公有云和私有云服務產生興趣,導致云服務的迅速增長。企業希望以更加靈活的方式按需獲取互聯網應用、基礎設施和IT資源。這對網絡的安全隔離性、策略一致性、審計等方面提出了更高要求。網絡在為計算、存儲和網絡資源提供更多彈性和可擴展性的同時,還需部署自服務平臺,方便用戶隨時獲取所需資源。
(3)大數據對網絡帶寬的彈性要求
大數據正成為互聯網企業追逐的下一座金礦。大數據處理需要成百上千臺相互連接的服務器并行計算,如百度和Google搜索引擎就是一種典型的大數據應用。根據權威機構預測,隨著大數據應用范圍的擴展,計算節點之間交換的數據流量將達到PB量級。大數據時代要求網絡帶寬具有極大彈性和伸縮性,能夠動態提供從數十吉比特每秒到太比特每秒級的網絡帶寬,以滿足成千上萬臺服務器之間的高容量、低時延的網絡連接。
(4)網絡虛擬化要求
當前電信運營商網絡部署了大量種類各異的專用硬件設備,這些專用硬件設施是在不同時期為滿足特定業務而購置的。這些設備生命周期短,運營維護成本高,為特定業務專門定制和獨享,利用效率低。隨著新業務層出不窮的涌現,需要部署更多新的專用硬件,不僅開發周期長,影響業務的快速部署,不利于網絡和應用創新,而且大大增加了電信運營商的資本支出。電信運營商迫切需要尋求一種通用的網絡基礎實施,支撐未來不斷變化的業務和應用需求。計算和存儲的虛擬化技術的大量商用部署為網絡功能虛擬化打開了一扇門。網絡虛擬化的目標是通過借助IT虛擬化技術把網絡基礎設施轉變成工業標準的大容量服務器、存儲設備和交換機,而使業務的部署不再受具體物理設備及位置的限制。
傳統網絡架構不能很好地適應今天的企業、電信運營商及用戶的需求。由開放網絡基金組織(ONF)發起的軟件定義網絡(SDN)正在變革傳統網絡架構。根據ONF對SDN的定義,在SDN架構中,控制平面和數據平面解耦,網絡智能和狀態邏輯集中,底層網絡基礎設施抽象于應用。企業和電信運營商能夠實現對網絡的自動化、編程和控制,網絡變得更加具有擴展性、靈活性,更能適應不斷變化的業務和應用的需求。

ONF提出的SDN架構如圖1所示。SDN架構分為3層,最上層為應用層,包括了各種不同的業務和網絡應用。應用層根據網絡不同的應用需求,調用與控制層相接的應用編程接口(API),實現不同功能的應用程序。利用API,業務應用可以充分利用網絡的服務和能力,并在一個抽象的網絡上進行操作,實現通常的網絡服務,包括路由、多播、安全、訪問控制、帶寬管理、流量工程、服務質量、計算和存儲優化、能源管理、各種形式的策略管理以及客戶定制化服務等。
SDN的控制層由控制軟件實現,主要負責集中收集和維護網絡拓撲及網絡狀態信息,實現不同業務特性的適配。利用控制/數據平面接口,控制層獲取底層網絡設備互聯及狀態信息,生成全局的網絡拓撲視圖,對底層網絡設備的資源進行抽象,并通過API提供給上層應用。因此,對于上層應用程序來說,網絡呈現為一個單一的邏輯開關。通過這種軟件模式,網絡管理人員可以靈活配置、管理和優化網絡資源,實現了網絡的可編程及靈活控制。
SDN基礎設施層由網絡的底層轉發設備構成,通過對底層設備及網絡資源進行抽象,并通過開放標準的接口為控制層提供服務。底層設備只需關注數據的轉發性能,無需運行網絡相關及應用相關的各種復雜信令協議,通過接受控制器的指令,實現數據分組的轉發、丟棄或修改等操作。SDN極大簡化了網絡設備復雜性。
從SDN架構可以總結出SDN應具有的四大基本特征。
·控制平面與數據平面完全分離。打破了傳統網絡設備垂直一體化設計架構,大大簡化了底層轉發設備復雜度。
·集中控制。由集中控制器實現全網拓撲的自動發現和路由計算,優化網絡資源利用,實現全網流量工程。
·開放接口。通過開放南、北向接口,實現應用和網絡的無縫集成,加快業務部署周期,提升用戶體驗。
·網絡可編程。通過開放API,上層應用與底層網絡良性互動,實現網絡服務的可定制化和可編程能力。
在SDN架構下,通過集中式的網絡配置和管理,大大簡化了傳統網絡設備配置的工作量。由于底層硬件采用工業標準化的通用轉發設備,有利于實現網絡功能虛擬化;新業務部署減少了對不同廠商設備的依賴程度,加速了網絡和應用創新。同時,SDN實現了網絡智能和狀態邏輯集中,網絡管理人員可以通過一套動態、自動化的應用程序實現對網絡的靈活配置、管理、安全加固、資源優化等。
SDN改變了傳統網絡架構,也改變了傳統網絡的運維管理模式和業務部署方式,為企業和用戶提供更好業務體驗的同時,期望能減少電信運營商的資本支出和運營支出。然而,SDN當前仍面臨許多挑戰。本文對SDN滿足電信級要求的網絡性能、網絡擴展性、網絡生存性3個方面進行了探討和分析,并結合電信運營商網絡現實需求,探索SDN在電信網的應用與實踐。
在移動互聯、云計算、大數據爆發的今天,網絡流量呈爆炸式增長。全球電信運營商都倍感網絡擴容壓力,目前中國電信集團ChinaNet骨干網流量已超過40 Tbit/s,若流量按照40%的年增長速度計算,網絡容量每隔兩年增長一倍。單槽位100 Gbit/s平臺路由器剛進入大規模商用期,許多大電信運營商已開始考慮在骨干網部署400 Gbit/s平臺的核心路由器。SDN的底層數據轉發平面可能使用完全不同于傳統網絡設備的硬件架構,因此,SDN首先面臨的一個基本挑戰是怎樣應對洶涌而來的數字洪流。這里有兩個方面的因素需要考慮:網絡性能與可編程/靈活性。
本文中SDN網絡性能主要考察網絡設備的吞吐量和時延兩個指標。網絡的可編程意味著網絡設備接受控制器下發的一系列指令,進而改變數據流的轉發行為。靈活性是指網絡對新業務和應用的適應能力。通常來講,網絡性能與可編程/靈活性是一對矛盾,網絡的高性能需要犧牲網絡的靈活性作為代價。怎樣在網絡性能與可編程/靈活性之間取得平衡是SDN需要解決的問題。

圖2給出了網絡處理的主要技術中性能與可編程性之間的關系。通用處理器(CPU/GPU)能夠提供極高的靈活性,高級編程語言和設計工具可對底層硬件進行高度抽象,快速開發復雜的數據分組處理功能。受通用架構約束,CPU的處理性能低,電能消耗大。類似Intel的Xeon系列多核處理器能夠達到幾十吉比特每秒的報文處理吞吐量。網絡處理器(NPU/NFP)的架構專為處理數據流而優化,專用硬件加速器及各種接口技術的使用可減少處理器能耗。由于需要定義數據分組/流的處理功能,其靈活性不如通用處理器。網絡處理器可達到100 Gbit/s的線速處理能力。可編程邏輯設備(PLD)或現場可編程門陣列(FPGA)專為特定的網絡功能而設計,具有高度并行處理數據分組/流的能力,當前的PLD技術可以達到200 Gbit/s的線速處理能力。專用標準產品(ASSP)是高性能網絡的里程碑,缺點是其靈活性不夠。ASSP主要應用于物理層和鏈路層設備、交換機及無線產品。最近,Intel、Broadcom以及Marvell公司開始使用基于SDN的ASSP來設計高性能以太網交換機,它們設計的OpenFlow交換機聲稱可支持500 Gbit/s的交換能力。專用集成電路(ASIC)專為廠商定制生產,作為一種專有的解決方案,ASIC具有極高的性能、成本及能耗優勢,但其靈活性也極為有限。
SDN需要同時兼顧網絡性能和可編程/靈活性,容易想到一種軟件和硬件相結合的混合架構更能適合SDN基礎設施層。例如,基于PLD/ASSP與NPU/NFP和CPU/GPU相結合的混合架構構建的底層轉發平面既能提供網絡可編程的靈活性,又能支持數據流的高性能轉發。這種軟、硬件一體化的混合架構有助于實現網絡虛擬化目標——開發出工業標準化的通用轉發設備。
如果SDN數據轉發平面的性能問題可以通過混合式可編程架構得到解決,另一個引起廣泛關注的問題是SDN的擴展性。目前,對SDN的擴展性研究主要集中在SDN控制平面可擴展性。
制約SDN控制平面可擴展性的主要原因有以下幾點。
·流的細粒度處理需求使得控制器需要響應更多的流請求事件。雖然控制器可以通過主動決策機制提前將控制邏輯下發到數據轉發單元,減少數據平面和控制器之間的處理開銷,但控制邏輯的變化通常是動態的,尤其是當網絡拓撲改變或者存在移動節點時。在基于OpenFlow的SDN中,提前安裝流表項也將使大量流表空間無法釋放,浪費緩存資源,而實際上大部分流的持續時間是很短的。
·接入控制、負載均衡、資源遷移等新型應用需求逐漸增加到控制平面中,控制器需要對日趨復雜的管控功能進行有效整合,這進一步增加了控制平面的處理開銷。
·傳統分布式網絡中每臺設備都是獨立自治的,每臺設備通過運行路由協議獲取全局的網絡狀態信息并計算路由。而SDN控制平面需要維護全局的網絡狀態信息,為全網中的所有網絡設備計算數據轉發路徑,這使得控制平面的可擴展性不僅需要考慮處理性能的需求,而且要考慮網絡狀態的一致性。
·在網絡規模增大、數據平面轉發設備數量增多的環境下,單控制器設備可能難以滿足性能需求。
在基于OpenFlow的SDN中,每當交換機收到一個新的數據流時,由于交換機還未安裝流表項,首個分組需要上送控制器。在電信運營商的大規模網絡中,會導致數據面和控制面之間的控制通道帶寬需求大、依賴首個分組反應式的流表項建立時延大以及控制器需要頻繁響應交換機請求等擴展性問題。DIFANE方案結合了主動和被動兩種安裝流表的方式將數據流量保持在數據平面,從而減小控制器負載。通過在OpenFlow交換機中選出權威交換機,由每個權威交換機管理一定區域內的OpenFlow交換機。當普通交換機產生新的數據流時,它根據自身的分區規則直接和自己分區內的權威交換機進行通信,由于權威交換機已提前部署了權威規則,因而可以向普通交換機安裝緩存規則,同時,直接將請求數據轉發給目的地而無須再返回給源交換機,從而省去了流請求建立過程中首個分組經過控制器的往返時延,也減少了控制器需要實時處理的控制流。DevoFlow方案借助于ASIC的支持,在OpenFlow交換機上提前安裝帶有通配符的流表項,對于需要特殊處理的細粒度流才轉發到控制器,這樣能有效減少控制器的負載。針對單控制器無法從根本上解決處理性能瓶頸問題,Onix提出了一整套面向大規模網絡的分布式SDN部署方案,即通過多控制器對OpenFlow交換機進行分域管理,這應該是未來SDN面向大規模網絡部署可擴展性研究的主要發展方向。
電信運營商網絡由于承載著大量實時交互性業務,對網絡的生存性提出了很高的要求,如5個9的網絡可用性、多種方式的業務保護及網絡快速自愈能力。為了滿足電信級IP網絡的要求,IP網絡已形成一整套成熟完善的高可靠性和高可用性技術,包括路由快速收斂技術、MPLS TE/LSP FRR業務保護技術、MPLS OAM/Ethernet OAM/PWE3 OAM故障快速檢測技術,不間斷轉發(NSF)、不間斷路由(NSR)及平穩重啟(GR)等技術在設備控制引擎失效時仍能保持業務的連續性。
SDN對網絡的生存性要求也不能低于傳統的IP網絡。為了應對控制器的單點失效,OpenFlow2.0增加了多角色控制器功能,主控制器與多個從控制器保持狀態信息的同步,當主控制器失效時,從控制器能平滑接管主控制器的工作,不至于引起業務中斷。當存在多條等價或非等價路徑時,轉發設備的流表項也應提供多個輸出端口,并根據負載均衡算法把數據流轉發到不同的路徑上。SDN同樣需要支持IP網絡中類似于MPLS TE/LSP FRR的業務保護機制,為需要業務保護的數據流提供1條到多條備用路徑,從而在鏈路失效時立即轉用備用路徑,而不是把數據轉發給控制器。
下面分析SDN的故障恢復能力。如圖3所示,正常情況下,由于R1與R3之間的鏈路代價小于R1與R4之間的鏈路代價,數據轉發設備R1的數據流都會轉發到R3。當R1快速檢測到R1與R3之間的鏈路故障時(如通過BFD或以太網OAM),R1應立即上報控制器,控制器收到故障通告后,根據更新的全局網絡拓撲重新計算路由,并向受影響的數據轉發設備更新流轉發表。等到最新的流轉發表都安裝好后,來自R1的數據流才切換到R4。再看看IP網絡是怎樣實現路由收斂的。在傳統IP網絡中,鏈路故障通知最先向它的鄰居宣告,鄰居再向鄰居的鄰居宣告,網絡規模越大,最后一跳獲知鏈路故障的路由器所需時間越長,當全網所有路由器都獲知這一鏈路故障事件時,才會重新形成一致的網絡拓撲,然后每臺路由器各自獨立計算路由,向轉發平面下發FIB。顯然,SDN的故障信息傳播時延要小于傳統IP網絡,SDN的網絡收斂性能基本不受網絡規模的影響,而傳統網絡的收斂時間隨著網絡規模的增大而增大,這就是傳統基于分布式路由計算的IP網絡收斂時間難以實現傳輸網所要求的50 ms保護倒換的原因。而且,基于云計算架構的控制器計算能力理論上可以無限擴展,而傳統路由器的CPU計算能力是有限的。

SDN優良的網絡自愈能力還取決于連接控制平面和數據平面的控制信道的高可靠性。如果控制信道與數據平面共享網絡帶寬(帶內控制信道),由于數據平面不再運行路由協議,難以保證控制平面和數據平面的連通性,數據平面的故障可能無法上報到控制器,導致網絡無法自愈,業務中斷。因此,控制信道的高可靠性需要獨立的控制網絡來保證,這個帶外控制網絡本身應該具有快速自愈能力。
SDN目前主要應用于校園網和企業數據中心。在校園網中部署OpenFlow網絡,是OpenFlow設計之初應用較多的場所,它為學校的科研人員構建了一個可以部署網絡新協議和新算法的創新平臺,并實現了基本的網絡管理和安全控制功能。目前,已經有包括斯坦福大學在內的多所高校部署了OpenFlow網絡,并搭建了應用環境。隨著云計算在數據中心的廣泛應用,將SDN應用于數據中心網絡已經成為研究熱點。Google在其數據中心全面采用基于OpenFlow的SDN技術,大幅度地提高其數據中心之間的鏈路利用率,起到了很好的示范作用。由于電信運營商網絡是一個多業務融合承載網,真實網絡面臨的異構組網、跨域互聯、超大容量、高可靠性和高可用性等都可能成為制約SDN應用的因素。SDN在校園網和企業數據中心取得的研究成果和應用經驗不能一成不變地移植到電信網,需要進一步在電信網加以實踐和驗證。為加速SDN在電信網的全面部署,還需要充分考慮電信網的特殊需求,進一步研究SDN滿足電信網所應具備的功能和性能要求。下面從電信運營商的數據中心、IP RAN、IP骨干網需求3個方面探索SDN應用和部署。
(1)SDN在數據中心的應用
隨著數據中心服務器和存儲虛擬化技術的廣泛應用,傳統數據中心網絡必須實現網絡虛擬化的改造,以滿足虛擬機頻繁遷移對網絡大量動態配置的需要。在服務器上實現虛擬網卡和虛擬交換機已成為VMware、Xen、Oracle等主流服務器供應商的標準配置。為適應網絡虛擬化要求,提出了相關標準和草案如虛擬以太網橋(VEB)、虛擬以太網端口聚集器(VEPA)、虛擬擴展局域網(VXLAN)、通用路由封裝實現網絡虛擬化(NVGRE)等,并在部分廠商設備上得到相應支持。同時,虛擬化網絡環境下的動態路由、負載均衡和能量管理等方面也對數據中心網絡提出了新的要求。SDN基于軟件控制的可編程特點可以簡化網絡配置和管理的復雜性,是實現數據中心網絡虛擬化最適合的基礎平臺。
(2)SDN在IP RAN的應用
IP RAN廣泛應用于移動回傳網,用于承載2G/3G/LTE等移動業務,是一種新型傳輸網絡。IP RAN分為接入層、匯聚層和核心層。IP RAN全網采用IP/MPLS解決方案,接入 層涉及IGP、BGP、LDP、RSVP-TE、PW、L2/L3VPN、QoS等配置。一個IP RAN本地網的接入層往往有數千臺接入設備,網絡配置復雜、業務開通周期長。隨著網絡規模的擴大,現有IP RAN在網絡高可用性、網絡運維等方面面臨困境。隨著技術的發展,新的增值業務和應用不斷推出,IP RAN如何更好地適應業務網絡的發展和要求,快速響應業務的部署及對業務進行動態維護也是需要考慮的問題。通過把SDN技術應用于IP RAN,可探索和研究SDN快速響應業務和網絡運維這兩方面的能力需求。
(3)SDN在IP骨干網的應用
隨著互聯網流量的爆炸式增長,電信運營商IP骨干網面臨持續擴容的壓力。另一方面,IGP選路的唯一性原則導致網絡流量分布極度不均衡,一部分鏈路嚴重擁塞,而另一部分鏈路長期處于輕載狀態。無法通過IGP metric(度量)調整來達到全網負載均衡的目的。在存在路由反射器(RR)的環境下,RR遵循標準BGP選路原則,無法實現跨域多歸屬網絡的負載均衡。BGP虛擬下一跳技術雖然能夠彌補RR選路的不足,但是卻增加了網絡配置和運維的復雜度。SDN可基于全局流量觀,根據自定義策略(如最短路徑、鏈路負載、指定經由節點等)進行路徑選擇,實現全網流量工程。同時,城域網、數據中心、不同電信運營商網絡同骨干網跨域互聯對SDN的可擴展性提出了挑戰,多控制器方案在骨干網的應用和實踐能夠驗證SDN分布式部署方案的可行性,為進一步完善SDN架構、功能、相關接口和規范提供研究基礎。
移動互聯、存儲和服務器虛擬化的爆發以及大數據和云服務的興起對傳統IP網絡架構提出了新的要求,并加速了傳統網絡的變革。SDN提供了一種新的、動態的、業務驅動的網絡架構,適應不斷變化的業務和應用需求,契合當今時代創新求變的主旋律。SDN倡導的“集中控制、網絡可編程、開放接口”等理念引起了產、學、研各界的廣泛關注。目前,OpenFlow是實現SDN的主要技術和標準,其相關規范已經得到普遍承認。基于OpenFlow的SDN技術在解決當前存在的實際問題和開拓網絡新應用等方面取得了不少成果,在校園網、企業網及數據中心都有相應部署,部分主流廠商的設備也逐漸支持OpenFlow接口規范,但目前在電信運營商大規模網絡仍缺少商用案例。總之,SDN在控制軟件架構、接口標準、數據轉發性能、網絡擴展性和頑健性、網絡安全性、與傳統網絡設備的互操作性等諸多方面仍面臨巨大挑戰。盡管如此,SDN已為傳統網絡演進和變革指明了方向,相信在眾多設備廠商、標準化組織、研究機構的共同努力下,SDN將發展成為面向下一代IP網絡的標準架構。
1 ONF White Paper.Software-Defined Networking:the New Norm for Networks,April 13,2102
2 Raj Jain,Subharthi P.Network virtualization and software defined networking for cloud computing:a survey.IEEE Communications Magazine,2013,51(11)
3 Sezer S,Hayward S S,Chouhan P K,et al.Are we ready for SDN?Implementation challenges for software-defined networks.IEEE Communications Magazine,2013,51(7)
4 Yeganeh S H,Tootoonchian A,Ganjali Y,et al.On scalability of software-defined networking.IEEE Communications Magazine,2013,51(2)
5 Boucadair M,Jacquenet C.Software-Defined Networking:A Perspective from within a Service Provider.RFC 7149,March 2014
6 Haleplidis E,Denazis S,Salim J H,et al.SDN Layers and Architecture Terminology.IETF Draft(Work in Progress)
7 ONF.OpenFlow Switch Specification Version 1.3.4,March 27,2004
8 Yu M,Rexford J,Freedman M J,et al.Scalable flow-based networking with DIFANE.Proceedings of the ACM SIGCOMM 2010 Conference on Applications,Technologies,Architectures,and Protocols for Computer Communications,New Delhi,India,2010
9 Curtis A R,Mogul J C,Tourrilhes J,et al.DevoFlow:scaling flow management for high-performance networks.Proceedings of the ACM SIGCOMM 2011 Conference on Applications,Technologies,Architectures,and Protocols for Computer Communications,Toronto,ON,Canada,2011
10 Koponen T,Casado M,Gude N,et al.Onix:a distributed control platform for large-scale production networks.Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation,San Jose,CA,USA,2010