OpenFlow-BasedPath-PlanningwithBandwidthGuaranteeintheInter-DatacenterNetwork

Tang Wan, Liu Guo, Yang Ximin, Chen Fan

(CollegeofComputerScience,South-CentralUniversityforNationalities,Wuhan430074,China)

?

OpenFlow-BasedPath-PlanningwithBandwidthGuaranteeintheInter-DatacenterNetwork

Tang Wan, Liu Guo, Yang Ximin, Chen Fan

(CollegeofComputerScience,South-CentralUniversityforNationalities,Wuhan430074,China)

AbstractCloudservicesthroughtheinter-datacenternetwork(IDN)makerequestsfordifferentbandwidthdemandsondifferenttemporalscalesintime.Inthispaper,apath-planningscheme,entitledOpenFlow-basedpath-planningwithbandwidthguarantee(OPPBG),wasproposedtoaddresstheissue.Aslongasaflowarrives,theOPPBGschemefirstlycollectsthereal-timelinkstatusofthenetworkandreturnsavirtualtopologywithsufficientremainderbandwidth.Itthenplansanoptimalroutingpathfortheflowbasedonasoftware-definednetworking(SDN)managementplatformapplyingtheOpenFlowprotocol.Simulationresultsrevealedthat,incomparisontotheIDNbasedonthetraditionalpath-planningscheme,theOPPBG-basedIDNcanachievealowerpacketlossrateandhigherbandwidthutilizationwithbandwidthguarantee.

Keywordssoftware-definednetworking(SDN)；datacenternetwork；pathplanning；bandwidthguarantee

1Introduction

Therapiddevelopmentofcloudcomputinginrecentyearshaspromotedtheworldwideconstructionofdatacenters.Duetotheuncertaintyandhugeamountoftrafficoccurringintheinter-datacenternetwork(inter-DCN),thepossibleflowpeakisgenerallyregardedasthehighestbandwidthdemand[1,2],usuallyleadingtolowbandwidthutilization.TraditionalroutingprotocolsrouteandforwardthetrafficbyapplyingtheShortestPathpolicy.However,althoughsomelinksalongtheshortestpathofaflowtransmitpacketsclosetofullcapability,subsequentpacketsoftheflowcontinuetobeinjected,givingrisetolink-overloadintheinter-DCN.Themostcommonlyappliedsolutiontothelink-overloadprobleminvolvestransformingorupgradingthenetwork,e.g.,byincreasingthetotaltransmissioncapabilityorsupplementingmoreredundantlinks[3].

Variousresearchhasfocusedontheproblemoutlinedabove.Forexample,astore-and-forwardmechanismhasbeenappliedtomakebandwidthusagemoreeffective[4,5].ThealgorithmhasalargermaximumvolumeofdatatransferandashorterendtimeofaveragebulktransferincomparisontoNetStitcherproposedinRef[6].However,theexecutiontimeofthealgorithmislongerduetoitsiterativeprocessesemployedinseekingtheexactoptimalsolution.Thegreedyresidualscheduler(GRESE)proposedinRef[7]attemptstominimizeoverallbandwidthconsumptionbyleveragingtheflexiblenatureofbulkdatajobdeadlines.However,theseproposalsmadelittleconsiderationofthefactthattheinter-DCNarchitecturecontainshundredsofthousandsofswitcheswithwhichtohandlethetremendousvolumeoftrafficoriginatingfromdifferentdatacenters.Thedevelopmentofamechanismabletocontrolandmanagetheseswitchesinaunifiedmanner,wouldthusenablethekeystepsofpathplanning,i.e.routingandbandwidthallocation,tobecarriedoutmoreflexibly.

Fortunately,suchagoalcanbeachievedbyintroducingOpenFlow-acommunicationsprotocolthatwasinitiallydevelopedtoenableinnovationexperimentsincampusnetworks[8].OpenFlowworksasafundamentalelementinsoftware-definednetworking(SDN)solutions.IntheSDN,thecontrolplaneisseparatedfromtheforwardingplane,andthecontrolleriscapableofdeterminingthepathsofpacketsthroughthenetworkofswitches[9,10],whichmakesiteasierfornetworkmanagement[11-13].SDNsuppliesaremotecontrollingmechanismbymaintainingtheflowtable(s)ineachOpenFlowswitch.Aflowtableconsistsofasetofpacket-matchingrulesandactions,withthecontrollermanagingflowtrafficbyadding,deletingormodifyingtheentriesoftheflowtables.

SomeSDN-basedsolutionshavealsobeenproposedtosolvetheproblemoftrafficmanagementininter-DCNs.Kanagaveluetal.proposedare-routingcontrolframeworkbasedonOpenFlowtosolvenetworkcongestion[14].But,there-routingprocessrequiresextratimeandistosolveratherthantoavoidnetworkcongestion.Additionally,inordertodealwithdatareplicationbetweendifferentdatacenters,anSDN-basedroutingschemewasproposedinRef[15].However,calculatingallthesepossiblepathsleadstohighspatialandtemporalresourceconsumption.

Inthispaper,weproposeapath-planningschemeforinter-DCNs,namedOpenFlow-basedpath-planningwithbandwidthguarantee(OPPBG).OPPBGcollectsnetworkinformationincludingnetworktopology,remainderbandwidthofeachlink,etc.,viaacontroller,andcalculatestheroutingpathsconsideringtheon-demandbandwidthbyflows.Whenaflowarrivesattheedgenode,OPPBGfirstlyextractstheappropriatetopologyinwhichthelinksmeetthebandwidthrequirementoftheflow,withtheshortestpaththendeterminedaccordingtotheextractedtopology.Finally,thebandwidthofeachlinkonthepathisalsoreservedforthearrivalflow.

2OpenFlow-basedpath-planningwithbandwidthguarantee

Inthissection,wedescribethekeypointsofOPPBGindetail,includingtheSDNmanagementplatform,timesequence,andpath-planningstrategy.

2.1SDNmanagementplatform

InordertocarryouttheOPPBGscheme,wedevelopedanSDNmanagementplatformbelongingtotheapplicationlayeroftheSDNstructuregiveninFig.1.IntheSDNstructure,thelowestlayeristhephysicalinter-SDNnetworkcomprisingOpenFlowswitches,links,anddatacenterstreatedastheterminaloftheInter-SDNandconnectingwiththeOpenFlowswitches.ThemiddlelayeristhecontrollerthatmanagesswitchesinaunifiedmannerbasedontheOpenFlowprotocol.TheSDNmanagementplatformisoverthecontrollerandcollectsthereal-timestatusoflinksanddevicesviaanumberofRESTAPIs[16].Accordingtotheobtainedinformation,themanagementplatformcalculatesthepaths,withthecontrollerthensendingthepathinformationtotherelatedOpenFlowswitchesbymeansofflowentries.

Thedevelopedplatform,whichisbasedonthenortherninterfacesofferedbythecontroller,consistsofseveralmoduleswithdifferentfunctions,includingobtainingnetworktopology,loadbalancing,flowtablemanagement,etc.Inthissubsection,webrieflyintroducesomeofthemodulesrelatedtorouting,anddescribehowtheyworktogethertoachievethetaskofpath-planningwithbandwidthguarantee.

(1)Topologyaccessor.ThetopologyaccessormodulemaintainsaJavaScriptobjectnotation(JSON),alightweightdata-interchangeformattotransmitthedataobjectsconsistingofattribute-valuepairs.ThismodulecollectsthetopologyinformationusingthreeRESTAPIs: (a)FeatureAPI,whichcapturesthestatusinformationofeachportinswitches(e.g.bandwidth)；(b)LinkAPI,whichcollectsinter-switchlinkinformation；(c)DeviceAPI,whichprovidesthepropertyinformationofeachdevice,aswellaslinkinformationbetweenterminalsandswitches.

(2)Routingmanager.Theroutingmanagermoduleistheprimarymodulecarryingoutpath-planningandservicestwomajorfunctions.Thefirstofthesefunctionsistocalculatethepathsbyexecutingtheroutingalgorithmstoredinanalgorithmcontainer;theglobalnetworkinformationforroutingisprovidedbytheTopologyAccessormodule.ThesecondmajorfunctionistogenerateorupdatetheflowentriesaccordingtothecalculatedpathandthensendtheseflowentriestoeachcorrespondingswitchviatheController.

Fig.1　SDN basic structure for Inter-DCN圖1　數(shù)據(jù)中心間網(wǎng)絡(luò)的SDN基本架構(gòu)

2.2TimesequenceofOPPBG

OPPBGworksaccordingtothesequencesshowninFig.2.Inordertoacquirethetopologyinformation,theTopologyAccessorsendsaTopologyInformationRequesttotheController.Afterthat,theControllercollectstheinformationofeachdeviceorlinkandsendsittotheTopologyAccessor,whichreceivestheinformationtoobtainthenetworkstatusandbuildtheglobaltopology.Followingthisstep,thetopologyinformationissenttotheRoutingManager,whichcomputesthecorrespondingpathsbasedonthespecifiedroutingalgorithm.Finally,theseroutingresultsaresubmittedtotheController,whichupdatestheflowtablesofcorrespondingswitchesusingthecontroller-to-switchMessages.

Inthetaskofpath-planningintheinter-DCN,OPPBGattemptstotakefulladvantageoftheSDNfeaturesnetworkprogrammability,controlcentralization,andseparationbetweenthecontrolplaneanddataplane.OPPBG′sSDNmanagementplatformcaneasilyobtaintheglobaltopologyinformationbymonitoringthelinkstatusinrealtime.Furthermore,inordertodecreasethepacketlossrateandsettlelinkoverload,theroutingworkintheSDNmanagementplatformappliestheroutingwithbandwidthguarantee(RBG)routingalgorithm.Asthepresentpaperfocusesonpath-planning,theRoutingManageristhemainpartoftheSDNmanagementplatform.

Fig.2　OPPBG time sequence圖2　OPPBG時(shí)序圖

Itisworthnotingthattheplatformcanalsobeexpandedforotherfunctions,suchasasecuritymoduleoraQoSanalyzer.

2.3Path-planning----routingwithbandwidth

guarantee(RBG)

Inordertoprovideenoughbandwidthtotrafficbyusingoptimalroutingpaths,wehereproposetheRBGroutingalgorithm,whichisstoredinthealgorithmcontainerandexecutedintheRoutingManager.RBGfollowsthreesteps,takingconsiderationofthelinkbandwidthconstraints.Moreover,thetriplefw (src, dst, ban)denotesanarrivingflowfwwithsourcenodesrc,destinationnodedst,andbandwidthdemandban,respectively.

*Step1:extractthepropertopologymeetingthebandwidthrequirement.Morespecifically,thisstepcreatesaduplicateofcurrentnetworktopology,anddeletesthelinksonwhichtheremainingbandwidthcannotmeetthebandwidthbanrequiredbytheapproachingflowfw;

*Step2:withthenodepair(src, dst),calculatetheshortestpathpausingtheDijkstraalgorithmonthetopologyobtainedinStep1.Eachlinkofpahassufficientremainderbandwidthfortheflowfw;

*Step3:reservebandwidthalongthepathpa,sothattheavailablebandwidthofeachlinkonpawilldecreasebyban.

Fig.3showsasimpleexampledescribinghowRBGroutesthroughthethreesteps,inwhichf1isaflowwiththesourcenodeN1,thedestinationnodeN7and15Mbit/sbandwidthdemand.Inthetopology,thenumberoveralinkrepresentsitsremainderbandwidth,andalllinksareequalinlength.Fig.3(a)describeshowStep1extractsthepropertopologyfortheflowf1.Link(N2,N6)isdeletedbecauseitsunemployedbandwidthislessthanthebandwidthdemandoff1.Pathselectionisthencarriedoutonthenewtopologygivenintheleft-handpartofFig.3(a).ThedottedlineinFig.3(b)indicatesthedeterminedroutingpathforf1.Eachlinkalongthepathupdatesitsunemployedbandwidth,asshowninFig.3(c).

3Performanceevaluation

Inthissection,weevaluatetheproposedOPPBGschemeviasimulationcomparedwiththeShortestPathscheme.Packetlossrate,linkbandwidthutilizationandaveragehopcountareappliedasperformancemetrics.

Fig.3　An example of the RBG process圖3　RBG過程示例

3.1Simulationenvironmentandsetting

Inthesimulation,thecontroller,datacentersandOpenFlowswitchesaresoftware-baseddevicesconstructedwithinMininet(version2.1.0p2)[16]runningontheLinuxsystem(Ubuntu14.04,installedonVirtualBoxversion4.3.12).ThecontrollerisFloodlightController(version0.90)[17]runningonaPCwith64-bitWindows7.ThePCcontainstwophysicalcoreswithIntel(R)Core(TM)i5-3230processorsand4GBRAM.Furthermore,theSDNManagementPlatform,holdingtheproposedroutingalgorithm,alsorunsinthePC.Thetraditionalshortestpathroutingschemewasalsotestedinthesameenvironmentforcomparison.

Inthesimulation,UDPtrafficisgeneratedviaIperf,asoftwaretoolmainlyusedformeasuringTCPandUDPbandwidth[18].Iperfisabletobothgeneratestabletrafficfortestingandprovidefeedbackinformation,suchasthetransmitbandwidth,delayjitteranddatagramlossrate.Notethatalthoughthebandwidthunit(inMbit/s)inoursimulationisthreeordersofmagnitudelowerthanthatintherealinter-DCN(inGbit/s)duetothelimitationofIperf,however,thisdoesnotimpactontheevaluation.

ThephysicaltopologyofthesimulationnetworkispresentedinFig.4.ThenetworkconsistsoftenOpenFlowswitchesandeightdatacenters.Thebandwidthcapabilityofeachlinkis100Mbit/s,withthevalueshownonthelinkrepresentingitsweightinlinkdelaytime(inms).AlthoughnotshowninFig.4,alltheOpenFlowswitchesareconnectedtotheSDNcontroller.

Fig.4　Topology of the test network圖4　測試網(wǎng)絡(luò)的拓?fù)?/p>

3.2FeasibilityofRBG

Inthissubsection,weverifythefeasibilityoftheRBGalgorithmbasedontheuseoftwotestscenarios,whoseflowinformationislistedinTab.1.InScenario1,thebandwidthdemandofflowislessthanthelinkbandwidth,inordertocheckwhethertheselectedpathistheshortestavailableinsuchasituation.InScenario2,thetotalrequiredbandwidthoftwoarrivingflowsislargerthantheunemployedlinkbandwidth.ThisistocheckwhethertheRBGcanprovideanalternativepathwhentheshortestoneiscongested.Inaddition,theshortestpathroutingisalsotestedinbothscenariosforpathcomparison.

Tab.1　Flowinformation

Tab.2　Comparisonofpath-planningresults

TheroutingpathsachievedinthesimulationscenariosaregiveninTab.2.InScenario1,thebandwidthdemandoff1is80Mbit/s,whichislessthanthemaximumlinkbandwidth.ThepathcalculatedbyRBG,D1-S1-S4-S6-S10-D8,isequaltothatcalculatedbytheShortestPathalgorithm;thisisbecausethetopologyobtainedfromRBGStep1isthesameastheoriginal.Thatistosay,whentherequiredbandwidthofaflowcanbesatisfied,theRBGplaystheroleofthetraditionalShortestPathalgorithm.

InScenario2,thesourcenodes,destinationnodesandon-demandbandwidthsforthetwoflowsaredifferent.Thetotalbandwidthrequirementis130Mbit/s,whichislargerthanthelinkcapabilityof100Mbit/s.Asaresult,oncethepathsofthetwoflowshaveacommonlink,acollisionwilltakeplaceonthelink.

Forinstance,asshowninFig.5,byusingthetraditionalShortestPathroutingscheme,thepathsoff2andf3areD4-S4-S6-D5 (thebluesolidarrowlinesinFig.5(a))andD1-S1-S4-S6-S10-D8 (theblackdottedarrowlinesinFig.5(a)),respectively.Thismayleadtocongestionasthetwopathshaveacommonlink(betweenS4andS6).

Incontrast,packetcongestionbetweenthetwoflowswillbeavoidedwhenapplyingtheproposedRBGinScenario2.Inthiscase,f3acquiresanotherpath:D1-S1-S2-S3-S5-S7-S9-S10-D8 (thedottedarrowlinesinFig.5(b)).Thisalternativepathisdisjointedwiththatoff2,thatistosay,thereisnocommonlinkbetweenthepathsofthetwoflowsandthusthepacketcollisionisprevented.

(a) Path calculated by the Shortest Path 　　　　　　　　　　　　　(b) Path calculated by RBGFig.5　Routing Paths of f2(D4,D5,50) and f3(D1,D8,80) in Scenario 2圖5　場景2中 f2(D4,D5,50) 和f3(D1,D8,80)的路徑

3.3Networkperformance

Tab. 3　Simulationsettings

Accordingtothedifferentcombinationsofsource-destinationpairs,wecarriedoutatotalof24simulationtests.Thepacketlossratesofthese24testsarepresentedinFig.6.Insomecases(tests1,3,4,7,9,10,11,12,15,16,21,22,23and24),thepacketlossrateoftheOPPBGcasesareequaltothatoftheShortestPathmethod,becausetheroutingpathscalculatedbythetwoschemesarethesame.AsshowninFig.7,thesinglepacketend-to-enddelaysofthetwoschemesareclose.Intheothercases(tests2,5,6,8,13,14,17,18,19and20),OPPBGoffersanalternativepathinordertopreventbandwidthresourcecompetitionwhentheshortestonecannotsupplyenoughbandwidth.Consequently,fewerpacketswillbediscardedthanintheShortestPathcase.Inthesecases,thesinglepacketend-to-enddelaysdonotshowevidentregularity.

Fig.6　Packet loss rate comparison圖6　丟包率比較

Intests5,6,17,18,19and20,thepacketlossrateofOPPBGisclosetozero,whichismuchlowerthanthatoftheShortestPathscheme.However,asshowninFig.8,theaveragehopcountsoftheOPPBGcasesarehigherbecausetheirroutingpathsmaynotbetheshortest(theaveragehopcountdenotestheaveragenumberofswitchesintheflowpaths).

Fig.9depictsthelinkbandwidthutilization.Duetomoresuccessfullytransferredpacketsandlesscongestion,thelinkbandwidthutilizationishigherwhenusingintheOPPBG.Here,thenetworklinkbandwidthutilizationiscalculatedbyEq.(1),withthebandwidthutilizationofasinglelinkbeingequaltotheratiooftheusedbandwidthtolinkcapability.

Ulink_bandwidth=

(1)

Fig.7　End-to-end delay comparison圖7　端到端延遲比較

Fig.8　Average hop count comparison圖8　平均跳數(shù)比較

Fig.9　Link bandwidth utilization comparison圖9　鏈路帶寬利用率比較

Finally,Tab.4displaysanoverallcomparison(theaverageresultof24tests)intermsofpacketlossrate,linkbandwidthutilizationandhopcount.TheseresultsshowthatthenetworkbasedonOPPBGachievedasmallerpacketlossprobabilityandbetterbandwidthutilization.InthecaseofOPPBG,Thepacketsrequiremorehopsonroutetotheirdestinationsbecausetheforwardingpathoftheflowmaynotbetheshortestonetoavoidpacketcongestionandthusfulfilthebandwidthguarantee.Foraninter-DCNthatcallsforhighthroughput,theproposedOPPBGsystemwouldbeapplicable.

Tab. 4　Performancecomparison

4Conclusion

Inthispaper,weaddresstheproblemoflinkoverloadinaninter-DCNbyproposingtheuseofOPPBG,anOpenFlow-basedpath-planningschemewithbandwidthguaranteefortrafficflows.DuetotheSDN′scentralizedcontrolapplyingtheOpenFlowprotocol,OPPBGcollectstheglobalinformationoftheinter-SDN,especiallythatregardinglinkstatus,forroutingandforwardingpackets,consideringthebandwidthconstraintsofdifferenttrafficflows.SimulationrevealedthatthenetworkapplyingOPPBGhadalowerpacketlossrateandbetterlinkbandwidthutilizationthanthatusingtheShortestPathroutingscheme.Inaddition,thankstothesuperiorityoftheSDNarchitectureandOpenFlow,inter-DCNnetworkmanagementtaskscanbecarriedoutinamoreeasyandflexiblemanner.

References

[1]GuoJ,LiuF,HuangX,etal.Onefficientbandwidthallocationfortrafficvariabilityindatacenters[C]//IEEE.Proceedingsofthe33rdAnnualIEEEInternationalConferenceonComputerCommunications(INFOCOM′14).Toronto:IEEE,2014:1572-1580.

[2]ChenM,QianY,MaoS,etal.Software-definedmobilenetworkssecurity[J].ACM/SpringerMobileNetworksandApplications,2016(1):1-15,DOI:10.1007/s11036-015-0665-5.

[3]ChenY,JainS,AdhikariV,etal.Afirstlookatinter-datacentertrafficcharacteristicsviaYahoo!Datasets[C]//IEEE.Proceedingsofthe30rdAnnualIEEEInternationalConferenceonComputerCommunications(INFOCOM′11).Shanghai:IEEE,2011:1620-1628.

[4]LiY,WangH,ZhangP,etal.D4D:Inter-datacenterbulktransferswithISPfriendliness[C]//IEEE.ProceedingsofIEEEInternationalConferenceonClusterComputing(Cluster′12).Beijing:IEEE,2012:597-600.

[5]WangY,SuS,JiangS,etal.Optimalroutingandbandwidthallocationformultipleinter-datacenterbulkdatatransfers[C]//IEEE.ProceedingsofIEEEInternationalConferenceonCommunications(ICC′12).Ottawa:IEEE,2012:5538-5542.

[6]LaoutarisN,SirivianosM,YangX,etal.Inter-datacenterbulktransferswithNetStitcher[J].ACMSIGCOMMComputerCommunicationReview,2011,41(4):74-85.

[7]NandagopalT,PuttaswamyKPN.Loweringinter-datacenterbandwidthcostsviabulkdatascheduling[C]//IEEE.Proceedingsofthe12thIEEE/ACMInternationalSymposiumonCluster,CloudandGridComputing(CCGrid′12).Ottawa:IEEE,2012:244-251.

[8]McKeownN,AndersonT,BalakrishnanH,etal.OpenFlow:enablinginnovationincampusnetworks[J].ACMSIGCOMMComputerCommunicationReview,2008,38(2):69-74.

[9]ONF.Software-definednetworking:thenewnormfornetworks(whitepaper)[EB/OL].[2015-01-02].https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf.

[10]XuY,YanY,DaiZ,etal.AmanagementmodelforSDN-baseddatacenternetworks[C]//IEEE.ProceedingsofIEEEConferenceonComputerCommunicationsWorkshops(INFOCOMWKSHPS).Toronto:IEEE,2014:113-114.

[11]KimH,FeamsterN.Improvingnetworkmanagementwithsoftwaredefinednetworking[J].IEEECommunicationsMagazine,2013,51(2):114-119.

[12]LaraA,KolasaniA,RamamurthyB.SimplifyingnetworkmanagementusingsoftwaredefinednetworkingandOpenFlow[C]//IEEE.ProceedingsofIEEEInternationalConferenceonAdvancedNetworksandTelecommuncationsSystems(ANTS′12).Bangalore:IEEE,2012:24-29.

[13]JarschelM,OechsnerS,SchlosserD,etal.ModelingandperformanceevaluationofanOpenFlowarchitecture[C]//IEEE.Proceedingsofthe23rdInternationalTeletrafficCongress(ITC′11).SanFrancisco:IEEE,2011:1-7.

[14]KanagaveluR,MingjieLN,AungKMM,etal.OpenFlowbasedcontrolforre-routingwithdifferentiatedflowsindatacenternetworks[C]//IEEE.Proceedingsofthe17thIEEEInternationalConferenceonNetworks(ICON).Singapore:IEEE,2012:228-233.

[15]KanagaveluR,LeeB,MiguelRF,etal.Softwaredefinednetworkbasedadaptiveroutingfordatareplicationindatacenters[C]//IEEE.ProceedingsofIEEEInternationalConferenceonNetworks(ICON).Singapore:IEEE,2013:1-6.

[16]MininetTeam.Mininet[EB/OL].[2016-01-04].http://mininet.org.

[17]ProjectFloodlight.Floodlightcontroller[EB/OL].[2015-01-02].http://www.projectfloodlight.org/floodlight/.

[18]NLANR/DAST.Iperf[EB/OL].[2015-04-20].https://iperf.fr/.

數(shù)據(jù)中心間網(wǎng)絡(luò)中保證帶寬的基于OpenFlow路徑規(guī)劃

唐菀，劉果，楊喜敏，陳凡

(中南民族大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院，武漢 430074)

摘要為了實(shí)時(shí)滿足依托于數(shù)據(jù)中心間網(wǎng)絡(luò)(IDN)的云服務(wù)在不同時(shí)間尺度的不同帶寬需求，提出了一個(gè)基于OpenFlow的保證帶寬路徑規(guī)劃(OPPBG)策略. 當(dāng)一個(gè)流到達(dá)時(shí)，OPPBG采集實(shí)時(shí)網(wǎng)絡(luò)鏈路狀態(tài)，生成一個(gè)滿足帶寬需求的虛擬拓?fù)?，并通過基于OpenFlow的軟件定義網(wǎng)絡(luò)(SDN)平臺(tái)為該流規(guī)劃出一條優(yōu)化路徑. 仿真結(jié)果表明：與采用傳統(tǒng)路徑規(guī)劃策略的IDN相比，基于OPPBG的IDN能夠在保證帶寬的同時(shí)，實(shí)現(xiàn)低丟包率和較高的帶寬利用率.

關(guān)鍵詞軟件定義網(wǎng)絡(luò)；數(shù)據(jù)中心網(wǎng)絡(luò)；路徑規(guī)劃；帶寬保證

收稿日期2016-02-13

作者簡介唐菀 (1974-)，女，副教授，博士，研究方向：光/無線網(wǎng)絡(luò)協(xié)議、軟件定義網(wǎng)絡(luò)、網(wǎng)絡(luò)安全，E-mail:tangwan@scuec.edu.cn

基金項(xiàng)目國家自然科學(xué) 項(xiàng)目(61103248)

中圖分類號(hào)TP393

文獻(xiàn)標(biāo)識(shí)碼A

文章編號(hào)1672-4321(2016)02-0128-07