南京工程學(xué)院畢業(yè)設(shè)計(jì)說明書(論文)作者：學(xué)號(hào)：院系：通信工程學(xué)院專業(yè)：通信工程（無線通信）題目：基于SDN的數(shù)據(jù)包控制策略的研究指導(dǎo)者：教授評(píng)閱者：2014年6月南京ThestrategyofDatapacketForwardbasedonSDNController

ADissertationSubmittedtoNanjingInstituteofTechnologyFortheAcademicDegreeofBachelorofScienceByYeJiSupervisedbyProfessorWeikangShenCollegeofCommunicationEngineeringNanjingInstituteofTechnologyJune2014摘要隨著互聯(lián)網(wǎng)的高速發(fā)展、業(yè)務(wù)的豐富多樣以及用戶的與日俱增，計(jì)算資源支撐不足、設(shè)備更新成本巨大成為互聯(lián)網(wǎng)企業(yè)無法回避的問題。軟件定義網(wǎng)絡(luò)（Software-DefinedNetworking，簡稱SDN）作為革命性的解決方案，提出了控制平面和數(shù)據(jù)平面解耦的思想，相較于傳統(tǒng)網(wǎng)絡(luò)的分布式架構(gòu)有了質(zhì)的飛躍。軟件定義網(wǎng)絡(luò)為解決傳統(tǒng)網(wǎng)絡(luò)難題提供了新的思路，學(xué)術(shù)界和工業(yè)界也紛紛提出了基于SDN的網(wǎng)絡(luò)新型應(yīng)用。流量工程作為傳統(tǒng)網(wǎng)絡(luò)面對的難題，一直是網(wǎng)絡(luò)研究領(lǐng)域中的熱點(diǎn)問題。本課題在SDN流量工程的場景下，提出基于軟件定義網(wǎng)絡(luò)的流量調(diào)度系統(tǒng)。通過對流量進(jìn)行深度解析以確定網(wǎng)絡(luò)的流量類型，進(jìn)行鏈路信息統(tǒng)計(jì)以獲取全網(wǎng)鏈路狀態(tài)。在此基礎(chǔ)上針對確定的流量類型下發(fā)相應(yīng)的的調(diào)度策略，以達(dá)到流量高效傳輸?shù)哪康模⑻嵘龓捓寐?、?yōu)化網(wǎng)絡(luò)性能。搭建相應(yīng)的實(shí)驗(yàn)環(huán)境進(jìn)行傳統(tǒng)網(wǎng)絡(luò)解決方案與本課題調(diào)度策略的對比測試，從多角度對該調(diào)度策略的效率進(jìn)行分析。本文的流量調(diào)度系統(tǒng)作為流量工程在軟件定義網(wǎng)絡(luò)的一個(gè)嘗試，為后續(xù)流量工程解決方案的研究提供新的思路。關(guān)鍵詞：軟件定義網(wǎng)絡(luò)；SDN；流量工程；路由策略；計(jì)算機(jī)網(wǎng)絡(luò) 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最優(yōu)路徑選擇該模塊利用可行路徑計(jì)算和鏈路狀態(tài)統(tǒng)計(jì)模塊所提供的參數(shù)進(jìn)行評(píng)測。按照鏈路長度、鏈路利用率的不同權(quán)重進(jìn)行計(jì)算，將計(jì)算結(jié)果進(jìn)行遞減排序，結(jié)果數(shù)值最大的即為最優(yōu)流量傳輸路徑。由于針對不同類型的流量是不同的調(diào)度策略，本小節(jié)著重闡述帶有權(quán)重的最優(yōu)路徑計(jì)算方案。不帶權(quán)重的最優(yōu)路徑方案只需將以上方案去掉權(quán)重即可實(shí)現(xiàn)。1）路徑選擇參數(shù)最優(yōu)路徑選擇的算法基于若干參數(shù)，包括路徑長度、鏈路帶寬、鏈路利用率等信息。下面將對這些參數(shù)進(jìn)行詳細(xì)闡述：A.路徑長度該選路主要針對大象流，由于其數(shù)據(jù)量大且持續(xù)對到達(dá)目的主機(jī)的鏈路進(jìn)行統(tǒng)計(jì)對比，在策略上將選擇最短的路徑進(jìn)行傳輸。如圖4.9所示，如果H1要發(fā)送數(shù)據(jù)包到H2，根據(jù)選路算法將優(yōu)先選擇將數(shù)據(jù)包通過S1直接轉(zhuǎn)發(fā)到S3最終到達(dá)H2，即H1-->S1-->S3-->h2，而不去選擇H1-->S1-->S2-->S3-->H2的路徑。圖4.9選路依據(jù)——路徑長度B.鏈路利用率該鏈路選擇的策略以到達(dá)目的主機(jī)的多條鏈路為基礎(chǔ)，策略先以其中一條鏈路為首選鏈路，所有數(shù)據(jù)轉(zhuǎn)發(fā)均經(jīng)過該鏈路，當(dāng)吞吐量到達(dá)閾值時(shí)再轉(zhuǎn)移其他鏈路，如此往復(fù)。如圖4.10為H1到H2之間的鏈路拓?fù)?，H1到H2的首選鏈路為H1-->S1-->S3-->H2，即圖左部拓?fù)涞木G色部分，并且狀態(tài)正常。當(dāng)鏈路吞吐量到達(dá)設(shè)定閾值時(shí)，即鏈路不健康，圖中右側(cè)拓?fù)潼S色表示到達(dá)閾值，選擇另外的鏈路（如圖中右側(cè)拓?fù)渚G色所示）即H1-->S1-->S2-->S3-->H2，如此往復(fù)。這種方法可以保證鏈路負(fù)載的均衡，提高帶寬利用率。s圖4.10選路依據(jù)——鏈路利用率2）權(quán)重計(jì)算將路徑長度N的權(quán)重設(shè)為10，將鏈路狀況的權(quán)重設(shè)為鏈路利用率U的倒數(shù)，設(shè)該路徑鏈路數(shù)量為n，則最優(yōu)路徑選擇系數(shù)W的計(jì)算公式(4-4)為： (4-4)3）閾值策略鏈路的狀態(tài)決定了大象流是否可以通過，所以需要設(shè)置一個(gè)閾值（默認(rèn)為鏈路利用率達(dá)到80%）以保證大象流的順利通過。也就是說鏈路帶寬利用率的大小決定了該條鏈路是否在路徑備選范圍之內(nèi)。下面根據(jù)閾值將情況做一個(gè)細(xì)分，并針對不同情況執(zhí)行不同的策略。1.所有鏈路均未超過閾值將鏈路利用率和路徑長度分別作為權(quán)重進(jìn)行計(jì)算以得到的最大值的路徑為最優(yōu)路徑；2.部分鏈路超過閾值，部分未超過這時(shí)超過閾值的路徑有兩種情況：有路徑不經(jīng)過超過閾值的鏈路（情況（1））和所有可行路徑都經(jīng)過該鏈路（情況（2））（1）將不經(jīng)過超過閾值的鏈路按照1中方法計(jì)算；（2）設(shè)置等待時(shí)間進(jìn)行等待，在一個(gè)等待周期后對鏈路狀況進(jìn)行分析，若從閾值回落，則按情況（1）處理，若不回落繼續(xù)等待，若一定周期后仍無回落，則丟棄。4）基礎(chǔ)算法分析本模塊的重點(diǎn)在于基于權(quán)重的最優(yōu)路徑計(jì)算，使用最優(yōu)路徑算法——Dijkstr_flyye1算法。使用該算法先求出最優(yōu)路徑，再求出次優(yōu)路徑，以此類推。算法思想如下：以有向圖作為算法參照圖（如圖4.11所示），設(shè)置兩個(gè)集合，其中一個(gè)集合存儲(chǔ)以計(jì)算的最優(yōu)路徑，另一個(gè)集合計(jì)算未計(jì)算好的最優(yōu)路徑。從原點(diǎn)到集合中每個(gè)頂點(diǎn)的權(quán)重均已標(biāo)出。本小節(jié)的參照圖理想的認(rèn)為圖中的沒條鏈路均為雙向鏈路，并且鏈路的兩個(gè)方向均采用同樣的權(quán)重信息。帶權(quán)重的有向圖用表示。加權(quán)函數(shù)為w，對所有的有用算法進(jìn)行多次迭代，對每個(gè)頂點(diǎn)有對每個(gè)頂點(diǎn)，當(dāng)u加入集合S時(shí)，圖在實(shí)現(xiàn)中以鄰接矩陣表示。本算法是以起始點(diǎn)為中心向外遍歷，在遍歷完所有節(jié)點(diǎn)算法結(jié)束。本實(shí)現(xiàn)流程將以圖4.2所示拓?fù)錇闇?zhǔn)，圖中鏈路間的數(shù)字為每條鏈路的權(quán)重。圖4.11最短路徑計(jì)算拓?fù)浔?.2最優(yōu)路徑算法詳細(xì)步驟5）流程展示圖4.12最優(yōu)路徑計(jì)算流程4.3.7決策調(diào)度根據(jù)最優(yōu)路徑計(jì)算模塊得出的最優(yōu)路徑，結(jié)合實(shí)際物理網(wǎng)絡(luò)，統(tǒng)計(jì)和路徑相關(guān)的交換設(shè)備。針對不同的交換設(shè)備進(jìn)行轉(zhuǎn)發(fā)策略的下發(fā)。圖4.13決策調(diào)度流程第五章系統(tǒng)運(yùn)行與實(shí)驗(yàn)數(shù)據(jù)5.1編程語言選擇常用的編程語言有C、C++、C#、Java、Python，下面將在內(nèi)存管理、跨平臺(tái)和性能優(yōu)劣三個(gè)方面對這幾種語言進(jìn)行取舍。5.1.1內(nèi)存管理優(yōu)秀的內(nèi)存管理功能可以免去很多麻煩，尤其是在編程慣性錯(cuò)誤方面。內(nèi)存自動(dòng)釋放收集就是一個(gè)很好的例子，由于C語言是面向過程的語言，他在自動(dòng)內(nèi)存釋放方面就存在劣勢，指針擁有強(qiáng)大的功能，但同時(shí)也存在著危險(xiǎn)，忽略掉釋放內(nèi)存的步驟，往往會(huì)出現(xiàn)野指針，嚴(yán)重者會(huì)造成運(yùn)行時(shí)內(nèi)存永久無法收集和CoreDump等問題。其他語言并未出現(xiàn)該問題，所以在第一點(diǎn)C語言存在劣勢。5.1.2跨平臺(tái)跨平臺(tái)亦是對語言的一項(xiàng)考驗(yàn)，目前比較常用的主流操作系統(tǒng)平臺(tái)是Windows、Linux、MacOS，這些語言很明顯在這三種平臺(tái)上運(yùn)行，不過C語言雖然在標(biāo)準(zhǔn)函數(shù)有跨平臺(tái)性，但每個(gè)系統(tǒng)均有自身優(yōu)化的系統(tǒng)函數(shù)，這就造成在編程時(shí)并不能很高效的完成編程工作。因?yàn)榫幊涕_發(fā)者不能搞頻率的復(fù)用代碼，所以代碼編寫效率是一個(gè)很大的問題，C語言也并不是很好的語言選擇。5.1.3性能優(yōu)劣性能描述是一個(gè)模糊的詞匯，有很多評(píng)判的標(biāo)準(zhǔn)。本文僅從多線程進(jìn)行考慮由于流量調(diào)度系統(tǒng)需要支持大量的交換機(jī)的請求，所以多線程的性能指標(biāo)是很關(guān)鍵的考慮因素。Python對多線程的支持并未真正實(shí)現(xiàn)多核處理，所以不再考慮之列。C/C++語言對多核的支持稍遜于Java。第三點(diǎn)中，考慮Java占到很大權(quán)重，將作為優(yōu)先采納對象。綜上所述，java無論從內(nèi)存管理、跨平臺(tái)、性能優(yōu)劣都占有很大的優(yōu)勢，最終選擇Java作為編程語言的最優(yōu)選擇。5.2開發(fā)環(huán)境圖5.1開發(fā)環(huán)境圖例由于在開發(fā)語言上選擇了Java，開發(fā)環(huán)境選用Java開發(fā)的常用工具eclipse。Eclipse支持多種編程語言，且工具豐富，適合軟件的快速開發(fā)。該工具集代碼編寫、編譯鏈接、程序運(yùn)行于一體，便于程序運(yùn)行和調(diào)試，開發(fā)界面如圖5.1所示。5.3測試工具5.3.1MininetMininet是一個(gè)SDN網(wǎng)絡(luò)搭建工具，能夠迅速的搭建出符合軟件定義網(wǎng)絡(luò)特性的網(wǎng)絡(luò)。使用Python語言編程，通過命令行形式進(jìn)行程序運(yùn)行配置。該工具的方便之處在于可以使用快捷的命令產(chǎn)生線型、樹形拓?fù)洌瑴p少配置時(shí)間，達(dá)到快速配置網(wǎng)絡(luò)的效果。圖5.2Mininet網(wǎng)絡(luò)搭建工具5.3.2IperfIperf是一種網(wǎng)絡(luò)性能測試工具。iperf可以測試真實(shí)載荷下的網(wǎng)絡(luò)質(zhì)量，可以測試端到端的網(wǎng)絡(luò)質(zhì)量，可以測試一定吞吐率下的丟包、抖動(dòng)。通過這些信息可以發(fā)現(xiàn)網(wǎng)絡(luò)問題，檢查網(wǎng)絡(luò)質(zhì)量，定位網(wǎng)絡(luò)瓶頸。該工具主要應(yīng)用于LINUX服務(wù)器。5.3.3ScapyScapy是一款強(qiáng)大的交互式數(shù)據(jù)包處理工具、數(shù)據(jù)包生成器、網(wǎng)絡(luò)掃描器、網(wǎng)絡(luò)發(fā)現(xiàn)工具和包嗅探工具。它提供多種類別的交互式生成數(shù)據(jù)包或數(shù)據(jù)包集合、對數(shù)據(jù)包進(jìn)行操作、發(fā)送數(shù)據(jù)包、包嗅探、應(yīng)答和反饋匹配等等功能。Python解釋器提供交互功能，所以要用到Python編程知識(shí)（例如variables、loops、和functions）。支持生成報(bào)告，且報(bào)告生成簡單。5.4測試流程及數(shù)據(jù)分析5.4.1拓?fù)鋭?chuàng)建圖5.3實(shí)驗(yàn)測試拓?fù)涫褂肕ininet創(chuàng)建一個(gè)實(shí)驗(yàn)拓?fù)?，如圖5.3所示，該拓?fù)渲邪_(tái)交換機(jī)、10臺(tái)主機(jī)，由于空間有限，故將主機(jī)用省略圖表示。其中三臺(tái)交換機(jī)采用兩兩相連的方式連成環(huán)狀拓?fù)?。該拓?fù)渲兄鳈C(jī)和交換機(jī)的各端口的默認(rèn)帶寬均為10Gbps。該拓?fù)涞腗ininet創(chuàng)建代碼如圖5.4所示。圖5.4Mininet創(chuàng)建拓?fù)浯a其中主機(jī)的IP地址分別為——0，——和交換機(jī)S1的1——5端口相連。——0和交換機(jī)S3的1——5端口相連。5.4.2工具測試1）iperf測試客戶端命令行，下面的5條命令分別作用在H1——H5的主機(jī)上，按照主機(jī)號(hào)加5的規(guī)律依次連接。Iperf–c–I1–n1000000000Iperf–c–I1–n1000000000Iperf–c–n1000000000Iperf–c–n1000000000Iperf–c0–n1000000000服務(wù)端命令行Iperf–s-I1運(yùn)行情況如圖5.5所示圖5.5iperf運(yùn)行時(shí)截圖5.4.3運(yùn)行情況模擬如圖5.6和圖5.7所示，在系統(tǒng)運(yùn)行初期，傳統(tǒng)網(wǎng)絡(luò)和流量調(diào)度系統(tǒng)均選擇了最短路徑算法。圖中黃色虛線為傳統(tǒng)網(wǎng)絡(luò)TE選擇的最優(yōu)路徑，紅色虛線為SDN網(wǎng)絡(luò)TE選擇的最優(yōu)路徑。圖中的綠色虛線即代表了該最短路徑，但是當(dāng)S1——S2的鏈路流量增多時(shí)，鏈路吞吐量長上升態(tài)勢。當(dāng)吞吐量達(dá)到一定閾值后，傳統(tǒng)網(wǎng)絡(luò)仍使用原先路徑，但SDN網(wǎng)絡(luò)TE選擇了另外一條可行的路線，直接的促進(jìn)了數(shù)據(jù)的傳輸。圖5.6最優(yōu)路徑圖1圖5.7最優(yōu)路徑圖25.4.4測試數(shù)據(jù)繪圖1）時(shí)間——吞吐量關(guān)系圖時(shí)間（S）傳統(tǒng)網(wǎng)絡(luò)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時(shí)間——吞吐量關(guān)系圖圖5.8吞吐量比較實(shí)驗(yàn)測試的數(shù)據(jù)在表5.1中有體現(xiàn)，在圖5.8中展現(xiàn)了時(shí)間——吞吐量關(guān)系圖的曲線走勢。試驗(yàn)中5個(gè)客戶端主機(jī)按照總計(jì)20秒的時(shí)間，均分成5個(gè)時(shí)刻加載到鏈路上。圖中的藍(lán)色曲線代表傳統(tǒng)網(wǎng)絡(luò)的TE，紅色曲線代表SDN網(wǎng)絡(luò)的TE，在剛開始的0——8s內(nèi)藍(lán)色曲線和紅色曲線幾乎重合。隨著時(shí)間的推移藍(lán)色曲線在8s時(shí)和紅色曲線出現(xiàn)分離，并且藍(lán)色曲線趨于平緩，吞吐量最終趨于4Gbps，而紅色曲線依舊呈現(xiàn)增長態(tài)勢，直到趨向于8Gbps為止。根據(jù)圖中數(shù)據(jù)分析，傳統(tǒng)網(wǎng)絡(luò)和SDN網(wǎng)絡(luò)TE在剛開始均使用同一鏈路，。使用傳統(tǒng)網(wǎng)絡(luò)的TE在8s時(shí)最短路徑已經(jīng)趨近飽和狀態(tài)，所以吞吐量指數(shù)趨于平緩。然而在使用了SDN網(wǎng)絡(luò)的TE后，系統(tǒng)實(shí)時(shí)的感應(yīng)到鏈路狀態(tài)的變化，選擇了最優(yōu)的路徑S1——>S2——>S3，這時(shí)鏈路的等效吞吐量還在上升，這就是SDN網(wǎng)絡(luò)的優(yōu)勢體現(xiàn)。2）吞吐量——帶寬利用率關(guān)系圖吞吐量（G）傳統(tǒng)網(wǎng)絡(luò)TE（%）SDNTE（%）0000.51111122221.53231244412.55550365593.57468480714.58572.558873.55.59074691746.59274792.5747.592.574892.5748.592.574992.5749.592.574表5.2吞吐量——帶寬利用率關(guān)系圖圖5.9帶寬利用率實(shí)驗(yàn)測試的數(shù)據(jù)在表5.2中有體現(xiàn)，在圖5.8中展現(xiàn)了吞吐量——帶寬利用率關(guān)系圖的曲線走勢。圖中的藍(lán)色曲線代表傳統(tǒng)網(wǎng)絡(luò)的TE，紅色曲線代表SDN網(wǎng)絡(luò)的TE，在剛開始的0——3.5Gbps內(nèi)藍(lán)色曲線和紅色曲線幾乎重合。隨著吞吐量的增加藍(lán)色曲線在3.5Gbps時(shí)和紅色曲線出現(xiàn)分離，并且藍(lán)色曲線趨于平緩，帶寬利用率最終趨于92.5%，而紅色曲線依舊呈現(xiàn)增長態(tài)勢，直到趨向于74%為止。根據(jù)圖中數(shù)據(jù)分析，傳統(tǒng)網(wǎng)絡(luò)和SDN網(wǎng)絡(luò)TE在剛開始均使用同一鏈路，。使用傳統(tǒng)網(wǎng)絡(luò)的TE在3.5Gbps時(shí)最短路徑已經(jīng)趨近飽和狀態(tài)，所以吞吐量指數(shù)趨于平緩。然而在使用了SDN網(wǎng)絡(luò)的TE后，系統(tǒng)實(shí)時(shí)的感應(yīng)到鏈路狀態(tài)的變化，選擇了最優(yōu)的路徑S1——>S2——>S3，這時(shí)鏈路的等效吞吐量還在上升，這就是SDN網(wǎng)絡(luò)的優(yōu)勢體現(xiàn)。第六章總結(jié)與展望本畢業(yè)設(shè)計(jì)研究的課題是基于SDN的數(shù)據(jù)包控制策略。本課題主要任務(wù)是進(jìn)行基于軟件定義網(wǎng)絡(luò)的流量調(diào)度系統(tǒng)的研究。1）研究現(xiàn)有的幾種控制器以及控制器和交換機(jī)通信的OpenFlow協(xié)議，理解OpenFlow協(xié)議中的消息類型及作用，并分析幾種版本OpenFlow協(xié)議的異同點(diǎn)和改善，為策略的制定提供依據(jù)；2）通過對數(shù)據(jù)包進(jìn)行深度解析，根據(jù)協(xié)議類型、協(xié)議端口號(hào)等信息確定流量的類型。本課題所研究的流量類型：小股數(shù)據(jù)流構(gòu)成的突發(fā)流量（即老鼠流）和持久且負(fù)載較高的穩(wěn)定流量（即大象流）；3）針對確定的流量進(jìn)行算法分析制定最優(yōu)調(diào)度策略。算法部分主要實(shí)現(xiàn)可行路徑計(jì)算、路徑鏈路狀態(tài)分析模塊、最優(yōu)路徑計(jì)算、調(diào)度策略制定等功能；4）搭建實(shí)驗(yàn)環(huán)境對調(diào)度策略進(jìn)行驗(yàn)證。針對流量調(diào)度系統(tǒng)進(jìn)行相關(guān)應(yīng)用場景的驗(yàn)證性實(shí)驗(yàn)，對實(shí)驗(yàn)數(shù)據(jù)進(jìn)行分析以對流量調(diào)度系統(tǒng)的可行性及效率進(jìn)行分析；本論文的算法存在著一些有待提升的地方，在數(shù)據(jù)測量的時(shí)候主動(dòng)測量時(shí)，在系統(tǒng)中存儲(chǔ)流量調(diào)度的策略信息，如果鏈路有所改變時(shí)，將鏈路信息主動(dòng)獲取，并且將最新的最優(yōu)路徑和存儲(chǔ)的最右邊路徑進(jìn)行比對如果存在改變則更新相關(guān)策略，并刪除之前策略，下發(fā)新的策略。最終做到最有鏈路的實(shí)時(shí)性。本課題對軟件定義網(wǎng)絡(luò)的創(chuàng)新型應(yīng)用的研究，對傳統(tǒng)網(wǎng)絡(luò)的流量調(diào)度問題提出了自己的解決方案，并對該方案的可行性進(jìn)行了驗(yàn)證。本課題是軟件定義網(wǎng)絡(luò)研究領(lǐng)域的一次嘗試，為后續(xù)流量調(diào)度的研究提供了參考。致謝本論文的編寫得到了很多老師、同學(xué)、公司同事的幫忙，可以說這個(gè)成果是所有人的功勞，由此對他們表示由衷的感謝。在本畢業(yè)設(shè)計(jì)（論文）寫作過程中，我的導(dǎo)師沈衛(wèi)康教授給予了我精心的指導(dǎo)和悉心的關(guān)懷。在我的學(xué)業(yè)和畢業(yè)設(shè)計(jì)（論文）從題目確立、課題展開到論文寫作的過程中中無不傾注著導(dǎo)師辛勤的汗水和心血。導(dǎo)師的嚴(yán)謹(jǐn)治學(xué)態(tài)度、淵博的知識(shí)、無私的奉獻(xiàn)精神使我深受的啟迪。從尊敬的導(dǎo)師身上，我不僅學(xué)到了扎實(shí)、寬廣的專業(yè)知識(shí)，也學(xué)到了做人的道理。在此我要向我的導(dǎo)師致以最衷心的感謝和深深的敬意。在我的畢業(yè)設(shè)計(jì)（論文）撰寫過程中，張欣慰、何曉曦、王健等提出了非常寶貴的意見和建議，在此向他們表示由衷的謝意。在多年的學(xué)習(xí)生活中，還得到了許多學(xué)院領(lǐng)導(dǎo)、系（教研室）領(lǐng)導(dǎo)和老師的熱情關(guān)心和幫助。在日常學(xué)習(xí)和生活中，洪楊等都給予了我很大幫助。最后，向所有關(guān)心和幫助過我的領(lǐng)導(dǎo)、老師、同學(xué)和朋友表示由衷的謝意！衷心地感謝在百忙之中評(píng)閱我的設(shè)計(jì)（論文）和參加答辯的諸位老師！參考文獻(xiàn)[1]AwducheDO,AgogbuaJ.RequirementsfortrafficengineeringoverMPLS[J].1999.[2]劉亞萍,龔正虎.域間流量工程與域內(nèi)流量工程的比較[J].計(jì)算機(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]劉春佳.軟件定義網(wǎng)絡(luò)介紹[J].科研信息化技術(shù)與應(yīng)用,2012,3:84-91.[8]王麗君,劉永強(qiáng),張健.基于OpenFlow的未來互聯(lián)網(wǎng)試驗(yàn)技術(shù)研究[J].電信網(wǎng)技術(shù),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