SDN架構與解析_第1頁
SDN架構與解析_第2頁
SDN架構與解析_第3頁
SDN架構與解析_第4頁
SDN架構與解析_第5頁
已閱讀5頁,還剩4頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、SDN架構與解析:深度開放與融合長期以來,網(wǎng)絡技術總是以被動方式進行演變,并且大量的技術革新都落地在網(wǎng)絡設備本身,如帶寬不斷提升,從千兆到萬兆、再到40G和100G;設備 體系架構變化,也是為了性能地不斷提升,從交換能力幾十Gbps提升到T級別以致100T級別;組網(wǎng)變化,網(wǎng)絡設備的N:1集群性質的虛擬化,在一定范圍 內和一定規(guī)模上優(yōu)化了網(wǎng)絡架構,簡化了網(wǎng)絡設計;大二層網(wǎng)絡技術,通過消除環(huán)路因素,支持了虛擬化條件下的虛機大范圍二層擴散性計算。新的技術商用,總會引起設備的升級換代,并且隨著流量的巨大變化,網(wǎng)絡的部署與變 更技術上越來越復雜,網(wǎng)絡在應對流量變化上很難有良好的預期性,在當前方式下,一旦

2、完成業(yè)務部署,通過網(wǎng)線連入網(wǎng)絡,流量吞吐對網(wǎng)絡的影響就難以控制、網(wǎng)絡的調整也就變得相當滯后。軟件定義網(wǎng)絡一一 SDN(Software Defined Network) 的出現(xiàn)和理念演進,開始改變網(wǎng)絡 被動性的現(xiàn)狀,使網(wǎng)絡具備較大靈活程度的“定義”能力 ;這種可定義性,是網(wǎng)絡主動“處 理”流量而不僅僅是 被動“承載”流量,并使得網(wǎng)絡與計算之間的關系不僅僅是“對接”, 而是“交互”。SDN的思想集中體現(xiàn)在控制面與實體數(shù)據(jù)轉發(fā)層面之間分離,這對網(wǎng)絡的工作方式產(chǎn)生了深遠的影響。高端用戶原本就不滿足于使用網(wǎng)絡預先設定好的功能,而是希望在自己的業(yè)務功能不斷豐富變化的過程中,能夠按照自身需求快速進行調整。

3、而在控制層面分離出來后,或者說控制層面可以開放出來,更能實現(xiàn)虛擬化的靈活性,使得用戶能夠進行程序編制,那么基于應用與流量變化的快速響應,便不需要完全依賴于設備供應商的長周期軟硬件升級來完成。SDN的思想是將更多的控制權交給網(wǎng)絡使用者,除了設計部署、配置變更,還可以進行 網(wǎng)絡軟件的重構,使得新的技術驗證可以先于商業(yè)化。這種網(wǎng)絡能夠以抽象化的方式解決網(wǎng)絡的復雜性問題,解除了用戶收支網(wǎng)絡功能和特性的緊約束,能夠在更高層面研究和滿足項業(yè)務需求。1、當前主流SDN的概念探討最經(jīng)典的SDN架構描述是來自 ONF(Open Network Foundation) 的SDN系架構圖(如圖 1所示)。圖1 SD

4、N體系架構圖1表達了 SDN的分層解耦合概念, 包括通用的基礎硬件層、硬件抽象層、網(wǎng)絡、 上層應用。其中基礎硬件與硬件抽象兩層組成物理網(wǎng)絡設備,也 就是SDNm構中的數(shù)據(jù)轉發(fā)層 面;網(wǎng)絡操作系統(tǒng)與上層應用組成了控制層面。數(shù)據(jù)轉發(fā)層面與控制層面之間以一種標準化 的交互協(xié)議來解耦合,此協(xié)議當前為OpenFlow。這種去耦合的架構,表明網(wǎng)絡操作系統(tǒng)及網(wǎng)絡應用(如控制協(xié)議等)不必運行在物理設備上,而可以運行在外部系統(tǒng)(如X86架構的服務器)內,從而實現(xiàn)網(wǎng)絡控制的靈活可編程性。除了解耦合控制層面與數(shù)據(jù)轉發(fā)層面,SDN引入了集中控制的概念(如圖2所示)。對于傳統(tǒng)的設備,因為不同的硬件、供應商私有的軟件,使

5、得網(wǎng)絡本身相對封閉,只能通過標準的互通協(xié)議與計算設備配合運行。網(wǎng)絡中所有設備的自身系統(tǒng)都是相對孤立和分散的, 網(wǎng)絡控制分布在所有設備中,網(wǎng)絡變更復雜、工作 量大,并且因為設備異構,管理上兼容 性很差,不同設備的功能與配置差異極大;同時網(wǎng)絡功能的修改或演進,會涉及到全網(wǎng)的升級與更新。而在 SDN的開放架構 下,一定范圍內的網(wǎng)絡(或稱SDN或),由集中統(tǒng)一的控制 邏輯單元來實施管理,由此解決了網(wǎng)絡中大量設備分散獨立運行管理的問題,使得網(wǎng)絡的設計、部署、 運維、管理在一個控制點完成,而底層網(wǎng)絡差異性也因為解耦合的架構得到了 消除。集中控制在網(wǎng)絡中引入了SDN別于傳統(tǒng)網(wǎng)絡架構的角色一一SDNContr

6、oller ,也就是運行SDN網(wǎng)絡操作系統(tǒng)并控制所有網(wǎng)絡節(jié)點的控制單元。SDN能夠提供網(wǎng)絡應用的接口,在此基礎上按照業(yè)務需求進行軟件設計與編程,并且是在 SDNController 上加載,從而使得全網(wǎng)迅速升級新的網(wǎng)絡功能,而不必再對每個網(wǎng)元節(jié)點進行獨立操作。圖2封閉式網(wǎng)絡與開放網(wǎng)絡分層解耦合架構中采用了OpenFlow的協(xié)議來分離網(wǎng)絡的控制與轉發(fā)層,圖 3是來自斯坦福的一張圖表明 OpenFlow的解耦模型。PMtrt * caiiflim1. ForwuiriJ pckrl !0 portf-s)X EjnufHuIvtr kA Fixwnl to ccrtlJcrilBir 里* S*n

7、4 3 rWE/pid z.MwfclyfMF q imJUpT feHLf Mt 砸 .T fr*F IpuEIlMjl fIR J Mf| MI-rnnAi whKb圖3 OpenFlow協(xié)議工作模式網(wǎng)絡設備(圖3中OpenFlowSwitch)由標準的網(wǎng)絡硬件和支持OpenFlow代理的軟件構成。OpenFlow定義的網(wǎng)絡硬件,不是傳統(tǒng)的交換模式,而是以一種流表的方式來進行數(shù)據(jù)的轉發(fā)處理,非常類似于當前交換機使用的TCAM寸數(shù)據(jù)流的分類與控制行為,每一個網(wǎng)絡中的流均由流表中的規(guī)則來控制處理,可以達到極精細的粒度。OpenFlow協(xié)議定義了一種通用的數(shù)據(jù)平面描述語言,設備上的OpenFlo

8、w代理軟件通過與 OpenFlow Controller 建立安全加密(如SSL通信機制)通信隧道來接受對設備的控制轉發(fā)指令。所有的流表指令均被定義成標準規(guī)范,通過Controller 與代理之間的加密協(xié)議可靠傳遞。 Controller上運行的各種網(wǎng)絡應用,均被轉換成OpenFlow “指令集”下發(fā),從而易于實現(xiàn)標準化的模式,這使得OpenFlow成為SDN構下的重要技術。OpenFlow以一種比較理想的形式定義了網(wǎng)絡設備的供應方式,但這種定義使得網(wǎng)絡不 是一個平滑升級和演進,而是一個顛覆性的更新,現(xiàn)有網(wǎng)絡不能通過OpenFlow來升級,而 是需要被完全替換。同時,OpenFlow設備是一種

9、流表轉發(fā),也需要新的體系架構來設計網(wǎng)絡芯片,雖然現(xiàn)有TCAM術 能支持OpenFlow的特性,但是功能不完備、 大TCAMl項設備 極其昂貴。因此,當前的 OpenFlow設備,基本是在傳統(tǒng)網(wǎng)絡基礎上支持OpenFlow協(xié)議,規(guī)格受限的初期產(chǎn)品。OpenFlow的設計思路體現(xiàn)了 SDN構,但是,這種思路只體現(xiàn)了集中控制的優(yōu)勢,對 于網(wǎng)絡的運維管理并沒有深入考慮,管理通信如何采用OpenFlow并與正常業(yè)務流的分離, 是否覆蓋替代還是與傳統(tǒng) SNMP/NETCONF管理方式,集中的 OpenFlow Controller 與分散 的OpenFlow網(wǎng)絡設備之間采取一種如何的管理方式更優(yōu), 還需要

10、OpenFlow本身的技術不斷 實踐來印證。OpenFlow在協(xié)議定義上還不完善,針對已有網(wǎng)絡特性的定義還在補充變化,內容變更會不斷持續(xù),并逐步形成不同的技術版本,這使得軟件和硬件在配套兼容上存在較大的問題,這也是OpenFlow作為SDN協(xié)議的在網(wǎng)絡應用覆蓋不全方面的嚴重不足。2、1H3c SDN、體架構與策略2.1 H3C SDN總體架構與策略H3c在基于全網(wǎng)端到端的總體網(wǎng)絡架構上,將會交付一個逐步發(fā)展豐富的SDN產(chǎn)品與解決方案集。(如圖4所示)H3c SDN當前提供三大方案集:基于 Controller/Agent的SDNr套網(wǎng)絡交付、基于 Open API的網(wǎng)絡平臺開放接口、基于OAA

11、的自定義網(wǎng)絡平臺。在這三大方案集成基礎上,構建一個標準化深度開放、用戶可融合的NPaaS(Network Platform as aService)網(wǎng)絡平臺即服務的 SDN系,既具備H3c已有的優(yōu)勢網(wǎng)絡技術方案,又能在各種層次融合與擴展用戶自制化網(wǎng)絡應用。2.2 基于Controller/Agent的SDN全套網(wǎng)絡交付在上述SDN基本體系架構定義的框架下, H3c提供與此一致的方案架構。如圖 5所示, H3C各在同一 SDN的架構下,除了支持標準化的 OpenFlow協(xié)議,并提供基于 H3c自身成熟 技術的自有協(xié)議 RIPCRIPC(Remote IPC)。/應用丁川史筱亞com回openst

12、ack云計算接口avntOF vSwitch里MlOF pSv/itchAPUPrMccolL Comwar6APttPr&dlComwareAPirSDKH3C ControllerQpenflowRemote IPCRouterSwilch圖 5 Controller/Agent 的 SDN網(wǎng)絡H3c將提供標準化的系列化 Controller 部件,能夠以OpenFlow協(xié)議進行OpenFlow設 備的集中控制,對上層提供靈活的開放接口,以滿足各種網(wǎng)絡應用的調用需求。在當前網(wǎng)絡產(chǎn)品逐步集成 OpenFlow特性,滿足初始 OpenFlow網(wǎng)絡部署需求,并逐步豐富OpenFlow的 產(chǎn)品組成

13、,如圖6左圖構建了整體 OpenFlow的SDN網(wǎng)絡。針對H3c優(yōu)勢技術IRF的進一步強化,基于 Controller/Agent 架構,以 H3CRIPCRIPC 的協(xié)議實現(xiàn)了 VCF的技術,如圖6右圖所示,使用多臺S5820V2組成的IRF結構體工作為網(wǎng) 絡的Controller 角色,下聯(lián)多臺 S5120HI。圖6 H3c SDN網(wǎng)絡的兩種實現(xiàn)圖8 VCC運行VCF采用SDN架構的N:1網(wǎng)絡虛擬化,不僅將多臺同一網(wǎng)絡層面的設備整合,也將另理各種操作均被虛擬化在層次的設備整合,整個網(wǎng)絡運行如同一臺大型框式設備,運行管 一臺大型設備內。 所有的控制、設備管理均在S5820V2的IRF組上,其

14、它的S5120HI運行為線卡模式。在這種 SDN構下,H3c的RIPC協(xié)議消除了 OpenFlow協(xié)議在效率與管理上的 不足,并有效繼承了 H3C Comware平臺的原有IRF優(yōu)勢。2.3 基于Open API的網(wǎng)絡平臺自H3c實現(xiàn)SDN最重要的網(wǎng)絡需求是可編程性,即用戶可以在自身業(yè)務變化的情況下,根據(jù)需要 行軟件開發(fā),這種需求的核心是網(wǎng)絡要有靈活開放的接口提供給用戶的編程實現(xiàn)。了多層化的Open API方案(如圖7所示)。OpenFlow基礎設備層面可以提供深度的SDK級標準化 VCCR絡(VCC: Virtual ComputingContainer虛擬計算容器),并提供高級XML的訪問

15、操作NETCON標準接口體系,也是設備層面提供的一種標準接口模式 ;設備控制層面(SDN Controller),作為網(wǎng)絡,標準化的接口依據(jù) 現(xiàn),對外可提供 VCC REST/SOAP NETCONF OpenFlow 等。Open API 與 H3c系統(tǒng)(Comware/iMC)內部集成(Integrated)API( 建差另的SDNm構,并在不同層次形成自有系統(tǒng)及對外開放與標準化, 程與應用變化性需求得以滿足。Controller的不同實如RIPC)相輔相成,構 使得不同用戶的可編圖7 H3c多層化的 Open API在Open API接口中,REST/SOA沈常規(guī)的高層協(xié)議編程接口,NE

16、TCON是網(wǎng)絡設備上新興的XML語言編程接口, OpenFlow是SDN的一種協(xié) 議,以上均是通用化的技術實現(xiàn),VCC則是H3c在長期網(wǎng)絡軟件技術積累過程中形成的一種更為底層的標準化實現(xiàn)。ComwareV程基于Linux內核實現(xiàn)的新一代云計算網(wǎng)絡操作系統(tǒng),當前的架構,基于類POSIX的Linux接口及擴展形成一套開放的SDK, H3c提供了含SDK勺接口描述、調用庫、編譯環(huán)境等完備的編程環(huán)境,使得用戶可以使用 C/C+以幾乎完全等同于 Linux系統(tǒng)下的環(huán) 境進行自 己的網(wǎng)絡應用程序軟件開發(fā),而ComwareV7m為用戶的軟件運行提供了一個完整的系統(tǒng)環(huán)境,如圖 8所示。Corn ware- V

17、7在VCC境中,用戶程序包可獨立加載到設備上運行,軟件可以不間斷業(yè)務升級。MAC?硬件表項Comware V7現(xiàn)有的特ComwareV7提供接口給用戶,軟件設計可以一定程度上訪問底層硬件,對、 進行操作,或者設備的配置變更及相應狀態(tài)監(jiān)控等,同時還可以利用 性來輔助實現(xiàn)用戶業(yè)務,從而實現(xiàn)用戶軟件定義網(wǎng)絡的真正需求。2.4 基于OAA的自定義網(wǎng)絡平臺早期,H3c提出了開放應用架構(Open Application Architecture)的網(wǎng)絡模型,即在H3c的網(wǎng)絡設備中提供具有計算能力的線卡,用戶可以在其上開發(fā)自己的特殊應用,并通過 H3c的OAM聯(lián)協(xié)議與網(wǎng)絡進行數(shù)據(jù)交互?;赟DN的架構思路

18、,H3c演繹了更靈活的用戶化網(wǎng)絡設計,實現(xiàn)的OAA新的業(yè)務模式,可以方便用戶靈活實現(xiàn)自定義的網(wǎng)絡功能。在OAA基礎上,提出了兩種開放式的接口模型,如圖9所示。圖9左圖,顯示了一種全松耦合的 OAA架構。針對用戶任意形態(tài)運行的網(wǎng)絡業(yè)務,可能是在上的計算業(yè)務(如流量監(jiān)控分析、 數(shù)據(jù)旁路挖掘),也可 能是專用的業(yè)務設備(如、IPS、 加密機、數(shù)據(jù)壓縮機),用戶設備可以支持標準的 OpenFlow協(xié)議,即可與H3c網(wǎng)絡進行通信, 在OpenFlow協(xié)議中傳輸業(yè)務指令,對需要處理的網(wǎng)絡流量進行鏡像、牽引、封裝、定向等 操作,將清晰定義的數(shù)據(jù)流以合適的方式導引到用戶的計算設備進行自定義處理。這種方案的本質是,借助 SDN的模型,將用戶的數(shù)據(jù)處理設備運行為SDN Controller 方式,而對特定業(yè)務流進行處理。圖9右圖,顯示了一種緊耦合的 OA躲構,其中分兩種模式:模式一,用戶自設計提供高性能計算單元子卡,H

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論