基于sdn的數據包控制策略的研究_第1頁
基于sdn的數據包控制策略的研究_第2頁
基于sdn的數據包控制策略的研究_第3頁
基于sdn的數據包控制策略的研究_第4頁
基于sdn的數據包控制策略的研究_第5頁
已閱讀5頁,還剩47頁未讀 繼續免費閱讀

下載本文檔

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

文檔簡介

南京工程學院畢業設計說明書(論文)作者:學號:院系:通信工程學院專業:通信工程(無線通信)題目:基于SDN的數據包控制策略的研究指導者:教授評閱者:2014年6月南京ThestrategyofDatapacketForwardbasedonSDNController

ADissertationSubmittedtoNanjingInstituteofTechnologyFortheAcademicDegreeofBachelorofScienceByYeJiSupervisedbyProfessorWeikangShenCollegeofCommunicationEngineeringNanjingInstituteofTechnologyJune2014摘要隨著互聯網的高速發展、業務的豐富多樣以及用戶的與日俱增,計算資源支撐不足、設備更新成本巨大成為互聯網企業無法回避的問題。軟件定義網絡(Software-DefinedNetworking,簡稱SDN)作為革命性的解決方案,提出了控制平面和數據平面解耦的思想,相較于傳統網絡的分布式架構有了質的飛躍。軟件定義網絡為解決傳統網絡難題提供了新的思路,學術界和工業界也紛紛提出了基于SDN的網絡新型應用。流量工程作為傳統網絡面對的難題,一直是網絡研究領域中的熱點問題。本課題在SDN流量工程的場景下,提出基于軟件定義網絡的流量調度系統。通過對流量進行深度解析以確定網絡的流量類型,進行鏈路信息統計以獲取全網鏈路狀態。在此基礎上針對確定的流量類型下發相應的的調度策略,以達到流量高效傳輸的目的,并提升帶寬利用率、優化網絡性能。搭建相應的實驗環境進行傳統網絡解決方案與本課題調度策略的對比測試,從多角度對該調度策略的效率進行分析。本文的流量調度系統作為流量工程在軟件定義網絡的一個嘗試,為后續流量工程解決方案的研究提供新的思路。關鍵詞:軟件定義網絡;SDN;流量工程;路由策略;計算機網絡 AbstractWiththefastlydevelopmentofInternet,businessvariety,andtheuser'sgrowing,computingresourcestosupporttheinsufficiency,thehugecostofequipmentupdatebecometheInternetenterprisethequestionwhichisunabletoavoid.Software-DefinedNetworkingasarevolutionarysolution,putsforwardthecontrolplaneanddataplanedecouplingthoughts,comparedwiththetraditionalnetworkdistributedarchitecturehaveaqualitativeleap.Softwaredefinednetworkoffersanewwaytosolvetheproblemsoftraditionalnetwork,academiaandindustryhavealsoproposedanewnetworkapplicationsbasedonSDN.Facingtheproblemoftrafficengineeringasatraditionalnetwork,hasbeenahotissueinthefieldofnetworkresearch.ThistopicinengineeringSDNflowscenarios,trafficdispatchingsystembasedonsoftwaredefinednetworkisputforward.Throughthestudyofthedepthofflowanalysistodeterminethetypeoftrafficnetwork,tolinkinformationstatisticsforentirenetworklinkstatus.Onthisbasistodeterminetheflowtypeissuedcorrespondingschedulingstrategy,inordertoachievethepurposeofflowefficienttransmission,andimprovethebandwidthutilization,optimizationofnetworkperformance.Structures,correspondingexperimentalenvironmentforthetraditionalnetworksolutionandthetaskschedulingstrategyofcontrasttest,frommultipleperspectivestoanalyzetheefficiencyoftheschedulingpolicy.Inthispaper,theflowschedulingsystemfortrafficengineeringinsoftwaredefinednetworkanattempt,forsubsequenttrafficengineeringsolutionresearchprovidesnewtrainofthought.Keywords:SoftwareDefineNetwork;SDN;TrafficEngineering;RoutingPolicy;ComputerNetwork.目錄第一章緒論 .3.6最優路徑選擇該模塊利用可行路徑計算和鏈路狀態統計模塊所提供的參數進行評測。按照鏈路長度、鏈路利用率的不同權重進行計算,將計算結果進行遞減排序,結果數值最大的即為最優流量傳輸路徑。由于針對不同類型的流量是不同的調度策略,本小節著重闡述帶有權重的最優路徑計算方案。不帶權重的最優路徑方案只需將以上方案去掉權重即可實現。1)路徑選擇參數最優路徑選擇的算法基于若干參數,包括路徑長度、鏈路帶寬、鏈路利用率等信息。下面將對這些參數進行詳細闡述:A.路徑長度該選路主要針對大象流,由于其數據量大且持續對到達目的主機的鏈路進行統計對比,在策略上將選擇最短的路徑進行傳輸。如圖4.9所示,如果H1要發送數據包到H2,根據選路算法將優先選擇將數據包通過S1直接轉發到S3最終到達H2,即H1-->S1-->S3-->h2,而不去選擇H1-->S1-->S2-->S3-->H2的路徑。圖4.9選路依據——路徑長度B.鏈路利用率該鏈路選擇的策略以到達目的主機的多條鏈路為基礎,策略先以其中一條鏈路為首選鏈路,所有數據轉發均經過該鏈路,當吞吐量到達閾值時再轉移其他鏈路,如此往復。如圖4.10為H1到H2之間的鏈路拓撲,H1到H2的首選鏈路為H1-->S1-->S3-->H2,即圖左部拓撲的綠色部分,并且狀態正常。當鏈路吞吐量到達設定閾值時,即鏈路不健康,圖中右側拓撲黃色表示到達閾值,選擇另外的鏈路(如圖中右側拓撲綠色所示)即H1-->S1-->S2-->S3-->H2,如此往復。這種方法可以保證鏈路負載的均衡,提高帶寬利用率。s圖4.10選路依據——鏈路利用率2)權重計算將路徑長度N的權重設為10,將鏈路狀況的權重設為鏈路利用率U的倒數,設該路徑鏈路數量為n,則最優路徑選擇系數W的計算公式(4-4)為: (4-4)3)閾值策略鏈路的狀態決定了大象流是否可以通過,所以需要設置一個閾值(默認為鏈路利用率達到80%)以保證大象流的順利通過。也就是說鏈路帶寬利用率的大小決定了該條鏈路是否在路徑備選范圍之內。下面根據閾值將情況做一個細分,并針對不同情況執行不同的策略。1.所有鏈路均未超過閾值將鏈路利用率和路徑長度分別作為權重進行計算以得到的最大值的路徑為最優路徑;2.部分鏈路超過閾值,部分未超過這時超過閾值的路徑有兩種情況:有路徑不經過超過閾值的鏈路(情況(1))和所有可行路徑都經過該鏈路(情況(2))(1)將不經過超過閾值的鏈路按照1中方法計算;(2)設置等待時間進行等待,在一個等待周期后對鏈路狀況進行分析,若從閾值回落,則按情況(1)處理,若不回落繼續等待,若一定周期后仍無回落,則丟棄。4)基礎算法分析本模塊的重點在于基于權重的最優路徑計算,使用最優路徑算法——Dijkstr_flyye1算法。使用該算法先求出最優路徑,再求出次優路徑,以此類推。算法思想如下:以有向圖作為算法參照圖(如圖4.11所示),設置兩個集合,其中一個集合存儲以計算的最優路徑,另一個集合計算未計算好的最優路徑。從原點到集合中每個頂點的權重均已標出。本小節的參照圖理想的認為圖中的沒條鏈路均為雙向鏈路,并且鏈路的兩個方向均采用同樣的權重信息。帶權重的有向圖用表示。加權函數為w,對所有的有用算法進行多次迭代,對每個頂點有對每個頂點,當u加入集合S時,圖在實現中以鄰接矩陣表示。本算法是以起始點為中心向外遍歷,在遍歷完所有節點算法結束。本實現流程將以圖4.2所示拓撲為準,圖中鏈路間的數字為每條鏈路的權重。圖4.11最短路徑計算拓撲表4.2最優路徑算法詳細步驟5)流程展示圖4.12最優路徑計算流程4.3.7決策調度根據最優路徑計算模塊得出的最優路徑,結合實際物理網絡,統計和路徑相關的交換設備。針對不同的交換設備進行轉發策略的下發。圖4.13決策調度流程第五章系統運行與實驗數據5.1編程語言選擇常用的編程語言有C、C++、C#、Java、Python,下面將在內存管理、跨平臺和性能優劣三個方面對這幾種語言進行取舍。5.1.1內存管理優秀的內存管理功能可以免去很多麻煩,尤其是在編程慣性錯誤方面。內存自動釋放收集就是一個很好的例子,由于C語言是面向過程的語言,他在自動內存釋放方面就存在劣勢,指針擁有強大的功能,但同時也存在著危險,忽略掉釋放內存的步驟,往往會出現野指針,嚴重者會造成運行時內存永久無法收集和CoreDump等問題。其他語言并未出現該問題,所以在第一點C語言存在劣勢。5.1.2跨平臺跨平臺亦是對語言的一項考驗,目前比較常用的主流操作系統平臺是Windows、Linux、MacOS,這些語言很明顯在這三種平臺上運行,不過C語言雖然在標準函數有跨平臺性,但每個系統均有自身優化的系統函數,這就造成在編程時并不能很高效的完成編程工作。因為編程開發者不能搞頻率的復用代碼,所以代碼編寫效率是一個很大的問題,C語言也并不是很好的語言選擇。5.1.3性能優劣性能描述是一個模糊的詞匯,有很多評判的標準。本文僅從多線程進行考慮由于流量調度系統需要支持大量的交換機的請求,所以多線程的性能指標是很關鍵的考慮因素。Python對多線程的支持并未真正實現多核處理,所以不再考慮之列。C/C++語言對多核的支持稍遜于Java。第三點中,考慮Java占到很大權重,將作為優先采納對象。綜上所述,java無論從內存管理、跨平臺、性能優劣都占有很大的優勢,最終選擇Java作為編程語言的最優選擇。5.2開發環境圖5.1開發環境圖例由于在開發語言上選擇了Java,開發環境選用Java開發的常用工具eclipse。Eclipse支持多種編程語言,且工具豐富,適合軟件的快速開發。該工具集代碼編寫、編譯鏈接、程序運行于一體,便于程序運行和調試,開發界面如圖5.1所示。5.3測試工具5.3.1MininetMininet是一個SDN網絡搭建工具,能夠迅速的搭建出符合軟件定義網絡特性的網絡。使用Python語言編程,通過命令行形式進行程序運行配置。該工具的方便之處在于可以使用快捷的命令產生線型、樹形拓撲,減少配置時間,達到快速配置網絡的效果。圖5.2Mininet網絡搭建工具5.3.2IperfIperf是一種網絡性能測試工具。iperf可以測試真實載荷下的網絡質量,可以測試端到端的網絡質量,可以測試一定吞吐率下的丟包、抖動。通過這些信息可以發現網絡問題,檢查網絡質量,定位網絡瓶頸。該工具主要應用于LINUX服務器。5.3.3ScapyScapy是一款強大的交互式數據包處理工具、數據包生成器、網絡掃描器、網絡發現工具和包嗅探工具。它提供多種類別的交互式生成數據包或數據包集合、對數據包進行操作、發送數據包、包嗅探、應答和反饋匹配等等功能。Python解釋器提供交互功能,所以要用到Python編程知識(例如variables、loops、和functions)。支持生成報告,且報告生成簡單。5.4測試流程及數據分析5.4.1拓撲創建圖5.3實驗測試拓撲使用Mininet創建一個實驗拓撲,如圖5.3所示,該拓撲中包含三臺交換機、10臺主機,由于空間有限,故將主機用省略圖表示。其中三臺交換機采用兩兩相連的方式連成環狀拓撲。該拓撲中主機和交換機的各端口的默認帶寬均為10Gbps。該拓撲的Mininet創建代碼如圖5.4所示。圖5.4Mininet創建拓撲代碼其中主機的IP地址分別為——0,——和交換機S1的1——5端口相連。——0和交換機S3的1——5端口相連。5.4.2工具測試1)iperf測試客戶端命令行,下面的5條命令分別作用在H1——H5的主機上,按照主機號加5的規律依次連接。Iperf–c–I1–n1000000000Iperf–c–I1–n1000000000Iperf–c–n1000000000Iperf–c–n1000000000Iperf–c0–n1000000000服務端命令行Iperf–s-I1運行情況如圖5.5所示圖5.5iperf運行時截圖5.4.3運行情況模擬如圖5.6和圖5.7所示,在系統運行初期,傳統網絡和流量調度系統均選擇了最短路徑算法。圖中黃色虛線為傳統網絡TE選擇的最優路徑,紅色虛線為SDN網絡TE選擇的最優路徑。圖中的綠色虛線即代表了該最短路徑,但是當S1——S2的鏈路流量增多時,鏈路吞吐量長上升態勢。當吞吐量達到一定閾值后,傳統網絡仍使用原先路徑,但SDN網絡TE選擇了另外一條可行的路線,直接的促進了數據的傳輸。圖5.6最優路徑圖1圖5.7最優路徑圖25.4.4測試數據繪圖1)時間——吞吐量關系圖時間(S)傳統網絡TE(Gbit/s)SDNTE(Gbit/s)00010.70.721.31.331.91.942.52.553363.43.573.7483.94.494.14.9104.255.3114.355.7124.356.1134.356.5144.356.8154.357.1164.357.35174.357.55184.357.7表5.1時間——吞吐量關系圖圖5.8吞吐量比較實驗測試的數據在表5.1中有體現,在圖5.8中展現了時間——吞吐量關系圖的曲線走勢。試驗中5個客戶端主機按照總計20秒的時間,均分成5個時刻加載到鏈路上。圖中的藍色曲線代表傳統網絡的TE,紅色曲線代表SDN網絡的TE,在剛開始的0——8s內藍色曲線和紅色曲線幾乎重合。隨著時間的推移藍色曲線在8s時和紅色曲線出現分離,并且藍色曲線趨于平緩,吞吐量最終趨于4Gbps,而紅色曲線依舊呈現增長態勢,直到趨向于8Gbps為止。根據圖中數據分析,傳統網絡和SDN網絡TE在剛開始均使用同一鏈路,。使用傳統網絡的TE在8s時最短路徑已經趨近飽和狀態,所以吞吐量指數趨于平緩。然而在使用了SDN網絡的TE后,系統實時的感應到鏈路狀態的變化,選擇了最優的路徑S1——>S2——>S3,這時鏈路的等效吞吐量還在上升,這就是SDN網絡的優勢體現。2)吞吐量——帶寬利用率關系圖吞吐量(G)傳統網絡TE(%)SDNTE(%)0000.51111122221.53231244412.55550365593.57468480714.58572.558873.55.59074691746.59274792.5747.592.574892.5748.592.574992.5749.592.574表5.2吞吐量——帶寬利用率關系圖圖5.9帶寬利用率實驗測試的數據在表5.2中有體現,在圖5.8中展現了吞吐量——帶寬利用率關系圖的曲線走勢。圖中的藍色曲線代表傳統網絡的TE,紅色曲線代表SDN網絡的TE,在剛開始的0——3.5Gbps內藍色曲線和紅色曲線幾乎重合。隨著吞吐量的增加藍色曲線在3.5Gbps時和紅色曲線出現分離,并且藍色曲線趨于平緩,帶寬利用率最終趨于92.5%,而紅色曲線依舊呈現增長態勢,直到趨向于74%為止。根據圖中數據分析,傳統網絡和SDN網絡TE在剛開始均使用同一鏈路,。使用傳統網絡的TE在3.5Gbps時最短路徑已經趨近飽和狀態,所以吞吐量指數趨于平緩。然而在使用了SDN網絡的TE后,系統實時的感應到鏈路狀態的變化,選擇了最優的路徑S1——>S2——>S3,這時鏈路的等效吞吐量還在上升,這就是SDN網絡的優勢體現。第六章總結與展望本畢業設計研究的課題是基于SDN的數據包控制策略。本課題主要任務是進行基于軟件定義網絡的流量調度系統的研究。1)研究現有的幾種控制器以及控制器和交換機通信的OpenFlow協議,理解OpenFlow協議中的消息類型及作用,并分析幾種版本OpenFlow協議的異同點和改善,為策略的制定提供依據;2)通過對數據包進行深度解析,根據協議類型、協議端口號等信息確定流量的類型。本課題所研究的流量類型:小股數據流構成的突發流量(即老鼠流)和持久且負載較高的穩定流量(即大象流);3)針對確定的流量進行算法分析制定最優調度策略。算法部分主要實現可行路徑計算、路徑鏈路狀態分析模塊、最優路徑計算、調度策略制定等功能;4)搭建實驗環境對調度策略進行驗證。針對流量調度系統進行相關應用場景的驗證性實驗,對實驗數據進行分析以對流量調度系統的可行性及效率進行分析;本論文的算法存在著一些有待提升的地方,在數據測量的時候主動測量時,在系統中存儲流量調度的策略信息,如果鏈路有所改變時,將鏈路信息主動獲取,并且將最新的最優路徑和存儲的最右邊路徑進行比對如果存在改變則更新相關策略,并刪除之前策略,下發新的策略。最終做到最有鏈路的實時性。本課題對軟件定義網絡的創新型應用的研究,對傳統網絡的流量調度問題提出了自己的解決方案,并對該方案的可行性進行了驗證。本課題是軟件定義網絡研究領域的一次嘗試,為后續流量調度的研究提供了參考。致謝本論文的編寫得到了很多老師、同學、公司同事的幫忙,可以說這個成果是所有人的功勞,由此對他們表示由衷的感謝。在本畢業設計(論文)寫作過程中,我的導師沈衛康教授給予了我精心的指導和悉心的關懷。在我的學業和畢業設計(論文)從題目確立、課題展開到論文寫作的過程中中無不傾注著導師辛勤的汗水和心血。導師的嚴謹治學態度、淵博的知識、無私的奉獻精神使我深受的啟迪。從尊敬的導師身上,我不僅學到了扎實、寬廣的專業知識,也學到了做人的道理。在此我要向我的導師致以最衷心的感謝和深深的敬意。在我的畢業設計(論文)撰寫過程中,張欣慰、何曉曦、王健等提出了非常寶貴的意見和建議,在此向他們表示由衷的謝意。在多年的學習生活中,還得到了許多學院領導、系(教研室)領導和老師的熱情關心和幫助。在日常學習和生活中,洪楊等都給予了我很大幫助。最后,向所有關心和幫助過我的領導、老師、同學和朋友表示由衷的謝意!衷心地感謝在百忙之中評閱我的設計(論文)和參加答辯的諸位老師!參考文獻[1]AwducheDO,AgogbuaJ.RequirementsfortrafficengineeringoverMPLS[J].1999.[2]劉亞萍,龔正虎.域間流量工程與域內流量工程的比較[J].計算機工程,2006,19:043.[3]J.Moy.OSPFversion2.UnitedStates:RFCEditor,1998:6-27[4]WangN,HoK,PavlouG,etal.Anoverviewofroutingoptimizationforinternettrafficengineering[J].CommunicationsSurveys&Tutorials,IEEE,2008,10(1):36-56.[5]GunnarA,AbrahamssonH,S?derqvistM.PerformanceoftrafficengineeringinoperationalIPnetworks–anexperimentalstudy[M]//OperationsandManagementinIP-BasedNetworks.SpringerBerlinHeidelberg,2005:202-211.[6]CasadoM,KoponenT,MoonD,etal.Rethinkingpacketforwardinghardware[C]//Proc.SeventhACMSIGCOMMHotNetsWorkshop.2008:11.[7]劉春佳.軟件定義網絡介紹[J].科研信息化技術與應用,2012,3:84-91.[8]王麗君,劉永強,張健.基于OpenFlow的未來互聯網試驗技術研究[J].電信網技術,2011(6):1-4.[9]GudeN,KoponenT,PettitJ,etal.NOX:towardsanoperatingsystemfornetworks[J].ACMSIGCOMMComputerCommunicationReview,2008,38(3):105-110.[10]DasS,ParulkarG,McKeownN,etal.PacketandcircuitnetworkconvergencewithOpenFlow[C]//OpticalFiberCommunicationConference.O

溫馨提示

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

評論

0/150

提交評論