<%BANNER%>

Simulation and Evaluation of PAP: A New Routing Architecture for Differentiated Services Domains Handling 'Expedite Forw...


PAGE 1

SIMULATIONANDEVALUATIONOFPAP:ANEWROUTING ARCHITECTUREFORDIFFERENTIATEDSERVICESDOMAINSHANDLING "EXPEDITEFORWARDING"TRAFFICCLASS By HRISHIKESHNULKAR ATHESISPRESENTEDTOTHEGRADUATESCHOOL OFTHEUNIVERSITYOFFLORIDAINPARTIALFULFILLMENT OFTHEREQUIREMENTSFORTHEDEGREEOF MASTEROFSCIENCE UNIVERSITYOFFLORIDA 2004

PAGE 2

Copyright2004 by HRISHIKESHNULKAR

PAGE 3

ACKNOWLEDGMENTS IwouldliketoacknowledgethesupervisionofDr.ShigangChen andhis extremelyhelpfulguidancethroughoutthiswork.Iwouldal soliketothankDr. RichardNewmanandDr.YeXiaforservingonmysupervisorycommitt eeand reviewingmywork. Iwouldliketothankallmyfriendswhohavehelpedmedirectl yorindirectly inthiswork. Finally,Iamgratefulandindebtedtomyparentswhohavehel pedmebecome whatIamtoday,atthisstageofmylife. iii

PAGE 4

TABLEOFCONTENTS page ACKNOWLEDGMENTS .............................iii LISTOFTABLES .................................vi LISTOFFIGURES ................................vii ABSTRACT ....................................ix CHAPTER1INTRODUCTION ..............................1 1.1QoSTechnologies ...........................1 1.2TheNewRoutingArchitecture(PAP) ................2 1.2.1TheProtocol ..........................2 1.2.2TheSimulation ........................3 1.3OrganizationofThesis ........................3 2QOSROUTINGANDDIFFERENTIATEDSERVICESNETWORKS .4 2.1QoSRoutingOverview ........................4 2.2OverviewofDierentiatedServices .................5 2.2.1TypesofDiServRouters ...................6 2.2.2DiServRouterArchitecture .................8 2.2.3DiservPer-HopBehaviors ..................8 2.3Summary ...............................10 3PAP:AROUTINGPROTOCOLFORDIFFSERVDOMAINS .....12 3.1Overview ................................12 3.2TRTandQRT ............................13 3.3AdmissionControl ..........................15 3.4QoSRouting ..............................16 3.5Summary ...............................20 4SIMULATION ................................21 4.1Overview ................................21 4.2NetworkTopologyGenerationMethods ...............22 4.2.1Metrics .............................23 4.2.2RandomTopologyGenerators ................23 iv

PAGE 5

4.3Simulation ...............................25 4.3.1NetworkModel ........................25 4.3.2TheGraphicalUserInterface ................26 4.4PathGenerationbyShortestPathRouting{Example1 ......35 4.4.1InputParameters .......................35 4.4.2SelectingSourceandDestination ...............37 4.4.3SPRSuccessful .........................37 4.5PathGenerationbyPAPRoutingProtocol{Example1 ......39 4.5.1InputParameters .......................39 4.5.2SelectingtheSourceandDestination ............39 4.5.3PAPSuccessful ........................39 4.6PathGenerationbyPAPRoutingProtocol{Example2 ......43 4.6.1InputParameters .......................45 4.6.2SelectingtheSourceandDestination ............45 4.6.3PAPSuccessful ........................45 4.7MultipleRequestMultipleTopologySimulation ..........49 4.7.1SimulationSteps ........................49 4.7.2MultipleTopology,MultipleRequestSimulation{Exam ple .51 4.8Summary ...............................54 5CONCLUSIONSANDFUTURESCOPE .................55 5.1Comparison ..............................55 5.1.1LinkSuccessRatio ......................55 5.1.2AverageNumberofRTEntries ................57 5.2Conclusion ...............................59 5.3FutureScope .............................60 REFERENCES ...................................62 BIOGRAPHICALSKETCH ............................64 v

PAGE 6

LISTOFTABLES Table page 4{1DefaultValuesforInputParameters ...................30 4{2DefaultValuesforMultipleTopology,MultipleRequestS imulation Parameters ................................31 4{3ParameterValuesforExampleSPRSimulation .............36 4{4ParameterValuesforExampleSPRSimulationSourceandD estination 37 4{5ParameterValuesforExamplePAPSimulation{Example1 ......39 4{6ParameterValuesforExamplePAPSimulation{Example1 ......40 4{7ParameterValuesforExamplePAPSimulation{Example2 ......45 4{8ParameterValuesforExamplePAPSimulation{Example2 ......45 4{9ParameterValuesforMultipleTopologyMultipleRequest Simulation{ Example .................................52 5{1LinkSuccessRatioValuesforPAPandSPR{UsingWaxman .....56 5{2LinkSuccessRatioValuesforPAPandSPR{UsingInet ........56 5{3AverageRTEntriesValuesforPAP{UsingWaxman ..........58 5{4AverageRTEntriesValuesforPAP{UsingInet .............58 vi

PAGE 7

LISTOFFIGURES Figure page 2{1Thedierentiatedservicesdomainarchitectureshowingth etypesof DiServrouters .............................6 2{2Thedierentiatedservicesdomainarchitectureshowingth etypesof DiServroutersandtheirfunctionsinthedomain. .........7 2{3ThearchitectureofaDiServrouterwithitsinternalcom ponents ..8 3{1TRTandQRT:WhenanEFpacketarrives,theQRTattheincominginterfaceisrstlookedup.Ifthereisamatch,thepacketi s forwardedtothenexthopandTRTisnotchecked;otherwisetheTRTislookedup ............................14 3{2QoSrouting ................................17 4{1AviewoftheGUIimplementedwithallthecomponentwindow s ..27 4{2NetworktopologygeneratedbyWaxmanmethodfor30nodesw ith anaverageout-degreeof3 .......................28 4{3AdensernetworktopologygeneratedbyWaxmanmethodfor3 0nodes withanaverageout-degreeof5 ....................29 4{4Theparameterentrywindowwithdefaultvalues ............30 4{5Thesimulationparameterentrywindowwithdefaultvalue s .....31 4{6Resetparametervaluestodefaultfornewsimulation .........32 4{7Thenodeinformationwindowdisplayingpropertiesofacl ickednode 32 4{8Thelinkinformationwindowdisplayingpropertiesofaspe ciedlink .33 4{9Selectingthesourceanddestinationnodes.Thebandwidthr equirementfortherequestisalsospecied. .................34 4{10AlgorithmforpathgenerationbyPAP/SPR .............35 4{11TheparameterentrywindowfortheexampleSPRpathgene ration .36 4{12SelectingthesourceanddestinationfortheexampleSPRsi mulation .37 vii

PAGE 8

4{13SPRprotocolsuccessful.Theshortestpathgeneratedforthe speciedsourceanddestinationisshowninGREEN.Thetotaldelayisshowninthetextwindowbelow ....................38 4{14Example1:SPRprotocolfails.Greenlineshowspartialsho rtestpath andredshowslinkoffailure ......................40 4{15UsingPAPprotocolforthesametopologywiththesameparameters.TheEFrequesthasthesamebandwidthrequirementforthesamesourceanddestination ......................41 4{16PAPsuccessfullyroutesthesamerequestforwhichSPRfailsat link 31 11.QoSpathisseeninBLUE,startingfromthebranching point(Node31) .............................42 4{17Linkinformationforlink31 11todemonstratewhySPRfailsat thebranchingpoint. ..........................44 4{18Linkinformationforlink31 4todemonstratewhythisalternate pathischosenbyPAP. .........................44 4{19Example2:SPRprotocolfails.Greenlineshowspartialsho rtestpath andredshowslinkoffailure ......................46 4{20Link4 31hasabandwidth6.HenceSPRfailsatthislink .....47 4{21PAPsuccessfullyroutesthesamerequestforwhichSPRfailsat link 4 31.QoSpathisseeninblue,startingfromthebranchingpoint (Node4) .................................48 4{22Link4 39hasabandwidth79.HencePAPchoosesitforthealternatepath. ..............................48 4{23Algorithmforthemultipletopology,multiplerequestsim ulation ...50 4{24Theinputparametersforthemultipletopology,multip lerequestsimulationexample .............................53 4{25Theresultsofthemultipletopology,multiplerequestsim ulationexampleusingWaxman.TheprotocolsarecomparedonthebasisoflinksuccessratioandaveragenumberofRTentries. ........53 4{26Theresultsofthemultipletopology,multiplerequestsim ulationexampleusingINET ...........................54 5{1Admissionratiosperadmittedow ...................57 5{2QRTentriesforPAPperadmittedow .................59 viii

PAGE 9

AbstractofThesisPresentedtotheGraduateSchool oftheUniversityofFloridainPartialFulllmentofthe RequirementsfortheDegreeofMasterofScience SIMULATIONANDEVALUATIONOFPAP:ANEWROUTING ARCHITECTUREFORDIFFERENTIATEDSERVICESDOMAINSHANDLING "EXPEDITEFORWARDING"TRAFFICCLASS By HrishikeshNulkar May2004 Chair:ShigangChenMajorDepartment:ComputerandInformationScienceandEng ineering TheresearchpaperbyDr.ShigangChen etal. proposesanewrouting architecture(PAP)fordierentiatedservicesdomainthatint egratesadmission controlsignalingandtheQoSrouting.Itdiersfromtraditio nalroutinginits abilitytoroutemostexpediteforwarding(EF)tracalongthe shortestpossible pathswhilemakinguseofalternativepathstoabsorbtransient overload.Once anEFdataowisadmitted,itsperformanceisassured.Theoverh eadforstoring alternativepathinformationisminimalsinceonlyonerouti ngentryatabranching pointisneededforeachalternativepath. Thisthesisfocusesonasimulationimplementedtodemonstratet heabove proposedroutingarchitectureandcompareitwiththetradit ionalroutingprotocols.AGUIhasbeendesignedandimplementedtoshowthesimulatio nresults graphicallyonthegeneratedtopologies.Itdisplaysthepath sgeneratedbythenew routingprotocolandbytheshortestpathroutingprotocolfor dierentbandwidth requirements,dierentsourcesanddestinationsandcomparest hemonthebasisof specicparameters. ix

PAGE 10

CHAPTER1 INTRODUCTION Astheeortofconvergingvoiceanddataintoasinglenetworkac celerates,a widerangeofmultimediaapplicationsemerges.Therequirem entfortimelydelivery ofdigitizedaudio-visualinformationraisesnewchallenges forbroadbandnetworks. Itisachallengingproblemtocommitnetworkresourcesinasca lablewayso thatthedelayorthroughputsensitivetracisappropriatelyt reatedastheyare routedthroughthenetwork.DierentsystemfunctionslikeAdmi ssioncontrol, QoSroutingshouldco-operatewitheachothertoachievethis. Admissioncontrol ensuresthatthetotaltracinthenetworkdoesnotoverwhelmt heavailable resources.Traditionalroutingprotocolsmakesurethatthepa cketsgettotheir destinations,whileQoSroutingprotocolsmakesurethattheQo Straciswell spreadondierentpathstoincreasetheutilizationofthenetw ork'scapacity. Packetschedulingandresourcemanagementattheroutersallo wdierentiated treatmentforpacketstreamswithvariedservicerequirement s 1.1 QoSTechnologies QoSsupportroughlyfallsintwobroadcategories:Integrated Services (IntServ)andDierentiatedServices(DiServ).IntServsupp ortsprotocols likeRSVPwheretherequiredresourcesarereservedateveryrou teralongthepath oftracstreamtoguaranteetheperformanceofatracstream.Bu tthishas adrawbackofstoringperstreaminformationateverycorerout erandforeven millionsofsuchstreamgoingthroughandhenceisnotsoscalable DiServsolvesthisproblembypushingthecomplexitytotheedg eofthe network,wherethedatatracisclassiedintodierentservicecl assesbysetting acodepointintheIPheaderofeverypacket.InsidetheDiServ domain,the 1

PAGE 11

2 packetsaretreatedaccordingtotheserviceclassestheybelon gto.Inthisway,the per-streaminformationiseliminatedinsidethedomain.Ther esourcemanagement isconductedatacourselevelbasedonserviceclasses.Inspiteofth is,routing supportforDiServisstillanopenproblem.Althoughthedesigno fDiServ isindependentfromrouting,theroutingfunctionhasasigni cantimpacton theeectivenessofsomeclassesliketheexpediteforwarding(EF ).Therouting functiondirectlyaectstheadmissioncontrol,whichdetermi nesthetracvolume thataDiServnetworkcanaccommodateforeachserviceclass. 1.2 TheNewRoutingArchitecture(PAP) IntheresearchpaperbyDr.Chen etal. [ 2 ],anewroutingarchitecturefor DiServdomainshasbeencomparedtotraditionalroutingpro tocolslikethe shortestpathrouting.Shortestpathroutingisgoodforbesteor ttracbuttoo restrictiveforQoStrac.Beforeatracstreamisdelivered,th esenderorthe receiveractivatestheQoSroutingprotocoltoestablisharou tingpaththathas therequiredresources.Aroutingentryisinsertedateachrout eronthepaththus depositingperstreaminformationateachrouter.Anotheropti onistocarrythe routingpathinthesource-routingIPoptionwhichcausesexce ssiveoverheadon therouters.Thecoreideaofthepaperfocusesonthefactthatt heremightbe severalotherpathsotherthantheshortestpaththatmightsuppo rttherequired QoSwhentheshortestpathcannot. 1.2.1 TheProtocol ThepaperbyDr.Chen etal. [ 2 ],thusproposesanewarchitectureforrouting ofparticularlytheExpediteForwardingtracclassforDiSer vdomains.Itrelies mainlyonthedestination-indexedshortestpathcalledasthep rimarypath.But whentheprimarypathissaturatedandcannotsupportmoretrac withoutQoS degradation,temporaryalternatepathsareestablishedonde mand.Thetracon thesealternatepathswillswitchbacktotheprimarypathwhen everitisagain

PAGE 12

3 abletosupportthetrac.Themajoradvantageofthisarchitec tureisthatno perstreamroutinginformationisneededinnormalcondition sandinoverloaded conditions,alternatepathsareusedtoabsorbtheoverloadedt racandonly oneextraentryisneededatthebranchingpointtostoreanalt ernatepath.The admissioncontrolsignalingisanintegratedcomponentinthen ewarchitectureand theexistingQoSroutingprotocolsndtheirplaceintheDiSer vworld. 1.2.2 TheSimulation AsimulationbasedonasimpleDiServnetworkmodelcandemonstra tethe advantagesdescribedabove.Thisthesisfocusesondeveloping aGUIbasedon thesimulationtomodelthetopologygraphically,selectther equiredsourceand destinationnodesinthenetwork,selectandcomparethetradi tionalshortestpath routingandthenewarchitecture(PAP)basedoncertainbandwi dthrequirements forthousandsofrequestsgenerated.Asimulationhasbeenimpl ementedinC++ todemonstratethenewroutingarchitecture,creatingsevera ltopologiesbythe Waxmanmodel,generatingthousandsofrequestsforeachbysele ctingarandom sourceanddestinationnode,andthencomparingthenewarchit ecturewith thetraditionalroutingprotocols.TheGUIdepictsthiscompa risongraphically displayingpathsforasingleWaxmantopology. 1.3 OrganizationofThesis Thethesisisorganizedasfollows:Chapter2providesanoverv iewofdierentiatedservicesandQoSrouting.Chapter3introducesthep roposedrouting architecture(PAP).ItalsodescribesadmissioncontrolandQoSr outinginthenew architecture.Chapter4describestheimplementationofthi sarchitectureinthe formofasimulation(inC++)andaGUIdevelopedforthissimulat ion(Using MFC[ 14 10 ]).Italsodescribesthecomparisonofthenewarchitectureand the shortestpathroutingbasedonthesimulationresults.Chapter5gi vesconclusions anddiscussesscopeforfurtherresearchinthisarea.

PAGE 13

CHAPTER2 QOSROUTINGANDDIFFERENTIATEDSERVICESNETWORKS 2.1 QoSRoutingOverview Today,networktracishighlydiverseandeachtypeoftrachas unique requirementsintermsofbandwidth,delay,loss,andavailabi lity.TheIPprotocol wasoriginallydesignedtoreliablygetapackettoitsdestina tionwithlessconsiderationtotheamountoftimeitgetsthere.Manyoftheapplic ationssupported overIPrequirelowlatencyandtheend-userqualitymaybesign icantlyaected orinsomecases,theapplicationsimplydoesnotfunctionatall. VoiceOverIP couldbeagoodexampleofanapplicationwhichrequiresthis typeofbehavior (lowandxedamountofdelaywithminimumloss),tofunctionpro perly.The best-eortIPnetworkintroducesavariableandunpredictabl eamountofdelayto thevoicepacketsandalsodropsvoicepacketswhenthenetwor kiscongested.QoS techniquescouldbeappliedtothisbesteortIPnetworktomak eitcapableof supportingVoIPwithacceptable,consistent,andpredictable voicequality[ 9 ]. QoSbasedroutinghasbeenregardedasanessentialmechanismfor providing QoSguaranteedservicesintheInternet[ 15 ].Itsprimaryaimistomanagelimited resourcesofIPnetworkseciently.Itaimstoachievetwokeyg oals: Improvingnetworkresourceutilization, Achievinguser'sQoSsatisfaction. Networksarebuiltbyconcatenatingnetworkdevicessuchasswi tchesandrouters. Theyforwardtracamongthemselvesusinginterfaces.Iftherat eatwhichtrac arrivesataninterfaceexceedstherateatwhichthatinterf acecanforwardtrac tothenextdevice,thencongestionoccurs[ 8 ].Thus,thecapacityofaninterface 4

PAGE 14

5 toforwardtracisafundamentalnetworkresource.QoSmechan ismsworkby allottingthisresourcepreferentiallytocertaintracover othertrac. Inordertodoso,itisrstnecessarytoidentifydierenttrac.Tra c arrivingatnetworkdevicesisseparatedintodistinctowsvia theprocessofpacket classication.Tracfromeachowisthendirectedtoacorrespond ingqueueon theforwardinginterface.Queuesoneachinterfaceareservi cedaccordingtosome algorithm.Thequeue-servicingalgorithmdeterminesthera teatwhichtracfrom eachqueueisforwarded,therebydeterminingtheresourcest hatareallottedto eachqueueandtothecorrespondingows.Thus,inordertoprovid enetworkQoS, itisnecessarytoprovisionorcongurethefollowinginnetwork devices: 1.Classicationinformationbywhichdevicesseparatetracint oows, 2.Queuesandqueueservicingalgorithmsthathandletracfro mtheseparate ows. ThisthesisfocusesononesuchtrachandlingmechanismcalledDi erentiated Services. 2.2 OverviewofDierentiatedServices Thegrowthofbusinessrequirementsandnewapplicationshasse taclearneed forsimplemethodsofprovidingdierentiatedclassesofservice forInternettrac. DierentiatedServicesisamodular,highperformance,incr ementallydeployable andscalableapproachonthewayofdevelopingend-to-endQoS ofInternet[ 5 ].Itis asetoftechnologiesthatallowthenetworkserviceproviders tooerdierentkinds ofservicestodierentcustomersandtheirtracstreams. DiServfollowsthephilosophyofmappingmultipleowsintoaf ewservice levels,sometimesreferredtoasClassofService(CoS).DiServ doesnotdene signalingmechanisms;instead,packetsaremarkedwithaDiServ CodePoint (DSCP),whichprovidesinformationabouttheQoSrequestedf orapacket[ 6 ].The codepointenablesnetworkrouterstohandleIPpacketsdier entlydependingon

PAGE 15

6 Figure2{1:Thedierentiatedservicesdomainarchitecturesh owingthetypesof DiServrouters thecodepointandhencetherelativepriority.DiServcodep ointsarelocatedin the8-bitTypeofService(TOS)eldintheIPheaderinthelowe rorder6bits. DierentiatedServicesisacombinationof 1.MarkingpacketswithaDSCPatboundarynodes;2.UsingtheDSCPtodeterminehowpacketsareforwardedbyinte riornodes; 3.Conditioningpacketsatboundarynodes. 2.2.1 TypesofDiServRouters TherearethreetypesofroutersinaDiServdomain[ 2 ]: 1.EdgeRouters,2.InteriorRouters,3.IngressandEgressRouters. Figure 2{1 showsthethreetypesofroutersintheDierentiatedServices domainarchitecture. Figure 2{2 showsthefunctionsofthethedierenttypesofroutersinthe DierentiatedServicesdomain. Edgerouters.AsshowninFigure 2{2 ,anedgerouterisattheboundaryof aDiServdomain.ItnegotiatesandenforcesaServiceLevelAg reement(SLA) withacustomer.SLAmayconsistofparameterslikemaximumpack etloss,

PAGE 16

7 Figure2{2:Thedierentiatedservicesdomainarchitecturesh owingthetypesof DiServroutersandtheirfunctionsinthedomain. maximumpacketdelay.TheSLAspeciesthetermsandcondition softheservice beingoered.Theedgerouterimplementsshaping,routing,po licing,packet classication,marking,monitoringandotherfunctions. Ingressandegressrouters.Betweentwodomains,therouterfrom whichthe tracleavesadomainiscalledanegressrouter,andtherouter fromwhichtrac entersadomainiscalledaningressrouter.Theseareresponsibl eforensuringthat incomingtracconformstotheSLAbetweenthetwodomains.Thu smostofthe workloadisshiftedontotheedgeroutersandtheinteriorcor eroutersremain simple. Interiorrouters.Theinteriorcorerouteronlyneedstoknow howtohandle afewtracclassesratherthankeepingknowledgeaboutthousand sofindividual tracstreams.Inthisway,per-streaminformationiseliminate dinsidethedomain. Theydonotimplementtracconditioning.Resourcemanagemen tisconducted atacourselevelbasedonserviceclasses.Dierentiatedservicesca nthusalleviate corenetworkandboundaryrouterbottlenecksbybettermana ginghighpriority trac.

PAGE 17

8 Figure2{3:ThearchitectureofaDiServrouterwithitsinte rnalcomponents 2.2.2 DiServRouterArchitecture ADiServrouterconsistsofvecomponentsasshowninFigure 2{3 ,apacket arrivesattheclassierandwillbeclassiedaccordingtothebila teralservicelevel agreement[ 6 ].Theclassierforwardsthepackettothetracconditioner.Th e tracconditionermayincludeameter,amarker,ashaperandad ropper. Meters measurethetemporalpropertiesofthestreamofpacketsselect ed byaclassieragainstatracprolespeciedinaTracconditioningAgreement(TCA. Shapers delaysomeorallofthepacketsinatracstreaminordertoshape thestreamintocompliancewithatracprole. Droppers discardsomeorallofthepacketsinatracstreaminorderto bringthestreamintocompliancewiththetracprole.Thispro cessis knownaspolicingthestream. 2.2.3 DiservPer-HopBehaviors TheserviceofDiServisrealizedbymappingtheDSCPcontaine dintheIP packetheadertoaper-hopBehavior(PHB)ateachnetworknode alongthepathof thepacket.TherearetwoprimaryPHBsdenedforDiServnetwor ks[ 6 ]: 1.ExpediteForwarding2.AssuredForwarding

PAGE 18

9 Expediteforwarding.EFisaservicewithlowloss,lowlatency, lowjitterand guaranteedbandwidth[ 1 ].Ithasthefollowingproperties:peakbitrateonows oronaggregatedows,nobursts,onlywithinthepeakbitrate,an dlowqueuing delay.TheideaistoalwayskeepthetotalEFtracpassingthrou ghanylinkin thenetworkunderalimit,whichissettobesmallerthanthelin kbandwidth. Tracthatexceedsthislimitmustbediscarded.Asimplepriorit yqueueisthen usedtoscheduleEFpacketsbeforepacketsfromotherservicecl asses.IfEFPHB isimplementedbyamechanismthatallowsunlimitedpreempti onofothertrac, theimplementationmustincludesomemeansoftolimitthedama geEFtrac coulddototheothertrac.SincethereceivingrateofEFtrac isalwayssmaller thanthesendingrateateveryrouter,EFtracisguaranteedfo rminimizeddelay andassuredbandwidth.Inordertoprovidethishighservicelev elinpractice,the amountoftracinjectedintotheEFclassneedstobecarefully policed.EFPHB isinchargeforguaranteingaminimumdeparturerateforsome tracandthisrate isindependentoftherestofthetractobeforwardedbythesame routeratthe sametime.Admissioncontrolandroutingareessentialtomakesuret hatEFtrac neverexceedsthelinkbandwidth.ItismostidlysuitedforVoI P. Severaltypesofqueueschedulingmechanismsmaybeemployedt odeliver theforwardingbehaviordescribedaboveandthusimplementt heEFPHB.A simplepriorityqueuewillgivetheappropriatebehaviorasl ongasthereisno higherpriorityqueuethatcouldpreempttheEFformorethan apackettimeat theconguredrate. 1 1 Thiscouldbeaccomplishedbyhavingaratepolicersuchasatok enbucketassociatedwitheachpriorityqueuetoboundhowmuchthequeuec anstarveother trac

PAGE 19

10 ThehostthatsendsoutanEFstreamiscalledthesourcehost.Theed ge routerthatthesourcehostconnectstoiscalledthesourcerout er.Thehostthat receivestheEFtracstreamiscalledthedestinationhost.Thee dgerouterthat thedestinationhostconnectstoiscalledthedestinationrout er.AnEFtrac streamisaone-waytracstream.TwoEFstreamsinoppositedirect ionsmodel two-waytrac.Two-waytracisadmittedintothenetworkonly afteritstwo EFstreamsarebothacceptedbytheadmissioncontrol[ 2 ].Inthepaperandthis implementation,onlyasingleEFtracstreamhasbeenconsidere d. Assuredforwarding.AFdoesnotprovidebandwidthguaranteebut packets aregivenahigherpriority.Itismainlyusedfordelayinsensit ivetrac.TheAF PHBgroupdenesthedroppingprecedenceamongdierentclasseso fAStrac whennetworkcongestionoccurs[ 6 ].Queuemanagementismoreessentialtothe implementationofAFservice. 2.3 Summary ThechapterdescribestheneedforQoSroutingtoroutedelayse nsitive tracthroughthenetworkwithguaranteedbandwidthandmini mumdelay. DierentiatedServicesisonesuchtrachandlingmechanismtha tdoesprovidethe classicationofnetworktracandprovidesQoSguaranteeforea chclassaccording toitsrequirements,bydierentiatingpacketsonthebasisofC odePointsatthe edgerouters.ItscoresoverIntServbyeliminatingperstreami nformationtobe depositedinsidethedomainandthusmakinginteriorrouterssi mple. ExpediteForwardingserviceisthefocusofthisthesissinceit provides guaranteedQoSifadmissioncontrolandroutingareproperlyd one.ClearlyEF trachasdistinctivecharacterizationfromAFtrac.Hencethen ewrouting architecturedescribedinthepaperbyDr.Chen etal. [ 2 ]anditsimplementation inthisthesisisconcernedmainlyforEFtracbecauseoftheimp ortantrolethat

PAGE 20

11 routingandadmissioncontrolplaysinecientworkingofEFPHB. Thenext chapterwilldiscussthenewroutingarchitectureforDiServd omains.

PAGE 21

CHAPTER3 PAP:AROUTINGPROTOCOLFORDIFFSERVDOMAINS Thischapterdiscussesanewroutingprotocolthatcanbeusedwit hthe proposedroutingarchitectureforDierentiatedServicesdo mains[ 2 ]. 3.1 Overview Expediteforwardingtraccanberoutedbythetraditionalro utingtable (TRT)asisdoneinthecasebest-eorttrac.Thetraditionalrou tingtables provideasinglepathbetweeneachpairofnodes.Ifthepathiso verloadedbythe EFtrac,theTRTapproachlackstheexibilityofusingalterna tepaths. Asproposedintheresearchpaper,thenewroutingarchitecture primarily usesTRTtoroutetheEFtracbutreliesonalternatepathstoha ndlethe overloadcondition.ThealternatepathsarestoredintheQoS routingtables(QRT) whichareconstructedondemandbytheQoSroutingprotocols.T heQoSrouting protocolsareinvokedonlywhentheEFtracoverloadsthepri maryroutingpath. Undernormalconditionswhenthenetworkisnotoverloaded,t hesystemwillnot seetheexistenceoftheQoSroutingprotocols. WhenanEFstreamarrives,thesourcehostissuesarequesttothesourc e router.Thesourcerouterinitiatestheadmissioncontrolsigna lingbetweenthe sourcerouterandthedestinationrouter.AREQUESTmessageissent towards thedestinationroutertocheckthebandwidthavailabilitya longthepath.Inthe proposedroutingarchitecture,allcontrolmessagesandnon-E Fdatapacketsare routedalongtheprimarypathsbyTRTinthesamewaythecurren tIPnetworks routepackets. AsarouterontheprimarypathreceivestheREQUEST,itperform sa simpleacceptancetesttocheckifithasenoughbandwidthfort heEFtrac. 12

PAGE 22

13 Ifitdoes,theREQUESTisforwardedtothenexthopontheprimar ypath.If theacceptancetestsofallintermediateroutersarepassedand theREQUEST successfullyarrivesatthedestinationrouter,itmeansthatth eprimarypathcan supportthenewEFtrac.ThedestinationroutersendsanACCEPTm essage tothesourcerouter,whichinturnnotiesthesourcehosttostart sendingdata packets.ThedatapacketswillberoutedbyTRTsandfollowthe primarypathto thedestinationhost. Ontheotherhand,iftheacceptancetestfailsatanintermedi aterouter,which meanstheprimarypathcannotsupportthetrac,thenaQoSrout ingprotocolis triggeredtondanalternativepath.Ifanalternativepatht hatsupportsthetrac isfound,anACCEPTmessageissenttothesourcerouterandthedat apackets oftheEFstreamwillfollowthealternativepath.Ifanaltern ativepathcannotbe found,aREJECTmessageissenttothesourcerouter,whichwillei therrejectthe EFtracorretrytheadmissioncontrolatalatertime. ThealternativepathsarestoredinQRTs.Inordertokeepthesiz eofthe QRTssmall,tracusinganalternativepathmergesbacktothepr imarypath whenthereissucientbandwidthfreedupontheprimarypath.T hedierence betweentheTraditionalroutingtableandQoSroutingtable isdiscussed,noting howdatapacketsareforwardedbytheseroutingtables. 3.2 TRTandQRT EachrouterhasoneTRTmaintainedbythetraditionalroutin gprotocolssuch asRIP,OSPF,IGRP,and/orBGP.Inaddition,ithasaQRTforea chnetwork interface.TheQRTsaremaintainedbytheQoSroutingprotoc ols.Thereason tousemultipleQRTsinsteadofonefortheentirerouteristore ducethesizeof eachQRT.Itisclearthateachincomingpacketwillbematche dagainstoneQRT, smallertablesizeresultsinfasterprocessing.

PAGE 23

14 look up QRT at the interface outgoing incominginterface QoS routing protocols traditional routing protocols update periodicallyor upon triggering packet frame no match match match packet frame update upon triggering incoming interface look up TRT Figure3{1:TRTandQRT:WhenanEFpacketarrives,theQRTatth eincoming interfaceisrstlookedup.Ifthereisamatch,thepacketisfo rwarded tothenexthopandTRTisnotchecked;otherwisetheTRTislook ed up TRTisindexedbydestinationIPaddresses.EachTRTtableentryc onsists ofadestinationIPaddress,anext-hopIPaddress,andotherinfor mation.The outgoinginterfacetowhichapacketisforwardedcanbedete rminedfromthenexthopIPaddress.QRTisindexedbyEFtracidentiers.AnEFtraciden tier iscomposedofasourceIPaddress,adestinationIPaddress,aprotoc olidentier, asourceportnumber,andadestinationportnumber.EachQRTta bleentry consistsofanEFtracidentier,anext-hopIPaddress,andotheri nformation.In thisarchitecturetheroutemapneedstobedynamicallyupda tedbyQoSrouting protocolsinordertosupportEF. Forallnon-EFpackets,onlyTRTislookeduptondthenexthop, whichis exactlywhatthecurrentIPnetworksdo.Figure 3{1 illustrateshowanEFpacket isforwardedatarouter.Afterthepacketarrivesattheincom inginterface,the QRTatthatinterfaceislookedup.Ifthereisamatchedtable entry,thepacket bypassesTRTandproceedsdirectlytotheoutgoinginterfacew hichsendsthe packettothenexthop.IfthereisnotamatchintheQRT,theTR Tislookedup andthedefaultshortest-pathisused. ThemainobjectiveistominimizethesizeoftheQRT.Mostofthe EFtrac iskeptontheprimarypath.Ifthenetworkisinnormalcondit ionswithoutany

PAGE 24

15 congestion,allEFtracwilltravelalongtheprimarypathand thesizeofQRT willbezero.Inthiscase,onlyTRTislookedupforallpackets. Ontheother hand,whentheaggregatedEFtraconaprimarypathreachesth emaximum allowedquotaforEFtrac,aQoSroutingprotocolwillbetrig geredtond alternativepathsfornewEFstreams.Newtableentriesareinser tedintoQRTfor thedurationofthetracstreams.Itshouldbestressedthatonlythe overload portionoftheEFtracisroutedviaQRTalongthealternative paths,andthis portionofthetracwillswitchbacktotheprimarypathwhenev erpossible. 3.3 AdmissionControl ThetaskofadmissioncontrolistodeterminewhetheranewEFtra cshould beacceptedintothenetworkorrejected.Inourroutingarch itecture,theadmission controlandtheQoSroutingiscloselyrelated.Infact,ifthe admissioncontrol functionndsoutthattheprimarypathdoesnotsupportthenew trac,itwill triggertheQoSroutingfunctiontondanalternativepath.I ftheQoSrouting functionndssuchapath,theadmissioncontrolacceptsthetrac ,otherwise,it rejectsthetrac. AdmissioncontrolisdoneonlyfortheEFtrac,whichreceivesassu red bandwidthandfastforwardingunderourroutingarchitectur e.Thesignaling processstartsfromthesourcerouterandfollowstheprimarypa thtowardsthe destinationrouter.Thesignalingmessage,REQUEST,carries: Thetracidentier(sourceIPaddress,destinationIPaddress,prot ocol identier,sourceport,anddestinationport), Theserviceclassidentier(EF), Thebandwidthrequirement B Inordertoassisttheadmissioncontrol,eachrouterkeepstracko fitsresource availability.Twovariablesaremaintainedforeachoutgoi nginterface: EF max : EF max isthemaximumsustainablebandwidthallowedtobeusedfor sendingEFtracfromthisinterface

PAGE 25

16 EF agg : EF agg istheaggregatedbandwidthcurrentlyusedbyallEFtracon thisinterface. EF max issetatthecongurationtime,while EF agg ismeasuredatruntime. WhenarouterreceivesaREQUEST,itusesTRTtondtheoutgoingi nterfaceto thenexthopontheprimarypath.Asimpleacceptancetestisper formedatthe outgoinginterfacetoseeifthereisenoughbandwidthforthe newtrac. If B EF max ¡ B agg theREQUESTissenttothenexthop. If B>EF max ¡ B agg thetraccannotbeadmittedbyusingthisoutgoinginterface. AQoSrouting protocolistriggeredtondanalternativeroutingpath.Ifa nalternativepath isnotfound,aREJECTmessageissenttothesourcerouterthatrej ectsthe tracorretriestheadmissioncontrolaftercertaindelay.Ont heotherhand,if theREQUESTsuccessfullyarrivesatthedestinationrouterorthe QoSrouting protocolndsanalternativepath,anACCEPTmessagewillbesent tothesource router.Thesourcerouterwillnotifythesourcehosttosenddata trac. 3.4 QoSRouting IftheprimarypathhasthebandwidthtosupportthenewEFtrac stream, theQoSroutingprotocolisnottriggeredbytheadmissioncont rol.Alldata packetswillfollowtheprimarypathsdirectedbyTRTbecause thereisnomatched tableentryinQRT.Undercongestionconditions,however,anin termediaterouter maynothavetherequiredbandwidth.AsshowninFigure 3{2 (b),suppose i fails theacceptancetestattheoutgoinginterfaceconnectingto j .Thecorresponding link( i;j )iscalledaninfeasiblelink,whichisrepresentedbyadotted line.Alink thatpassestheacceptancetestiscalledafeasiblelink.Theadm issioncontrol signalingcannotproceedalonglink( i;j ),andaQoSroutingprotocolisactivated.

PAGE 26

17 d ( b ) ( c ) ( a )s k m ij( e )data data i j s k m i j s k mACKs k mACKij s k m ij( d )ACCEPTACCEPTREQUEST REQUEST ROUTING ROUTING d d d d Figure3{2:QoSrouting Theproposedroutingarchitectureisindependentofanypart icularQoSrouting protocol.Forthepurposeofcompleteness,onlyoneQoSrouting protocolhas beenimplementedinthisthesistoshowhowittsinthearchitec ture.Onebig advantageoftheprotocolisthatitreliesonlyonthelocalst atestoredateach router,whichmakesitscalableandeasytoimplement.Thebasic ideaisas follows:Whenaninfeasiblelinkisencountered,itisconsider edasanindication oflocalcongestion.TheQoSroutingprotocoltriestondanal ternativepathby detouringaroundtheinfeasiblelink.Withouttheknowledge abouttheextentof thecongestion,theprotocolbranchesouttowardsmultipled irectionsandsearches multiplepathsforonethatcansupportthenewEFtrac. InFigure 3{2 (c), i sendsoutROUTINGmessagesalongalladjacentfeasible links. i iscalledthebranchingpoint.Apparently,aROUTINGmessageshoul dnot besenttothelinkfromwhichtheREQUESTwasreceived,anditwi llnotbesent to( i;j ),whichisaninfeasiblelink.AROUTINGmessagecarriestwoIPadd resses: bpAddr,whichistheaddressofthebranchingpoint,andnbAddr, whichisthe addressoftheneighborthatreceivesthemessage.Italsoaccumu latesthedelayof thepathittraverses. AfteraROUTINGmessagesarriveattheneighbornode k (or m ),itisrouted byTRTsfromthereon.Hence,theROUTINGmessagefollowstheprima rypaths

PAGE 27

18 from k (or m )tothedestinationrouter.Thishasaveryimportantimplica tion: inordertostoreanalternativepath,itissucienttoaddasingl etableentry intheQRTat i todirecttracto k (or m ).From k (or m )on,TRTswillbe used.SimilartoREQUEST,aROUTINGmessagecausesanacceptancetest tobe performedateveryrouterittraverses. TheROUTINGmessageissenttothenexthoponlyiftheacceptancete stis passed.Therefore,iftheROUTINGmessagesuccessfullyreachesthede stination router,analternativepathforthenewEFtracisfound,thep aththatthe messagehasjusttraversedis.Inthiscase,anACKissentbacktotheb ranching point i ,whoseIPaddressis bpAddr thatwascarriedintheROUTINGmessage. TheACKcopies nbAddr andtheaccumulatedpathdelayfromtheROUTING message.UponreceiptoftheACK, i insertsatableentryintheQRTatthe incominginterfacefromwhichtheREQUESTwasreceived.Then exthopinthe entryissettobe nbAddr .Alsostoredintheentryisthedelaycarriedbackby ACK,whichisthetotalexpecteddelayforEFtraconthealter nativepath.In addition, i sendsanACCEPTmessagetothesourceroutertoadmitthetrac. AsFigure 3{2 (d)shows,thesourcerouterwillnotifythesourcehost.As showninFigure 3{2 (e),thedatapacketsfollowtheprimarypathuntilitreache s thebranchingpoint i ,wheretheQRTattheincominginterfacedirectsthepackets awayfromtheprimarypath.Oncethepacketsreachtheneighb orrouter k theyareagainroutedbyTRTs.IfmultipleROUTINGmessagesarrive atthe destinationrouter,thenmultiplealternativepathsarefou ndandmultipleACKs aresentbacktothebranchingpoint.Whenthebranchingpoint receivesanACK andndsthatthereisalreadyatableentryintheQRTfortheEF tracstream, itchecksifthedelayintheACKissmallerthanthedelayinthe entry.Ifitis

PAGE 28

19 smaller,thenexthopintheentryisreplacedbythe nbAddr valueintheACK. Therefore,thebestfoundalternativepathwillbeused. 1 WhenarouterreceivesaROUTINGmessage,iftheacceptancetestfa ils, itsendsaNACKmessagebacktothebranchingpoint.Ifthebranchi ngpoint receivesaNACKfromeveryACKsentout,itconcludesthattheQo Srouting protocolfailsinndinganalternativepath.AREJECTmessagei ssentbackto thesourcerouter,indicatingthatthetraccannotbeadmitte datthismoment. Theaboveroutingprotocolallowsonlyonebranchingpointt odeviatefrom theprimarypath.Moresophisticateddesignmayallowmultiple branchingpoints. WhenaROUTINGmessagereachesarouterthatfailstheacceptance test,the routercanbranchagainandsendROUTINGmessagestotheneighbors otherthan theonepointedbyTRT.Insuchadesign,everybranchingpointn eedsatable entryinQRTinordertostorethealternativepath Inordertocancelthealternativepathandswitchbacktothep rimarypath wheneverpossible,thebranchingpointperiodicallysendsCHEC Kmessages downtheprimarypathtoseeiftheprimarypathcannowsupportt heEFtrac stream.Itisamini-versionofadmissioncontrol.IftheCHECKmessa gepassesthe acceptancetestatallintermediateroutersandsuccessfullyre achesthedestination router,thesourcerouterwillbeinstructedtonotsendKEEPALIVE .TheEF tracwillautomaticallyfollowtheprimarypathwhenthealt ernativepathtimes out. 1 AnACKforanalternativepathwithsmallerEFdelaymayarrivel aterbecausethecontrolmessagesarenotEFtracandhencemayexperien ceadierent delay

PAGE 29

20 3.5 Summary ThechapterdescribesthenewPAProutingarchitectureforDiS ervdomains indetail.ThePAPQoSprotocolcanbeusedtondalternaterouti ngpathsfor ExpediteForwardingtracstreamswhentheprimaryroutingpr otocolfailsat abranchingpoint.SupportforadmissioncontrolandQoSrouti nghasalsobeen integratedinthenewarchitecturetorouteExpediteForwar dingtracclasswith guaranteedbandwidthandminimumdelay. Thenextchapterdescribesasimulationthathasbeenimplemen tedto demonstratetheadvantageoftheaboveproposedroutingproto colinusewiththe DiServdomains.ItcomparesthenewprotocolPAPwiththetradi tionalrouting protocolsliketheshortestpathroutingwithrespecttotheadm issionratio(number ofrequeststhatareadmitted)andalsoconsiderstheperforman ceaecteddue tothenumberofRTentriesdepositedperadmittedowonaverag e.AGUIhas alsobeendescribedwhichwilldisplaygraphically,thenetwor ktopology,source anddestinationnodesselectedandthepathsasgeneratedbyth etwocompared protocols.Italsoshowsthebranchingpointincasewhentheacce ptancetestfails atacertainnodealongtheshortestpathanddisplaystheQoSpat h(asgenerated bythenewQoSprotocol)fromthebranchingpointtothedestin ationnode.

PAGE 30

CHAPTER4 SIMULATION ThischapterdescribesthesimulationandtheGUIthathasbeeni mplemented todemonstratetheadvantageofthePAPQoSroutingprotocolin thenewrouting hierarchyforthedierentiatedservicesdomains. 4.1 Overview Thesimulationgeneratesanumberofnetworktopologiesbased onthe Power-Lawmodel.Eachlinkisassignedrandomlyalinksuccesspr obability.It istheprobabilityofthelinkthatitwillpasstheacceptance test.Alargelink successprobabilitycorrespondstoalightloadconditionthus increasingthe probabilitythattheparticularlinkwillbeabletoforward thetracstream. Alowlinksuccessprobabilityontheotherhandcorrespondstoa heavyload condition[ 2 ].Thenetworktopologycanbegeneratedusingeitherthe Inet orthe Waxman topologymodel,whicharedescribedlaterinthischapter.Fo reachof thetopologiesgenerated,severalthousandrequestsaregener atedwhicharerouted fromaspecicsourcetodestination.Thesourceanddestinationar eselectedat randomorcanbeinputimplicitlyasaparameter.Forthispar ticularsetofsource anddestinationnodes,thenewroutingprotocolPAPiscompared withtheshortest pathroutingprotocol.Thebasisofcomparisonforthetwoprot ocolsis: Admissionratio (percentageofrequeststhatareadmitted) AverageRTentries depositedperadmittedow(forPAP). TheGUIthathasbeenimplementedusesthesamesimulationdesign, butoers severalfacilitieswithrespecttogenerationofthetopology byallowingcongurationofitsparameterslikethenumberofnodes,typeoftopolo gygenerator,the 21

PAGE 31

22 outdegreeexponentvalueforWaxmanmodel,minimumandmaxi mumlinkdelay, minimumandmaximumlinkbandwidth.Itgeneratesasinglereq uestforaspecic sourceanddestinationnodethatcanbeselectedbytheuser.Itth endisplays thepathasgeneratedbytheshortestpathroutingprotocol.If atcertainpoint alongtheshortestpath,theacceptancetestfails,thentheQoSr outingprotocolis triggeredandtheremainingQoSpathfromthebranchingpoin ttothedestination isalsodisplayed.Ifthebandwidthrequirementsaresuchthatt heexistinglinksare notabletosupportthetracrequest,thentheroutingfailsand thepathonlyup tothebranchingpointisshown.Italsodisplaysthecomparisonr esultsofthetwo protocols.Thesimulationisthusmodelledintwoparts. 1.GenerateasinglenetworktopologybyusingtheWaxmantopol ogygenerationmethod,specifythesourceanddestinationforwhichthepa thistobe found,specifyasinglerequestwiththebandwidthrequirement forthetrac andselecttheprotocoltobeused. 2.GenerateseveralnetworktopologiesbasedeitherontheIne tmodelorthe Waxmanmodel.Specifythenumberofrequeststobegenerateda longwith theminandmaxbandwidthanddelayvalues.Thesourceanddestin ationare takenatrandomforeachrequest. Thecomparisonresultsforthesecondsimulationpartareshownin termsofthe factorsstatedabove. Abriefoverviewoftopologygeneratorsandthepower-lawmo delhasbeen providedtogetabriefknowledgeoftopologygenerationmet hodsusedinthe implementationandhowthelinksuccessprobabilitiesareassig nedtothenodesin thenetwork. 4.2 NetworkTopologyGenerationMethods Theinternetcanbedecomposedintoconnectedsubnetworkstha tareunder separateadministrativeauthorities.Thesesubnetworksarecal ledasdomainsor autonomoussystems.Thisway,thetopologyoftheInternetcanb estudiedattwo levelsofgranularities.Attherouterlevel,eachrouterisr epresentedbyanode

PAGE 32

23 andeachlinkbetweentheroutersbyanedge.Attheinter-dom ainlevel,anode representseachdomainandeachedgeisaninter-domainconne ction.Protocols aredevelopedforbothinter-domainandintra-domaincommu nication.Network protocolsaredesignedtobeindependentoftheunderlyingne tworktopology. Whiletopologyshouldnothaveaneectonthecorrectnessofthe protocol,it doeshaveamajorimpactontheperformanceofthenetworkpro tocols[ 11 ].Hence topologygeneratorsareusedoftentogeneraterealistictopo logiesinsimulations. Thesetopologygeneratorsdonotaspiretoproducetheexactre plicasofthe current Internet ,buttheymerelyattempttocreatenetworktopologiesthat embodythefundamentalcharacteristicsofrealnetworks[ 12 ].Therearemainly threecategoriesoftopologygenerators[ 11 ]: 1.Random,2.Degreebased,3.Structure(hierarchical)based. 4.2.1 Metrics Themetricsthathavebeenusedtodescribegraphsaremainlyth e nodeout ¡ degree andthedistancebetweenthenodes.Givenagraph,theout-degr eeof anodeisdenedasthenumberofedgesincidentonthatnode.Th edistance betweentwonodesisthenumberofedgesoftheshortestpathbet weenthenodes. 4.2.2 RandomTopologyGenerators Theprocessofgeneratingrandomtopologiescanbegenerally statedasfollows: Givenaninputof N nodesanda2-dimensionalplaneofsize n by m ,rstthe placementofthenodesistobedecided[ 3 ].Thenodescanbedistributeduniformly acrosstheplane,orclusteredaroundsomeregion.Theoutdegre eforeachnode isthendecided,whichisthenumberofnodesthatitisconnec tedto.Afterthe nodesarepositionedandtheiroutdegreehasbeendecidedupo n,thelinksare tobeidentiedtodecidewhichnodesshouldbelinkedtowhicho thernodes.

PAGE 33

24 Theprobabilityofcreatinganedge( link )betweentwonodescanbeuniformly distributedorweightedbytheEuclideandistancebetweenthe m.Theedgesare thenaddedtothenetworkuntilallthenodeshavetheirout-d egreessatised. Aminimumspanningtreecanbebuiltpriortothegenerationof otheredgesto ensurethatthegraphisaconnectedgraph.Ifthegraphisdisco nnectedthenextra edgescanbeaddedtonodesatrandomtoensurethatthegraphis connected. Waxmanmodel.Waxmanintroducedoneofthemostpopularnetwo rkmodels. Waxmantopologygeneratorisarandomgraphtopologygenera tor.Thegenerator producesrandomgraphsbasedontheErdos-Renyirandomgraphm odel,butit includesnetworkspeciccharacteristicssuchasplacingtheno desonaplaneand usingaprobabilityfunctiontointerconnecttwonodes,which isparameterized,by thedistancethatseparatesthemintheplane.TheWaxmantopol ogygenerator usestheEuclideandistancebetweenthenodestogoverntheirc onnectivity.It startsbyplacingthenodesina nxn plane.Oncethenodeshavebeenplaced,it calculatestheprobabilityofcreatinganedgebetweentwon odes u and v usingthe followingprobabilityfunction: P ( u;v )= e ( ¡ d ( u;v ) L ) whereP ( u;v )istheprobabilityoflinkingnodes u and v d ( u;v )istheEuclideandistancebetween u and v L istheEuclideandiameterofthenetwork 1 istheaverageoutdegree determinestheaverageedgelength 1 EuclideandiameteristhemaximumEuclideandistancebetwee nanytwonodes inthegraph

PAGE 34

25 Thenarandomnumberisgeneratedbetween0and1.Anedgeiscre ated betweennodes u and v onlyiftherandomnumberissmallerthan P ( u;v )which iscalculatedasabove.Finally,aspanningtreecanbeconnec tedtoensurethat theresultantgraphisconnected.TheuseofEuclideandistance nowmakes thegeographicdistributionofnodesafactorinthetopology .ThusWaxmanis concernedonlywithrandomlygeneratednetworks.Waxmanhas beenusedinthis simulationGUItogeneratesuchrandomnetworktopologieswith severalnodesto demonstratethenewroutingarchitecture. Inetmodel.TheInetmodelgeneratesatopologybyplacing N nodesonan nxn plane[ 3 ].EachnodeisassignedandoutdegreebasedonPowerLaw2.Thena fullmeshisusedtoconnectthetop mostconnectednodes.Forthesenodes,25% oftheiredgesareconnectedrandomlyselectednodeswithout degree2.Tocreatea fullyconnectedtopology,theremainingnodesareeitherco nnectedtooneofthese nodesorconnectedtoanodethatcanreachoneofthese nodes.TheInet-1.0 modelhasasecondphasewherethetopmostconnectednodesareex pandedinto networkswith nodeseach.Thisphaseisusedtoexpandthetopmostconnected autonomoussystemsintonetworkswithrouter-levelconnecti vity. 4.3 Simulation 4.3.1 NetworkModel Thenetworkmodelusedinthesimulationisdescribedbelow:Thesimulationgeneratesarandomnetworktopologybasedonth einput parametersgiven.Therstpartofthesimulationinwhichthepa ths(shortestpath and/orQoSpath)aregraphicallydisplayed,asingletopology isgeneratedusing theWaxmantopologygenerationmethodandasinglerequestisc onsidered.In thesecondpartwherethesimulationisrunwithseveraltopolog iesandseveral thousandrequests,topologyisgeneratedusingeithertheWaxma northeInet topologygenerationmethod.

PAGE 35

26 Thesimulationtakesasinputthefollowingparameterstomod elthenetwork topology: Numberofnodes Numberofrequests Numberoftopologies 2 Topologygenerationtype(Waxman/Inet) MinimumandMaximumbandwidth MinimumandMaximumdelay ForWaxman:theaverageoutdegree Arandomnumberseedwhichwillaecttheassignmentoflinksinth e Waxmanmodel Theinputparametersforaspecictopologycanbesavedtoalean d latertheparameterscouldbereadfromtheleinordertore-g eneratethesame topology. 4.3.2 TheGraphicalUserInterface AviewoftheGUIthathasbeenimplementedtodemonstratethene wrouting architectureisshowninFigure 4{1 Themainpartsoftheuserinterfacecanbestatedas 1.Themaindisplaywindow-Thetopologygeneratedaccording tothegiven parametersisdisplayedinthemainwindow. 2.ParameterEntry-Theinputparametersstatedaboveforthe topology generationareenteredhere 3.Multipletopologysimulationparametersareenteredbelo walongwiththe choiceoftopologytype(Waxman/inet)andthenumberofrequ ests 4.Atextwindowwhichdisplaystheresultsofthesimulation5.Thenodeinformationwindowwhichgivesthepropertiesof aselectednode 2 Fortherstpartofthesimulation,thenumberoftopologies=1a ndnumber ofrequests=1

PAGE 36

27 Figure4{1:AviewoftheGUIimplementedwithallthecomponen twindows

PAGE 37

28 Figure4{2:NetworktopologygeneratedbyWaxmanmethodfor3 0nodeswithan averageout-degreeof3 6.Thelinkinformationwindowwhichgivesthepropertiesfo raspeciedlink Theindividualpartsoftheuserinterfacearenowdescribedin detail: Topologydisplaywindow.Dependingupontheparametersente redforthe simulation,anetworktopologyisgeneratedusingtheWaxmang enerationmethod. Thenodesareplacedina x ¡ y planecorrespondingtotheblankwhiteareaseen onthedisplaywindow. ThenusingtheWaxmanprobabilityfunction,thelinksarecal culatedandthe nodesalongwiththelinksbetweenthemaredisplayedasshowni nFigure 4{2 Thenodesarerepresentedbybluecirclesandthelinksbetwee nthembygray

PAGE 38

29 Figure4{3:AdensernetworktopologygeneratedbyWaxmanmet hodfor30nodes withanaverageout-degreeof5 lines.Eachnodeisassignedauniqueidentitywithanintegersta rtingfrom0tothe numberofnodes.EachnodealsohasitscorrespondingIDdisplaye dbesidesit. Asstatedpreviously,ahighervalueforthe outdegreevalueforWaxman willgenerateadensernetworktopology.ThiscanbeseeninFig ure 4{3 which showsatopologywithallthesameparametersasinFigure 4{2 butwitha value of5. TheParameterentrywindow.Theinputparametersspeciedabo vewillbe enteredbytheuserintheparameterentrywindowasshowninFig ure 4{4 .The defaultvaluesfortheinputparametersaregiveninthefoll owingtable Thebandwidthvaluesforthelinksinthetopologyareassigned fromtherange MinBandwidth ¡ MaxBandwidth andthedelayvaluesareassignedfromthe range MinDelay ¡ Maxdelay .Theaverageout-degreevalueforWaxmanisgiven

PAGE 39

30 Figure4{4:Theparameterentrywindowwithdefaultvalues Table4{1:DefaultValuesforInputParameters Parameter DefaultValue NumberofNodes 50 RandomNumberseed 333 Alphaout-degree(Waxman) 3 MinimumLinkBandwidth 0 MaximumLinkBandwidth 100 MinimumLinkDelay 0 MaximumLinkDelay 100

PAGE 40

31 Figure4{5:Thesimulationparameterentrywindowwithdefau ltvalues bytheparameteralpha.Ahighervaluefor willresultindensertopologywhile alowervaluewillgiveasparsetopology.Thesevaluesarealsouse dwhenmultiple topology,multiplerequestsimulationisrun. Simulationparameterentrywindow.Figure 4{5 showstheinputboxesforthe parametersrequiredforthemultipletopology,multiplere questsimulation.Ittakes asinputthenumberoftopologiestobegenerated,thenumber ofrequestsandthe choiceofthetopologygenerationmethodtobeused( Waxman=inet ).Theother parametersarethetakenfromtheparameterentrywindowasd escribedabove. Thisgeneratesasimulationwithseveraltopologiesandchoose sasource anddestinationnodeatrandomfromthegeneratedtopologyfo reachrequest. Itgeneratesseveralthousandrequestsasspeciedbytheinputpa rameterfor thatparticularsourceanddestinationandthencomparesther esultsofthenew protocolwiththeshortestpathroutingprotocol,bycalculat ingtheaveragesofthe comparisonparametersforthethousandsofrequests.Thedefaul tvaluesforthe windowaregiveninthefollowingtableTable4{2:DefaultValuesforMultipleTopology,MultipleR equestSimulation Parameters Parameter DefaultValue NumberofRequests 6000 Numberoftopologies 10 TopologyType Waxman

PAGE 41

32 Figure4{6:Resetparametervaluestodefaultfornewsimulati on Figure4{7:Thenodeinformationwindowdisplayingproperti esofaclickednode Afterapathisgeneratedorthesimulationisrun,thevaluesin boththe parameterentrywindowscanberesettothedefaultvaluesgiv eninthetablesby clicking"Reset"fromthe"Simulation"optionontheGUIasshow ninFigure 4{6 TheNodeinformationwindow.Thenodeinformationwindowdisp laysthe followingpropertiesforagivennode: NodeID Numberoflinksforthenode(itsoutdegree) Itsneighbors TheneighborsofthenodearetheIDsofthenodesinthetopolo gytowhichit hasalink.Whenanynodeinthetopologyisclicked,itscorre spondingproperties wouldbedisplayedinthenodeinformationwindow.Thewindow isshownin Figure 4{7 TheLinkinformationwindow.Thelinkinformationwindowac ceptsthestart andendpointsofanodewhicharethenodeIDsofthenodesbetw eenwhichthe

PAGE 42

33 Figure4{8:Thelinkinformationwindowdisplayingproperti esofaspeciedlink linkexists.Giventhe"start"and"end"nodes(IDs)ofalink,clic kingthe"Get LinkInformation"windowwilldisplaythefollowingpropert iesofalink: Bandwidth Delay Thebandwidthforalinkistakenfromtherange MinBandwidth ¡ MaxBandwidth andsimilarlythedelayfromtherange MinDelay ¡ MaxDelay whicharespeciedintheparameterentrywindow.Thisinforma tionisusefulto checkandverifywhetheraparticularlinkcanpasstheaccept ancetestforthe incomingrequest.Theinformationcandemonstratehowthenew protocolchooses analternatepathovertheshortestpathwhentheshortesthopfro mthebranchingpointcannotsupporttherequestedbandwidth.Figure 4{8 showsthelink informationwindow. Selectingthesourceanddestinationnodes.Forthesingletopol ogy,singlerequestsimulation,oncethetopologyhasbeengenerated,thesou rceanddestination forthegeneratedrequestcanbeselectedbyclickingthe"Gene ratePath"button ontheparameterentrywindow. Thefollowingwindowisdisplayedasshowningure 4{9 .Thesourceand destinationnodescanbespeciedalongwiththebandwidthrequ irementforthe

PAGE 43

34 Figure4{9:Selectingthesourceanddestinationnodes.Theban dwidthrequirementfortherequestisalsospecied. requesttoberoutedfromthesourcetothedestination.Therequ estcorresponds toanEFtracstreamtoberoutedfromthesourcetothedestinatio nwiththe speciedbandwidthrequirement.Therequirementstatesthate veryhop(link)on thegeneratedpathfromthesourceuptothedestinationshouldh aveabandwidth greaterthantherequirementspecied,toensureguaranteedde liveryofthethe EFtracstream.Thelinkthathasabandwidthlessthanthespecie drequired bandwidthfortherequestcannotbeusedonthepath.Theprotoc oltobeusedfor theroutingcanbechosenhere. If ShortestPathRouting protocolischosen,thenifanyofthelinksinthe shortestpathcalculatedbytheprotocol,doesnotpasstheacce ptancetest, thentheprotocolfailsandthepartialpathfromthesourceto thenodeof failureisshown.Thelinkatwhichthetestfailsisalsohighlig hted.Thislink iscalledasan InfeasibleLink asstatedinthePAPprotocoldescriptionin chapter3.Anexamplelaterinthischapterwilldemonstratesuc hacase. Ifthenew PAP QoSprotocolischosen,itstartsofwithcalculatingthe shortestpathbetweenthesourceanddestinationnodes.Butifany linkalong thepathfailstosatisfytheEFrequest,thentheQoSprotocolis triggeredas describedinchapter3.Itlooksforalternatespathsfromthe branchingpoint whichwouldsatisfytheEFrequest.Ifitndsany,thenthealtern atepathis shownalongwiththepartialshortestpath.Iftheprotocolisno tabletond evenanalternatepath,thenonlythepartialpathisdisplaye dwiththelink offailurehighlighted.

PAGE 44

35 Figure4{10:AlgorithmforpathgenerationbyPAP/SPR Algorithm.Thealgorithmtogenerateanddisplayapathbetwee ntheselected sourceanddestinationisshownasinFigure 4{10 SPRandPAParesuccessful,iftheyndapathsuchthatalllinksonth at pathhavebandwidthsassigned requiredbandwidth. 4.4 PathGenerationbyShortestPathRouting{Example1 Anexamplepathgenerationbyshortestpathroutingisrstshown. 4.4.1 InputParameters Theinputparametersforthesamplepathgenerationareasgiv eninthetable below.

PAGE 45

36 Table4{3:ParameterValuesforExampleSPRSimulation Parameter Value NumberofNodes 50 RandomNumberseed 333 TopologyType Waxman AlphaOutdegree 3 MinimumBandwidth 0 MaximumBandwidth 100 MinimumDelay 0 MaximumDelay 100 Figure4{11:TheparameterentrywindowfortheexampleSPRp athgeneration

PAGE 46

37 Figure4{12:Selectingthesourceanddestinationfortheexam pleSPRsimulation Theparameterinputwindowcorrespondingtothevaluesabove isshownin Figure 4{11 Giventheseparameters,atopologyisgeneratedusingtheWaxma nmodelfor 50nodesandanaverageout-degreeof3. 4.4.2 SelectingSourceandDestination Once,thetopologyhasbeengenerated,thesourceanddestinat ionnodesare selected,fortheEFstreamhastoberouted.TheEFbandwidthre quirementis alsospeciedandtheprotocoltobeusedwhichwouldbeShortestPa thRouting inthiscase.Asanillustrationofthepathgeneration,thefoll owingtablegivesthe valuesselected: Table4{4:ParameterValuesforExampleSPRSimulationSour ceandDestination Parameter Value SourceNodeID 24 DestinationNodeID 26 Bandwidth 10 Protocol SPR ThewindowcorrespondingtotheselectionsmadeisasshowninFi gure 4{12 4.4.3 SPRSuccessful Whenthe"OK"buttonisclicked,theShortestPathgeneration algorithm willcalculateashortestpathbytheDijkstra'salgorithmfrom thesourcetothe

PAGE 47

38 Figure4{13:SPRprotocolsuccessful.Theshortestpathgenerate dforthespecied sourceanddestinationisshowninGREEN.Thetotaldelayisshowninthetextwindowbelow destination.Iftheacceptancetestispassedbyallthelinksalo ngtheshortest path,thentheprotocolissuccessful.Inthiscase,thetopology windowwilldisplay thecalculatedshortestpathwithagreenhighlighting,showin gallthelinksalong thepath.Fortheexamplesimulationinputspeciedabove,thesh ortestpath calculatedisasshowninFigure 4{13 .Thesourceandthedestinationhavebeen showninthegure.Thegreenlinerepresentstheshortestpathbet weenthesource andthedestinationnodes,bywhichtheEFtracwillberoutedwi thguaranteed bandwidth.

PAGE 48

39 ThiscaseresultswhentheShortestPathroutingissuccessfulandt heEF tracstreamisroutedsuccessfullyfromthesourcetothedestinati on.Ifthe routingisunsuccessful,thepartialpathisdisplayedalongwit hthelinkoffailure. Anexamplewillbedealtwithinthenextsection. 4.5 PathGenerationbyPAPRoutingProtocol{Example1 Intheprevioussection,successfulroutingusingtheShortestPat hroutingwas described.Thenewroutingprotocoldescribedwillcomeintop icturewhenthe ShortestPathRoutingfailsandthePAPQoSprotocolistrigger ed.Henceinorder toseeanexampleofthenewroutingprotocol,thecaseinwhicht heshortestpath routingfailsisrstconsidered. 4.5.1 InputParameters Here,adierentscenarioisconsideredwiththeinputparameter stakenas showninthetablebelow: Table4{5:ParameterValuesforExamplePAPSimulation{Exam ple1 Parameter Value NumberofNodes 45 RandomNumberseed 333 TopologyType Waxman AlphaOutdegree 2 MinimumBandwidth 0 MaximumBandwidth 100 MinimumDelay 0 MaximumDelay 100 4.5.2 SelectingtheSourceandDestination Thevaluesforthesource,destinationandbandwidthrequirem entsforthe generatedtopologyaregivenbythetableshownbelow: 4.5.3 PAPSuccessful WhentheOKbuttonisclicked,theoutputthatisdisplayedint hetopology windowisasshowninFigure 4{14

PAGE 49

40 Table4{6:ParameterValuesforExamplePAPSimulation{Exam ple1 Parameter Value SourceNodeID 8 DestinationNodeID 42 Bandwidth 10 Protocol SPR Figure4{14:Example1:SPRprotocolfails.Greenlineshowspa rtialshortestpath andredshowslinkoffailure

PAGE 50

41 Figure4{15:UsingPAPprotocolforthesametopologywiththesame parameters. TheEFrequesthasthesamebandwidthrequirementforthesamesourceanddestination AsseeninFigure 4{14 ,theshortestpathroutingfailsbecause,ithaslink31 11ontheshortestpathwhichcannotpasstheacceptancetest.The bandwidth forlink31 11is7whereastherequestedbandwidthfortheEFtracwas10. HenceSPRfailsatnode31.Link31 11isthe InfeasibleLink asdescribed inchapter3.Figure 4{14 showsthepartialshortestpathwith green colorand theinfeasiblelinkwith red .Alsoseeninthegureisthebandwidthofthelinkat whichtheroutingfailed. ThisnecessitatestheuseofaQoSprotocolwhichwillguarantee thatthe EFrequestwillberoutedtothedestinationnode42.ThePAPprot ocolisthen triggeredwhichlooksforalternatepathsatnode31(branch ingpoint)whichhave bandwidthgreaterthan10andwhichcanroutetheEFrequest.T oseehowit works,thesamescenarioisconsideredwiththesamevaluesforinp utparameters. ThePAPprotocolisnowconsideredforthesamesourceanddestinat ionandthe samebandwidthrequirement.Figure 4{15 showthis. WhentheOKbuttonisclicked,thePAPprotocolgetsinvokedwh enSPR failsatnode31asshownabove.ThepathcalculatedbyPAPproto colisasseenin Figure 4{16 ThegureshowsthepathasgeneratedbythePAProutingprotocol ,withthe shortestpathsectionandtheQoSpathsectionshownwithdierentc olors.The

PAGE 51

42 Figure4{16:PAPsuccessfullyroutesthesamerequestforwhichSPR failsatlink 31 11.QoSpathisseeninBLUE,startingfromthebranching point(Node31)

PAGE 52

43 textwindowbelowdisplaysthetotaldelayandthedierentpat hsectionsbynode numbers. Atnode31,SPRchoosespath31 11,whichfails,sinceithasabandwidth (7)lessthantherequiredbandwidth.ThePAPprotocolistrigg ered,which searchesforanalternatepathfromthebranchingpointnode3 1.Itndsalink31 4whichhasabandwidth(47)greaterthantherequiredbandwi dth(10).This canbeveriedbyndingthelinkinformationforlinks31 11and31 4from thelinkinformationwindow.ThisisshowninFigures 4{17 and 4{18 .Hence thePAPprotocolwillndthealternatepathfromnode4onwards tillitreaches thedestinationnode42.Itcanbeseenthatthepathshiftsbackt otheremaining shortestpathwhichisfrom11 42later.Sincethelinksontheshortestpath from11onwardscansupporttherequest,thePAPprotocolfollow stheshortest pathagain.Afterreachingnode42,anacceptmessagewillbesent tothesource thusformingthisnewQoSpathfromnode8to42willbefollowe dforallEF tracfromnode8tonode42.RTentriesaredepositedattheinte rmediaterouters accordingly.Thebranchingpointinthiscaseisnode31asshow ninFigure 4{16 TherecanalsobeapossibilitythattheQoSprotocoldoesnotnda nalternatepathatthebranchingpointwhichwouldsupporttheEFreq uestbyensuring abandwidthgreaterthantherequestedbandwidth.Insuchacase ,thesourcenode isnotiedaccordingly,andthePAPprotocolalsofails.Acorresp ondingmessageis displayed. ThenextexampleshowsacasewheretheSPRfails,PAPissuccessful,a nd PAPchoosesapathwhichistotallydierentfromtheinitialshor testpathwhich SPRwouldhavechosen. 4.6 PathGenerationbyPAPRoutingProtocol{Example2 Here,asecondexampleispresentedtodemonstratethePAProuting protocol. Thedierencebetweenthisexampleandthepreviousoneistha tintheprevious

PAGE 53

44 Figure4{17:Linkinformationforlink31 11todemonstratewhySPRfailsat thebranchingpoint. Figure4{18:Linkinformationforlink31 4todemonstratewhythisalternate pathischosenbyPAP.

PAGE 54

45 case,PAPshiftsbacktotheshortestpathafterchoosinganalterna tepathover theSPRlinkoffailure.Hereinthisexample,thePAPfollowsad ierentpath altogethertothedestination. 4.6.1 InputParameters Here,adierentscenarioisconsideredwiththeinputparameter stakenas showninthetablebelow: Table4{7:ParameterValuesforExamplePAPSimulation{Exam ple2 Parameter Value NumberofNodes 45 RandomNumberseed 333 TopologyType Waxman AlphaOutdegree 3 MinimumBandwidth 0 MaximumBandwidth 100 MinimumDelay 0 MaximumDelay 100 4.6.2 SelectingtheSourceandDestination Thevaluesforthesource,destinationandbandwidthrequirem entsforthe generatedtopologyaregivenbythetableshownbelow: Table4{8:ParameterValuesforExamplePAPSimulation{Exam ple2 Parameter Value SourceNodeID 25 DestinationNodeID 16 Bandwidth 25 Protocol SPR 4.6.3 PAPSuccessful WhentheOKbuttonisclicked,theoutputthatisdisplayedint hetopology windowisasshowninFigure 4{19 AsseeninFigure 4{19 ,theshortestpathroutingfailsbecause,ithaslink4 31ontheshortestpathwhichcannotpasstheacceptancetest.The bandwidth

PAGE 55

46 Figure4{19:Example2:SPRprotocolfails.Greenlineshowspa rtialshortestpath andredshowslinkoffailure

PAGE 56

47 Figure4{20:Link4 31hasabandwidth6.HenceSPRfailsatthislink forlink4 31is6(Figure 4{20 ),whereastherequestedbandwidthwas25.Hence SPRfailsatnode4.Figure 4{19 showsthepartialshortestpathwith green color andthelinkoffailurewith red .Alsoseeninthegureisthebandwidthofthelink atwhichtheroutingfailed. ThePAPprotocolistriggered,whichlooksforalternatepath satnode4 whichisthebranchingpointinthiscase.Forthesamesourceand destination andbandwidthrequirement,thePAPprotocolgeneratesthepa thasshownin Figure 4{21 Inthiscase,however,theQoSpathiscompletelydierentfrom theshortest pathafterthebranchingpointunlikeexample1.Thepathfro mthebranching pointis4 39 27 16;sincelink4 39hasalinkbandwidthof79asshown inFigure 4{22 .Theinitiallinkchosenbyshortestpathroutingatwhichitfai ls (4 31)hasabandwidthof6asshowninFigure 4{20 Theabovetwoexamplesdemonstratetheuseofthenewroutingpr otocol especiallyfortheEFtracincaseofDierentiatedServices,whi chrequires guaranteeddelivery.Insuchcases,thenewprotocolwilltryto ndoutalternate pathsinordertoguaranteetheowofEFrequestevenifshortestp athrouting failsatacertainpoint.

PAGE 57

48 Figure4{21:PAPsuccessfullyroutesthesamerequestforwhichSPR failsatlink 4 31.QoSpathisseeninblue,startingfromthebranchingpoint (Node4) Figure4{22:Link4 39hasabandwidth79.HencePAPchoosesitforthealternatepath.

PAGE 58

49 4.7 MultipleRequestMultipleTopologySimulation Therstpartofthesimulationdiscussedintheprevioussectiongen erateda singletopologyandthencomparedtheShortestPathRoutingan dthenewPAP protocolbygeneratingasinglerequestwithaspeciedbandwidt hrequirement. Thesourceanddestinationwerechosenbytheuserandthenthepat hsasgeneratedbythetwoprotocolsweredisplayedgraphicallyontheto pologygenerated. Inthesecondpartofthesimulation,multipletopologiesareg enerated. Foreachtopology,arandomsourceanddestinationnodearesele ctedfromthe topologyandseveralthousandsofrequestsaregeneratedtober outedfromthe selectedsourcetodestination.Boththeprotocolsarerunfore achtopologyand eachrequestandthenthecomparisonresultsaredisplayedinthe resultswindow below.Thetwoprotocolsarecomparedonthebasisof LinkSuccessRatio which isthepercentageofrequeststhatareadmitted.Theresultsof comparisonwillbe consideredinthenextchapter. 4.7.1 SimulationSteps Thissectiondescribesstepwisehowthemultipletopology,mult iplerequest simulationhasbeendesigned. Input.Thesimulationtakesasinputthesameparametersasthe simulationin theprevioussection,withthefollowingadditionalparamet ers: NumberofTopologies NumberofRequests TopologyType(Inet/Waxman) Algorithm:.ThesimulationfollowsthealgorithmgiveninFigure 4{23 Therequeststhataregeneratedforeachtopologyarenotbased onthe bandwidthrequirement,butonthelinksuccessprobabilityfo reachlinkinthe topology.Foreachvalueoflinksuccessprobabilityrangingb etween0.1and

PAGE 59

50 Figure4{23:Algorithmforthemultipletopology,multipler equestsimulation

PAGE 60

51 1.0(inincrementsof0.1),eachlinkisassignedalinksuccesspr obabilitywhich decideswhetherthelinkwillpasstheacceptancetestornot. 3 Thisdomainstate iscalculatedeachtimeforeachrequestgeneratedforeachto pology.Thusforeach dierentrequestgenerated,thelinksuccessprobabilitieswil lbedierentandhence foreachofthe10iterationsofthesimulationrunforlinkpro babilityvaluesfrom 0.1to1.0, theaveragesuccessratioiscalculatedbytheformula successRatio= numSuccess numRequests where numSuccess=numberofsuccessfulroutingattemptsnumRequests=numberofrequestsgeneratedTheaveragenumberofRTentriesdepositediscalculatedbyth eformula avgRTentries= numRTentries numSuccess where numSuccess=numberofsuccessfulroutingattemptsnumRTentries=numberofroutingentriesdepositedforthesuc cessfulrouting attempt Thenalvaluesforthesetwoparametersforvaluesoflinksucce ssprobabilities rangingfromfrom0.1to1.0,arethendisplayed.Thesevaluesf ormthebasisfor comparisonforthetwoprotocols. 4.7.2 MultipleTopology,MultipleRequestSimulation{Example ThissectiongivesanexampleofaMultipleTopology,Multipl eRequest Simulation. 3 Thebandwidthinthiscaseis0foralllinks

PAGE 61

52 InputParameters.Thefollowingtablegivestheinputparametersfortheexamp lesimulation: Table4{9:ParameterValuesforMultipleTopologyMultiple RequestSimulation{ Example Parameter Value NumberofNodes 50 RandomNumberseed 333 TopologyType Waxman AlphaOutdegree 3 MinimumBandwidth 0 MaximumBandwidth 100 MinimumDelay 0 MaximumDelay 100 NumberofTopologies 10 NumberofRequests 6000 ThisisshowninFigure 4{24 Runningthesimulation.Whenthe"RunSimulation"buttonisc licked,the simulationistriggered,whichthenfollowsthealgorithmgi venintheprevious section.Aftertherequestsaregeneratedandprocessedforallto pologies,the resultsaredisplayedinthetextwindowasshowningure 4{25 AsseenintheFigure 4{25 ,thetwoprotocolsarecomparedonthebasisoflink successratiowithvaluesforlinksuccessprobabilityrangingf rom0.1to1.0.This exampleshowsthesimulationrunwiththeWaxmantopologygene rationmethod. ThesimulationcanalsoberunwiththeInettopologygeneratio nmethod. Theresultsforthesimulationwithsameparametervaluesbutru nwithInet topologygenerationmethodareasshowninFigure 4{26 Thischapterdescribedthesimulationthathasbeenimplement edtodemonstratethenewroutingarchitectureandtheuseofthenewPAProu tingprotocol. ItalsopresenteditsadvantagesoverthetraditionalShortest PathRouting.Itwas seenthatfortraclike EF tracinDierentiatedServicesdomains,guaranteed

PAGE 62

53 Figure4{24:Theinputparametersforthemultipletopology ,multiplerequest simulationexample Figure4{25:Theresultsofthemultipletopology,multipler equestsimulationexampleusingWaxman.TheprotocolsarecomparedonthebasisoflinksuccessratioandaveragenumberofRTentries.

PAGE 63

54 Figure4{26:Theresultsofthemultipletopology,multipler equestsimulation exampleusingINET deliverycanbeassuredwiththenewprotocol,bysearchingfora lternatepathsin casetheshortestpathroutingfails. 4.8 Summary ThechapterdescribesthesimulationandtheGUIthathasbeenim plemented todemonstratethenewroutingarchitecture.The SingleTopology;SingleRequest simulationdisplaysthepathsasgeneratedbytheshortestrouti ngprotocoland thePAPprotocolforaselectedsourceanddestinationforareque stedEFtrac stream.The MultipleTopology;MultipleRequest simulationgivesstatisticalresults tocomparethePAPprotocolwiththeshortestpathroutingbygen eratingseveral thousandEFstreamrequestsonanumberoftopologies.Thenextch apterwill discusstheresultsofcomparisonbetweenthetwoprotocols.

PAGE 64

CHAPTER5 CONCLUSIONSANDFUTURESCOPE Thepreviouschapterdescribedthesimulationwhichdemonstra tedtheuseof thenewroutingarchitectureandasampleprotocol(PAP)thatc anbeusedwith thearchitecturetoguaranteetimelydeliveryofEFtracinD ierentiatedServices domains. 5.1 Comparison Thelastsectioninthepreviouschapterdescribedthecompariso nofthe PAPprotocolwiththetraditionalShortestPathRouting.Seve raltopologieswere generatedwithseveralrequestsroutedonrandomlyselectedsou rceanddestination nodes.Theprotocolswerecomparedonthefollowingtwoparam eters: 1.AverageLinkSuccessRatio2.AverageNumberofRTEntries Thelinksuccessprobabilityvalueswerevariedfrom0.1to1.0 withincrements of0.1andforeachvalue,theabovementionedtwoparameters werecalculated. Figure 4{25 andFigure 4{26 showsthevaluesfortheseparametersforWaxman andInetmodelrespectively.Theaverageresultofthe6000req uestsgivesadata point. 5.1.1 LinkSuccessRatio Thevaluesforthelinksuccessratiohavebeengiveninthefoll owingtablefor theexamplesimulationgiveninthepreviouschapter Fromthevaluesinthetable,weobservethatthelinksuccessrat ionforthe proposedQoSroutingalgorithm(PAP)ishigherthanthelinksuc cessratiofor ShortestPathRoutingforlinksuccessprobabilityvaluesover 0.3,thusshowing 55

PAGE 65

56 Table5{1:LinkSuccessRatioValuesforPAPandSPR{UsingWaxman LinkSuccessProbability SPR PAP 0.1 0.01 0.01 0.2 0.02 0.02 0.3 0.03 0.03 0.4 0.05 0.06 0.5 0.09 0.10 0.6 0.14 0.17 0.7 0.23 0.28 0.8 0.38 0.44 0.9 0.62 0.68 1.0 1.00 1.00 Table5{2:LinkSuccessRatioValuesforPAPandSPR{UsingInet LinkSuccessProbability SPR PAP 0.1 0.01 0.01 0.2 0.02 0.02 0.3 0.04 0.04 0.4 0.07 0.07 0.5 0.11 0.15 0.6 0.19 0.25 0.7 0.30 0.39 0.8 0.45 0.56 0.9 0.68 0.78 1.0 1.00 1.00

PAGE 66

57 0 0.2 0.4 0.6 0.8 1 1.2 0.4 0.5 0.6 0.7 0.8 0.9 1 percentage improvement in admission ratio link success probability PAP with Simple QoS Routing Figure5{1:Admissionratiosperadmittedow thatthenewprotocoldoesimprovethenumberofrequeststhat areadmitted successfully.Comparingwithtraditionalrouting,PAPthusimp rovestheadmissionratio(percentageofrequeststhatareadmitted)signican tly,upto100%. Figure 5{1 showsthis. 5.1.2 AverageNumberofRTEntries Thenewprotocolachievesthisimprovementinadmissionratio atasmallcost. ThiscanbeseenfromthevaluesoftheAverageNumberofRTentrie sdeposited forthePAPprotocol.ThetablebelowgivesthevalueforAverag eRTEntriesfor theexamplesimulationdescribedinthepreviouschapter. Fromthevaluesinthetables,itcanbeseenthatPAPincursavery smallcost withrespecttothenumberofRTentriesdeposited.Intheworstc ase,itdeposits 0.51QRTentryperadmittedowonaverage.Thereasonforthele ss-than-one averageisthat,forrequeststhatcanbesupportedbytheprima rypaths,PAPis equivalenttotraditionalrouting(TRTonly),andnoQRTent ryisrequired.

PAGE 67

58 Table5{3:AverageRTEntriesValuesforPAP{UsingWaxman LinkSuccessProbability AverageRTEntries 0.1 0.01 0.2 0.06 0.3 0.08 0.4 0.13 0.5 0.15 0.6 0.16 0.7 0.17 0.8 0.15 0.9 0.09 1.0 0.00 Table5{4:AverageRTEntriesValuesforPAP{UsingInet LinkSuccessProbability AverageRTEntries 0.1 0.05 0.2 0.09 0.3 0.16 0.4 0.20 0.5 0.24 0.6 0.26 0.7 0.24 0.8 0.20 0.9 0.13 1.0 0.00

PAGE 68

59 0 0.1 0.2 0.3 0.4 0.5 0.6 0.4 0.5 0.6 0.7 0.8 0.9 1 avg. QRT entries per admitted flow link success probability PAP with Simple QoS Routing Figure5{2:QRTentriesforPAPperadmittedow ThisimprovementcanbeseeninFigure 5{2 5.2 Conclusion InthepaperbyDr.Chen etal. [ 2 ],anewroutingarchitectureforDiServ domainshasbeenproposed.Itintegratesthetraditionalrou ting,QoSrouting, packetforwarding,andadmissioncontrol.Theadmissioncontro landQoSrouting ensurethattheEFtracadmittedtothenetworkislimitedunde rthemaximum allowedquotasothattheEFtracalwaysreceivesassuredbandwi dthandlow delay.MuchcarehasbeentakentoreducethesizeoftheQoSrou tingtables.In particular,theproposedQoSroutingprotocolrequiresonly onetableentryata branchingpointtostoreanalternativeroutingpath. ThesimulationandtheGUIthathasbeenimplementedhelpsdemo nstrating theadvantagesofthenewprotocoloverthetraditionalprot ocolsliketheshortest pathrouting.Itdisplaysgraphicallyhowtheprotocolsearch esforalternatepaths whentheshortestpathroutingfailsatacertainnodeinthenet work.Withthe

PAGE 69

60 helpoftheGUI,thiscanbeveriedbylookingatthelinkbandwi dthsforthelinks offailureorthealternatelinkschosenbythenewprotocol.C omparingthesetwo protocolsonthebasisofthelinksuccessratiogivesaviewofho wthenewprotocol improvesadmissioncontrolataverylowcost.TheGUIgivesagrap hicalviewof thepathsgeneratedthusgivinganideaoftheQoSroutingint heinternetworld, providingmoreopportunitiesforresearchinthisarea. 5.3 FutureScope Thisthesisdiscussesanewprotocolanditsimplementationfort heDiServ domainsbutitdealswiththeExpediteForwardingTracPHBonl y.Inchapter2, twoclassesofPHBswereseenfortheDierentiatedServicesdomai ns: 1.ExpediteForwarding(EF)2.AssuredForwarding(AF) TheprotocolproposedcanbeextendedormodiedtohandleAFtra c also.AFtracdenesdierentforwardingclasseseachwiththreedi erentdrop precendences.Thisismainlytoprovidedierentlevelsofserv icestocustomers andapplications.Consideringthis,theprotocoland/ortheim plementationcanbe modied/extendedtohandleAFtracclassforeachoftheforward ingclasses thatitdenes. Also,evenfortheEFtracclass,theprotocolcanbecomparedwith several othertraditionalroutingprotocolsapartfromtheShortest PathRoutingandthis canbedemonstratedbyenhancingandextendingtheimplement ation/GUI.This couldgiveaclearviewofwhetherthenewroutingarchitectu redoesprovidea considerableadvantageovermostofthecurrentlyusedrouting protocols. Inthisimplementation,thePAProutingprotocolusesthebasic approachof ndingashortestpathfromthesourcetothedestination(shortestp athalgorithm) evenafterndinganalternatepath.Ittriestoshiftbacktoth eoriginalshortest pathtoseeifitcannowsupporttherequestedbandwidth.Ifbein gcompared

PAGE 70

61 withotherroutingprotocols,themethodofndingtherouteto thedestination afterthealternatepathhasbeenfoundfromthebranchingno de,couldbemade moreecientthanusingtheshortestpathonly.Theapproachcoul dberecursively appliedateachhopalongthepath,whichwouldbecompletely independentofthe initialshortestpath,thussuggestingtheuseofmultiplebranch ingpointsinsteadof one. ThesimulationusesonlytheWaxmanandInettopologygenerati onmethods. Waxmanhasbeenusedforthesimplicityofdisplayingthetopolo gysinceWaxman provideswelldenedco-ordinatesforthenodesthatcouldbe plotted.Butthere aremanyothernetworktopologygeneratorswhichcouldbeuse dinorderto simulateamorerealisticnetworktopologytomodeltheDiServ domain.Someof thepopularnetworktopologygeneratorsthatcouldbeusedar e: 1.TheNS-2simulatorfromStanfordUniversity[ 4 ], 2.TheGT-ITMtopologygeneratorfromGeorgiaInstituteofTe chnology[ 13 ], 3.TheBRITEtopologygeneratorfromBostonUniversity[ 7 ], Suchenhancementscouldopennewwaysforfurtherresearchin theproposed protocolanditsimplementation.

PAGE 71

REFERENCES [1]Bergho,G.,\IntroductiontoQoSandDierentiatedServi ces," Application toNokia'sIPRAN ,May2002,AvailableatURL: www-i4.informatik.rwth-aachen.de/Kolleg/Vortraege/B erghoff.pdf LastAccessed:March2004 [2]Chen,S.,Ling,Y.andChen,S.,\ANewRoutingArchitecturef orDiServ Domains" InternationalConferenceonCommunications,Internetand InformationTechnology(CIIT2003) ,Scottsdale,AZ,Nov2003 [3]Cheng,J.,Chen,Q.andJamin,S.,\Inet:IntenetToplogy Generator," TechnicalReport UM-CSE-TR-433 ¡ 00,AvailableatURL: http://topology.eecs.umich.edu/inet/inet-2.0.pdf LastAccessed:March2004 [4]Greis,M.,\TutorialfortheNetworkSimulator"ns"," InformationSciences Institute ,AvailableatURL: http://www.isi.edu/nsnam/ns/tutorial/index.html LastAccessed:March2004 [5]Kasari,A.,\AnArchitectureforDierentiatedServices," ResearchSeminar onIPQualityOfService ,DepartmentofComputerScience,Universityof Helsinki,Oct.2000,AvailableatURL: http://www.cs.helsinki.fi/u/kraatika/Courses/QoS00a /kasari.pdf LastAccessed:March2004 [6]Manner,J.,\ShortOverviewofDierentiatedServices,"O ct2003,Available atURL: www.cs.helsinki.fi/u/jmanner/Courses/seminar papers/diffserv.pdf LastAccessed:April2004 [7]Medina,A.,Lakhima,A.,Matta,I.andByers,J.,\BRITE:Univ ersalTopologyGenerationfromaUser'sPerspective," ComputerScienceDepartment, BostonUniversity ,Apr2001,AvailableatURL: http://www.cs.bu.edu/brite/user manual/BritePaper.html LastAccessed:March2004 [8]MicrosoftCorporation,\MicrosoftWindows2000Server:A ShortOverview ofQoSMechanismsandtheirInteroperation" WhitePaper ,Nov1999, AvailableatURL: http://www.microsoft.com/windows2000/docs/QoSMech.d oc 62

PAGE 72

63 LastAccessed:March2004 [9]NortelNetworks,\IntroductiontoQualityofService(QoS) ," WhitePaperon QualityofService ,2003,AvailableatURL: www.nortelnetworks.com/products/02/bstk/switches/bp s/collateral/56058.25 022403.pdf LastAccessed:March2004 [10]Schildt,H., MFCprogrammingfromthegroundup ,2ndEdition, Osborne/McGraw-Hill,NewYork,1998. [11]Tangmunarunkit,H.,Govindan,R.,Jamin,S.,Shenker,S .andWillinger, W.,\NetworkTopologies,PowerLawsandHeirarchy," TechnicalReport USC-CS-01 ¡ 746,AvailableatURL: http://www.isi.edu/ hongsuda/publication/ccrNote01 2.ps LastAccessed:March2004 [12]Tangmunarunkit,H.,Govindan,R.,Jamin,S.,Shenker,S .andWillinger,W., \NetworkTopologyGenerators:DegreeBasedvs.Structural,"in Proceedings ofACMSIGCOMM'02 ,Pittsburgh,PA,Aug2002.AvailableatURL: http://www.acm.org/sigcomm/sigcomm2002/papers/topog en.pdf LastAccessed:March2004 [13]Thomas,M.,Edwards,E.andBhattacharjee,S.,\Modeling Topologyof LargeInternetworks," CollegeofComputing,GeorgiaInstituteofTechnology May1997,AvailableatURL: http://www.cc.gatech.edu/fac/Ellen.Zegura/graphs.ht ml LastAccessed:March2004 [14]Wilkins,S.,Garg,S.andMeyyammai,S., MFCDevelopmentusingMicrosoft VisualC++ ,MicrosoftPress,Redmond,WA,2000. [15]Zhang,P.,Kantola,R.andAalto,S.,\QoSRoutingforDiS ervNetworks: IssuesandSolutions(Draft)," TechnicalReport,NetworkingLaboratory, HelsinkiUniversityofTechnology ,Oct2002,AvailableatURL: www.netlab.hut.fi/tutkimus/ironet/papers/report-qos r-diffserv.ps LastAccessed:March2004

PAGE 73

BIOGRAPHICALSKETCH HrishikeshNulkarwasbornonApril27 th ,1981,inthecityofPune,Maharashtra,India.Hereceivedhisbachelor'sdegree,BachelorofEn gineering,inComputer ScienceandEngineeringfromthePuneUniversity,IndiainJun e2002. InAugust2002,hejoinedtheUniversityofFloridatopursueamaste r'sdegree incomputerscienceandengineering.Duringhismaster'sstudy hehasbeena TeachingAssistantattheDepartmentofComputerandInformatio nScienceand EngineeringattheUniversityofFlorida.Hisresearchinterests includecomputer networks,networksecurity.Heexpectstocompletehisdegreei nMay2004. 64


Permanent Link: http://ufdc.ufl.edu/UFE0004892/00001

Material Information

Title: Simulation and Evaluation of PAP: A New Routing Architecture for Differentiated Services Domains Handling 'Expedite Forwarding' Traffic Class
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0004892:00001

Permanent Link: http://ufdc.ufl.edu/UFE0004892/00001

Material Information

Title: Simulation and Evaluation of PAP: A New Routing Architecture for Differentiated Services Domains Handling 'Expedite Forwarding' Traffic Class
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0004892:00001


This item has the following downloads:


Full Text











SIMULATION AD I7ALUATION OF PAP: A NT7-.' ROUTING
AR( i ::' :lE FOR DIFFi: \.: TIATED ': :i.VI : DOMAINS HANDLING
: )ITE FORWARDING" TRAFFIC CLA* .
















By


HR1 E iT


:: N ULKAR


A THESIS PR: i iTED TO THE GRADUATE SCHOOL
OF i i OF OF 0 I i)A L PAIR I AL FU i: 1
OF THE REQUIRi TTS FOR THE DEGREE OF
MAJ Li OF S('Cii .CE


UNIVERSITY OF FLORIDA




































by

HRI :i I i NULKAR















ACKNOWLEDGMENTS

I would to c: 1:: 1 1: the supervision of Dr. ::: C : :: and his

extremely helpful guidance throughout this work.I would also like to thank Dr.

Richard Newman and Dr. Ye Xia serving on '* supervisory committee and

reviewing : : work.

I would Y to thank all i friends who have helped me directly or indirectly

in this work.

Finally, I am n -..: and indebted to -:-ents who have helped me become

what I am to














TABLE OF CONTENTS
page

ACKNOWLEDGMENTS ................... .......... iii

LIST OF TABLES ................... .............. vi

LIST OF FIGURES ................... ............. vii

ABSTRACT ................... ................. ix

CHAPTER

1 INTRODUCTION .................. ... 1

1.1 QoS Technologies ................... ........ 1
1.2 The New Routing Architecture (PAP) ............... 2
1.2.1 The Protocol ...... ........... .. ...... 2
1.2.2 The Simulation .... ............. .... 3
1.3 Organization of Thesis ................... ... 3

2 QOS ROUTING AND DIFFERENTIATED SERVICES NETWORKS 4

2.1 QoS Routing Overview .... ........... .... 4
2.2 Overview of Differentiated Services . . . .. 5
2.2.1 Types of DiffServ Routers. . . . . 6
2.2.2 DiffServ Router Architecture . . . . 8
2.2.3 Diffserv Per-Hop Behaviors . . . . .. 8
2.3 Summary .. . . . .. . . .... 10

3 PAP: A ROUTING PROTOCOL FOR DIFFSERV DOMAINS .. .. 12

3.1 Overview . . . . . . . .... 12
3.2 TRT and QRT .. . . . .. . .... 13
3.3 Admission Control .. . . . . .... 15
3.4 QoS Routing . . . . . . ..... 16
3.5 Summary .. . . . .. . . .... 20

4 SIMULATION .. . . . .. . . .... 21

4.1 Overview. . ............ . . ...... ... 21
4.2 Network Topology Generation Methods . . . 22
4.2.1 Metrics ................ . ... 23
4.2.2 Random Topology Generators . . . ...... 23










4.3 Simulation ... . . .. . . .... 25
4.3.1 Network M odel . . . . .. . 25
4.3.2 The Graphical User Interface . . . ...... 26
4.4 Path Generation by Shortest Path Routing-Example 1 . 35
4.4.1 Input Parameters . . . . . 35
4.4.2 Selecting Source and Destination . . . 37
4.4.3 SPR Successful . . . . . . 37
4.5 Path Generation by PAP Routing Protocol-Example 1 . 39
4.5.1 Input Parameters .. . . . . ... 39
4.5.2 Selecting the Source and Destination . . 39
4.5.3 PAP Successful . . . . . 39
4.6 Path Generation by PAP Routing Protocol-Example 2 . 43
4.6.1 Input Parameters .. . . . . .. 45
4.6.2 Selecting the Source and Destination . . 45
4.6.3 PAP Successful . . . . .. . 45
4.7 Multiple Request Multiple Topology Simulation . .... 49
4.7.1 Simulation Steps . . . . .. . 49
4.7.2 Multiple Topology, Multiple Request Simulation-Example 51
4.8 Summary . . . . .. .......... 54

5 CONCLUSIONS AND FUTURE SCOPE. . . . 55

5.1 Comparison . . . . .. .......... 55
5.1.1 Link Success Ratio .. . . . . .. 55
5.1.2 Average Number of RT Entries . . . 57
5.2 Conclusion . . . . .. .......... 59
5.3 Future Scope . . . . .. ......... 60

REFERENCES. .... . . ... .............. 62

BIOGRAPHICAL SKETCH ... . . .. . ..... 64















LIST OF TABLES
Table page

4-1 Default Values for Input Parameters . . . ... 30

4-2 Default Values for Multiple Topology, Multiple Request Simulation
Parameters . . . . . . ...... 31

4-3 Parameter Values for Example SPR Simulation . . 36

4-4 Parameter Values for Example SPR Simulation Source and Destination 37

4-5 Parameter Values for Example PAP Simulation-Example 1 . 39

4-6 Parameter Values for Example PAP Simulation-Example 1 . 40

4-7 Parameter Values for Example PAP Simulation-Example 2 . 45

4-8 Parameter Values for Example PAP Simulation-Example 2 . 45

4-9 Parameter Values for Multiple Topology Multiple Request Simulation-
Example .. . . . .. ............ 52

5-1 Link Success Ratio Values for PAP and SPR-Using Waxman . 56

5-2 Link Success Ratio Values for PAP and SPR-Using Inet . . 56

5-3 Average RT Entries Values for PAP-Using Waxman . . 58

5-4 Average RT Entries Values for PAP-Using Inet . . 58















LIST OF FIGURES
Figure page

2-1 The differentiated services domain architecture showing the types of
DiffServ routers . . . . . . .. 6

2-2 The differentiated services domain architecture showing the types of
DiffServ routers and their functions in the domain. . . 7

2-3 The architecture of a DiffServ router with its internal components 8

3-1 TRT and QRT: When an EF packet arrives, the QRT at the incom-
ing interface is first looked up. If there is a match, the packet is
forwarded to the next hop and TRT is not checked; otherwise the
TRT is looked up .. . . . .. ........ 14

3-2 QoS routing . . . .. ............ 17

4-1 A view of the GUI implemented with all the component windows 27

4-2 Network topology generated by Waxman method for 30 nodes with
an average out-degree of 3 . . . . ... 28

4-3 A denser network topology generated by Waxman method for 30 nodes
with an average out-degree of 5 . . . ..... 29

4-4 The parameter entry window with default values . . . 30

4-5 The simulation parameter entry window with default values .. ... 31

4-6 Reset parameter values to default for new simulation . . 32

4-7 The node information window displaying properties of a clicked node 32

4-8 The link information window displaying properties of a specified link 33

4-9 Selecting the source and destination nodes. The bandwidth require-
ment for the request is also specified. . . . . 34

4-10 Algorithm for path generation by PAP / SPR .. . 35

4-11 The parameter entry window for the example SPR path generation 36

4-12 Selecting the source and destination for the example SPR simulation 37









4-13 SPR protocol successful.The shortest path generated for the speci-
fied source and destination is shown in GREEN.The total delay is
shown in the text window below . . . ..... 38

4-14 Example 1: SPR protocol fails. Green line shows partial shortest path
and red shows link of failure . . . . .. 40

4-15 Using PAP protocol for the same topology with the same parame-
ters. The EF request has the same bandwidth requirement for the
same source and destination . . . . ... .. 41

4-16 PAP successfully routes the same request for which SPR fails at link
31 11. QoS path is seen in BLUE, starting from the branching
point (Node 31) .. . . ... . ..... 42

4-17 Link information for link 31 -> 11 to demonstrate why SPR fails at
the branching point. .. . . .... 44

4-18 Link information for link 31 4 to demonstrate why this alternate
path is chosen by PAP. . . . . . . 44

4-19 Example 2: SPR protocol fails. Green line shows partial shortest path
and red shows link of failure . . . . ... .. 46

4-20 Link 4 31 has a bandwidth 6.Hence SPR fails at this link . 47

4-21 PAP successfully routes the same request for which SPR fails at link
4 -> 31. QoS path is seen in blue, starting from the branching point
(Node 4) ..... . . . ............. 48

4-22 Link 4 -> 39 has a bandwidth 79. Hence PAP chooses it for the al-
ternate path. . . . . . . ....... 48

4-23 Algorithm for the multiple topology, multiple request simulation 50

4-24 The input parameters for the multiple topology, multiple request sim-
ulation example . . . . . . .. 53

4-25 The results of the multiple topology, multiple request simulation ex-
ample using Waxman. The protocols are compared on the basis of
link success ratio and average number of RT entries. . . 53

4-26 The results of the multiple topology, multiple request simulation ex-
ample using INET .. . . . . .... 54

5-1 Admission ratios per admitted flow . . . ...... 57

5-2 QRT entries for PAP per admitted flow . . .. 59















Abstract of T1 Presented to the Graduate School
of the University of Fi :da in Partial Fi:i:D : : :. of the
Squirenments for the Degree of Master of Science

i LAl: ON AND EVALUA: :0- C: PAP: A i RO: IL G
ARCHITED' i E FOR DIFFERENTIATED i VIC: DOMAINS HANDLING
i:EDITE FOLF.ARDING" TRA i: :IC CLA

By

llrishikesh Nnulkar

May L


Major Department: Computer and Information Science and Engineering

research paper by Dr. c'' et al. proposes a new routing

architecture (PAP) for differentiated services domain that integrates admission

control signaling and the P .'. routing. It .'. from traditional routing in its

ability to route most expedite f4. :1':: (EF) 1: : along the shortest .

paths while making use of alternative 1 to absorb transient overload. Once

an EF data flow is admitted, its :: :e is assured. T: overhead : : storing

alternative path information is minimal since <'*!-- one routing entry at a branching

point is needed for each alternative path.

T- thesis focuses on a simulation ': .:.1 :... :.i ed to demonstrate the above

proposed rooting architecture and compare it with the traditional ro: l':: proto-

cols. A (.: : has been designed and ': : 1. :.. .cid to show the simulation results

graphically on the generated topologies. It
routing protocol and by the shortest path routing protocol for different bandwidth

requirements, (i-'' sources and destinations and c(i -- -es them on the basis of

specific parameters.















C :1WPTER 1
INTRODUCTION

As the effort of .- : : voice and data into a single network accelerates, a

wide :::I- of multimedia applications i ::: : i : requirement for timely delivery

( c digitized audio-visual information raises new challenges broadband networks.

It is a challenging problem to commit network resources in a scalable ----- so

that the <( 1 or thro- at sensitive traffic is appropriately treated as 1: are

routed through the network. U system functions like Admission control,

QoS routing should co-operate with each other to achieve this. Admission control

ensures that. the total traffic in the network does not overwhelm the available

resources. T: : ::: routing protocols make sure that the packets get to their

destinations, while CI. *' routing protocols make sure that the iho 1 traffic is well

spread on I H ::: paths to increase the utilization of the network's capacity.

Packet a r and resource management at the routers allow differentiated

treatment for :1 streams with varied service requlirerments

1.1 QoS Technologies

0b '' support roughly : i in two broad categories: Integrated Services

(IntServ) and Differentiated Services (- .i v). IntServ supports protocols

like I' '-.'P where the required resources are reserved at every router along the path

of traffic stream to guarantee the performance of a traffic stream. But this has

a drawback of storing per stream information at ***" core router and for even

millions of such stream going through and hence is not so scalable.

L i. .ery solves this problem 1-- pushing the complexity to the edge of the

network, where the data traffic is classified into (c: : ::;. service classes 1. setting

a code point in the IP header of every packet. Inside the DiffServ domain, the









packets are treated according to the service classes they belong to. In this way, the

per-stream information is eliminated inside the domain. The resource management

is conducted at a course level based on service classes. In spite of this, routing

support for DiffServ is still an open problem. Although the design of DiffServ

is independent from routing, the routing function has a significant impact on

the effectiveness of some classes like the expedite forwarding (EF). The routing

function directly affects the admission control, which determines the traffic volume

that a DiffServ network can accommodate for each service class.

1.2 The New Routing Architecture (PAP)

In the research paper by Dr. C'. i1 et al.[2], a new routing architecture for

DiffServ domains has been compared to traditional routing protocols like the

shortest path routing. Shortest path routing is good for best effort traffic but too

restrictive for QoS traffic. Before a traffic stream is delivered, the sender or the

receiver activates the QoS routing protocol to establish a routing path that has

the required resources. A routing entry is inserted at each router on the path thus

depositing per stream information at each router. Another option is to carry the

routing path in the source-routing IP option which causes excessive overhead on

the routers. The core idea of the paper focuses on the fact that there might be

several other paths other than the shortest path that might support the required

QoS when the shortest path cannot.

1.2.1 The Protocol

The paper by Dr. C('!. i et al.[2], thus proposes a new architecture for routing

of particularly the Expedite Forwarding traffic class for DiffServ domains. It relies

mainly on the destination-indexed shortest path called as the primary path. But

when the primary path is saturated and cannot support more traffic without QoS

degradation, temporary alternate paths are established on demand. The traffic on

these alternate paths will switch back to the primary path whenever it is again









able to support the traffic. The n i' Pr advantage of this architecture is that no

per stream routing information is needed in normal conditions and in overloaded

conditions, alternate paths are used to absorb the overloaded traffic and only

one extra entry is needed at the branching point to store an alternate path. The

admission control signaling is an integrated component in the new architecture and

the existing QoS routing protocols find their place in the DiffServ world.

1.2.2 The Simulation

A simulation based on a simple DiffServ network model can demonstrate the

advantages described above. This thesis focuses on developing a GUI based on

the simulation to model the topology graphically, select the required source and

destination nodes in the network, select and compare the traditional shortest path

routing and the new architecture (PAP) based on certain bandwidth requirements

for thousands of requests generated. A simulation has been implemented in C++

to demonstrate the new routing architecture, creating several topologies by the

Waxman model, generating thousands of requests for each by selecting a random

source and destination node, and then comparing the new architecture with

the traditional routing protocols. The GUI depicts this comparison graphically

di-pl iiing paths for a single Waxman topology.

1.3 Organization of Thesis

The thesis is organized as follows: C'!I Ipter 2 provides an overview of differ-

entiated services and QoS routing. C'!i lpter 3 introduces the proposed routing

architecture (PAP). It also describes admission control and QoS routing in the new

architecture. C'!I Ipter 4 describes the implementation of this architecture in the

form of a simulation (in C++) and a GUI developed for this simulation (Using

MFC[14, 10]). It also describes the comparison of the new architecture and the

shortest path routing based on the simulation results. C'!I Ipter 5 gives conclusions

and discusses scope for further research in this area.















CHAPTER 2
QOS ROUTING AND DIFFERENTIATED SERVICES NETWORKS

2.1 QoS Routing Overview

Tod i .-, network traffic is highly diverse and each type of traffic has unique

requirements in terms of bandwidth, delay, loss, and availability. The IP protocol

was originally designed to reliably get a packet to its destination with less consid-

eration to the amount of time it gets there. t1 ij of the applications supported

over IP require low latency and the end-user quality may be significantly affected

or in some cases, the application simply does not function at all. VoiceOverlP

could be a good example of an application which requires this type of behavior

(low and fixed amount of delay with minimum loss), to function properly. The

best-effort IP network introduces a variable and unpredictable amount of delay to

the voice packets and also drops voice packets when the network is congested. QoS

techniques could be applied to this best effort IP network to make it capable of

supporting VoIP with acceptable, consistent, and predictable voice qI ilii ['l"

QoS based routing has been regarded as an essential mechanism for providing

QoS guaranteed services in the Internet[15]. Its primary aim is to manage limited

resources of IP networks efficiently. It aims to achieve two key goals:

Improving network resource utilization,
Achieving user's QoS satisfaction.

Networks are built by concatenating network devices such as switches and routers.

They forward traffic among themselves using interfaces. If the rate at which traffic

arrives at an interface exceeds the rate at which that interface can forward traffic

to the next device, then congestion o. .ii []. Thus, the capacity of an interface









to forward traffic is a fundamental network resource. QoS mechanisms work by

allotting this resource preferentially to certain traffic over other traffic.

In order to do so, it is first necessary to identify different traffic. Traffic

arriving at network devices is separated into distinct flows via the process of packet

classification. Traffic from each flow is then directed to a corresponding queue on

the forwarding interface. Queues on each interface are serviced according to some

algorithm. The queue-servicing algorithm determines the rate at which traffic from

each queue is forwarded, thereby determining the resources that are allotted to

each queue and to the corresponding flows. Thus, in order to provide network QoS,

it is necessary to provision or configure the following in network devices:
1. Classification information by which devices separate traffic into flows,

2. Queues and queue servicing algorithms that handle traffic from the separate
flows.

This thesis focuses on one such traffic handling mechanism called Differentiated

Services.

2.2 Overview of Differentiated Services

The growth of business requirements and new applications has set a clear need

for simple methods of providing differentiated classes of service for Internet traffic.

Differentiated Services is a modular, high performance, incrementally deploibl] '1

and scalable approach on the way of developing end-to-end QoS of Internet [5]. It is

a set of technologies that allow the network service providers to offer different kinds

of services to different customers and their traffic streams.

DiffServ follows the philosophy of mapping multiple flows into a few service

levels, sometimes referred to as Class of Service (CoS). DiffServ does not define

signaling mechanisms; instead, packets are marked with a DiffServ Code Point

(DSCP), which provides information about the QoS requested for a packet[6]. The

code point enables network routers to handle IP packets differently depending on











DiffServ Domain DiffServ Domain

host I host
SLA SLA



edge router Egress router Ingress Router Edge Router
Interior Router

Figure 2-1: The differentiated services domain architecture showing the types of
DiffServ routers

the code point and hence the relative priority. DiffServ code points are located in

the 8-bit Type of Service (TOS) field in the IP header in the lower order 6 bits.

Differentiated Services is a combination of

1. Marking packets with a DSCP at boundary nodes;

2. Using the DSCP to determine how packets are forwarded by interior nodes;

3. Conditioning packets at boundary nodes.

2.2.1 Types of DiffServ Routers

There are three types of routers in a DiffServ domain[2]:

1. Edge Routers,

2. Interior Routers,

3. Ingress and Egress Routers.

Figure 2-1 shows the three types of routers in the Differentiated Services

domain architecture.

Figure 2-2 shows the functions of the the different types of routers in the

Differentiated Services domain.

Edge routers. As shown in Figure 2-2, an edge router is at the boundary of

a DiffServ domain. It negotiates and enforces a Service Level Agreement (SLA)

with a customer. SLA may consist of parameters like maximum packet loss,










SLA SLA

Ingress T r ip e -Egress
Node inteor Node




\ Forwarding
DiffServ Domain (H -Shaping


Figure 2-2: The differentiated services domain architecture showing the types of
DiffServ routers and their functions in the domain.


maximum packet delay. The SLA specifies the terms and conditions of the service

being offered. The edge router implements -nI .Iph,.re routing, policing, packet

classification, marking, monitoring and other functions.

Ingress and egress routers. Between two domains, the router from which the

traffic leaves a domain is called an egress router, and the router from which traffic

enters a domain is called an ingress router. These are responsible for ensuring that

incoming traffic conforms to the SLA between the two domains. Thus most of the

workload is shifted on to the edge routers and the interior core routers remain

simple.

Interior routers. The interior core router only needs to know how to handle

a few traffic classes rather than keeping knowledge about thousands of individual

traffic streams. In this way, per-stream information is eliminated inside the domain.

They do not implement traffic conditioning. Resource management is conducted

at a course level based on service classes. Differentiated services can thus alleviate

core network and boundary router bottlenecks by better managing high priority

traffic.























Figure 2-3: The architecture of a DiffServ router with its internal components


2.2.2 DiffServ Router Architecture

A DiffServ router consists of five components as shown in Figure 2-3, a packet

arrives at the classifier and will be classified according to the bilateral service level

'i, H ii II ['*]. The classifier forwards the packet to the traffic conditioner. The

traffic conditioner may include a meter, a marker, a shaper and a dropper.

Meters measure the temporal properties of the stream of packets selected
by a classifier against a traffic profile specified in a Traffic conditioning
Agreement (TCA.

Shapers delay some or all of the packets in a traffic stream in order to shape
the stream into compliance with a traffic profile.

Droppers discard some or all of the packets in a traffic stream in order to
bring the stream into compliance with the traffic profile. This process is
known as policing the stream.

2.2.3 Diffserv Per-Hop Behaviors

The service of DiffServ is realized by mapping the DSCP contained in the IP

packet header to a per-hop Behavior (PHB) at each network node along the path of

the packet. There are two primary PHBs defined for DiffServ networks[6]:

1. Expedite Forwarding

2. Assured Forwarding









Expedite forwarding. EF is a service with low loss, low latency, low jitter and

guaranteed bandwidth[l]. It has the following properties: peak bit rate on flows

or on .' -:-regated flows, no bursts, only within the peak bit rate, and low queuing

d4.1 i. The idea is to alb-- keep the total EF traffic passing through any link in

the network under a limit, which is set to be smaller than the link bandwidth.

Traffic that exceeds this limit must be discarded. A simple priority queue is then

used to schedule EF packets before packets from other service classes. If EF PHB

is implemented by a mechanism that allows unlimited preemption of other traffic,

the implementation must include some means of to limit the damage EF traffic

could do to the other traffic. Since the receiving rate of EF traffic is ahb i smaller

than the sending rate at every router, EF traffic is guaranteed for minimized delay

and assured bandwidth. In order to provide this high service level in practice, the

amount of traffic injected into the EF class needs to be carefully policed. EF PHB

is in charge for guaranteeing a minimum departure rate for some traffic and this rate

is independent of the rest of the traffic to be forwarded by the same router at the

same time. Admission control and routing are essential to make sure that EF traffic

never exceeds the link bandwidth. It is most idly suited for VoIP.

Several types of queue scheduling mechanisms may be emploi-- 1 to deliver

the forwarding behavior described above and thus implement the EF PHB. A

simple priority queue will give the appropriate behavior as long as there is no

higher priority queue that could preempt the EF for more than a packet time at

the configured rate.1



1 This could be accomplished by having a rate police such as a token bucket as-
sociated with each priority queue to bound how much the queue can starve other
traffic









The host that sends out an EF stream is called the source host. The edge

router that the source host connects to is called the source router. The host that

receives the EF traffic stream is called the destination host. The edge router that

the destination host connects to is called the destination router. An EF traffic

stream is a one-way traffic stream. Two EF streams in opposite directions model

two-way traffic. Two-way traffic is admitted into the network only after its two

EF streams are both accepted by the admission control[2]. In the paper and this

implementation, only a single EF traffic stream has been considered.

Assured forwarding. AF does not provide bandwidth guarantee but packets

are given a higher priority. It is mainly used for delay insensitive traffic. The AF

PHB group defines the dropping precedence among different classes of AS traffic

when network congestion o .'ii -[';[]. Queue management is more essential to the

implementation of AF service.

2.3 Summary

The chapter describes the need for QoS routing to route delay sensitive

traffic through the network with guaranteed bandwidth and minimum delay.

Differentiated Services is one such traffic handling mechanism that does provide the

classification of network traffic and provides QoS guarantee for each class according

to its requirements, by differentiating packets on the basis of Code Points at the

edge routers. It scores over IntServ by eliminating per stream information to be

deposited inside the domain and thus making interior routers simple.

Expedite Forwarding service is the focus of this thesis since it provides

guaranteed QoS if admission control and routing are properly done. Clearly EF

traffic has distinctive characterization from AF traffic. Hence the new routing

architecture described in the paper by Dr. Ch! i1 et al.[2] and its implementation

in this thesis is concerned mainly for EF traffic because of the important role that







11

routing and admission control 1:1 in (- ent working of EF PHB. ni next

chapter will : : the new routing architecture for L:: i.' :v domains.















CHAPTER 3
PAP: A ROUTING PROTOCOL FOR DIFFSERV DOMAINS

This chapter discusses a new routing protocol that can be used with the

proposed routing architecture for Differentiated Services domains[2].

3.1 Overview

Expedite forwarding traffic can be routed by the traditional routing table

(TRT) as is done in the case best-effort traffic. The traditional routing tables

provide a single path between each pair of nodes. If the path is overloaded by the

EF traffic, the TRT approach lacks the flexibility of using alternate paths.

As proposed in the research paper, the new routing architecture primarily

uses TRT to route the EF traffic but relies on alternate paths to handle the

overload condition. The alternate paths are stored in the QoS routing tables (QRT)

which are constructed on demand by the QoS routing protocols. The QoS routing

protocols are invoked only when the EF traffic overloads the primary routing path.

Under normal conditions when the network is not overloaded, the system will not

see the existence of the QoS routing protocols.

When an EF stream arrives, the source host issues a request to the source

router. The source router initiates the admission control signaling between the

source router and the destination router. A REQUEST message is sent towards

the destination router to check the bandwidth availability along the path. In the

proposed routing architecture, all control messages and non-EF data packets are

routed along the primary paths by TRT in the same way the current IP networks

route packets.

As a router on the primary path receives the REQUEST, it performs a

simple acceptance test to check if it has enough bandwidth for the EF traffic.









If it does, the R'liU i is forwarded to the next hop on the primary path. If

the acceptance tests of all intermediate routers are passed and the RE" UL .' I

successfully arrives at the destination router, it rneans that the primary path can

support the new l It : i:: 'i ::: destination router sends an ACC ii'LT message

to the source router, which in turn notifies the source host to start, sending data

packets. The data packets will be routed by TRTs and .':.w the primary path to

the destination host.

On the other hand. if the acceptance test i ** at an int( .... .. router, which

reans the primary r. .i1: can not -q i;'t the traffic, then a QoS routing protocol is

tr---ered to find an alternative path. If an alternative I!1 that supports the traffic

is >und, an AC' IEPT message is sent to the source router and the data packets

of the EF stream will follow the alternative path. If an alternative pathl cannot be

found, aR i L:' i message is sent to the source router, which :1 either : the

EF traffic or : *: the admission control at a later time.

alternative paths are stored in ( Ts. In order to keep the size of the

( *!Ts small, traffic using an alternative path merges back to the :':: x y path

when there is sufficient bandwidth freed up on the primary path. The difference

between the T: ::: : : routing table and QoS routing table is discussed, noting

how data : are forwarded 1 these :* *' tables.



Each router has one TRT maintained by the traditional routing otocols such

as RIP, OSPF, IGRP, and/or BGP. In addition, it has a OlT for each network

: i i : s are maintained --- the 0-)S routing protocols. reason

to use ::i111 QI-.T instead of one for the entire router is to reduce the size of

each QRIl'. It is clear that each incoming packet 1 be matched against one QIRT,

:::: table size results in i :* processing.










QoS routing protocols ) ( traditional roofing protocols


update upon triggering update perodicaly
or upon triggering


packet frame incoming look up QRT at the look upTRT outgoing -*packet frame
interface incoming interface no match match interface

match


Figure 3-1: TRT and QRT: When an EF packet arrives, the QRT at the incoming
interface is first looked up. If there is a match, the packet is forwarded
to the next hop and TRT is not checked; otherwise the TRT is looked
up


TRT is indexed by destination IP addresses. Each TRT table entry consists

of a destination IP address, a next-hop IP address, and other information. The

outgoing interface to which a packet is forwarded can be determined from the next-

hop IP address. QRT is indexed by EF traffic identifiers. An EF traffic identifier

is composed of a source IP address, a destination IP address, a protocol identifier,

a source port number, and a destination port number. Each QRT table entry

consists of an EF traffic identifier, a next-hop IP address, and other information. In

this architecture the route map needs to be dynamically updated by QoS routing

protocols in order to support EF.

For all non-EF packets, only TRT is looked up to find the next hop, which is

exactly what the current IP networks do. Figure 3-1 illustrates how an EF packet

is forwarded at a router. After the packet arrives at the incoming interface, the

QRT at that interface is looked up. If there is a matched table entry, the packet

bypasses TRT and proceeds directly to the outgoing interface which sends the

packet to the next hop. If there is not a match in the QRT, the TRT is looked up

and the default shortest-path is used.

The main objective is to minimize the size of the QRT. Most of the EF traffic

is kept on the primary path. If the network is in normal conditions without any









congestion, all EF traffic will travel along the primary path and the size of ( -i;T

be zero. In this case, only Ti 1T is looked for all packets. On the other

hand., when the 1 : EF traffic on a ::. y path reaches the maximum

Iwed quota for Li i: : i: a (i routing protocol will be t:: 1 to

alternative paths new EF streams. 7 table entries are inserted into (f:!T for

the duration ('A the traffic streams. It should be stressed that only the overload

portion (." the EF traffic is routed via QRT along the alternative .Ai and this

portion of the *i i : will switch back to the :-' i *y path whenever possible.

3.3 Admission Control

task of admission control is to determine whether a new EF tr. :',c should

be accepted into the network or rejected. In our routing architecture, the admission

control and the '. .-' routing is ch.( related. In if the admission control

function : : out that the :::: path does not ::iA :)rt the new traffic, it will

the Q.. routing function to :*** an alternative path. If the C( *. routing

function i : : such a !: the admission control : 1 the t: H: otherwise, it

the traffic.

Admission control is done :-"'7 for the EF traffic, which receives assured

bandwidth and fast forwarding under our routing architecture. T:1. signaling

process starts from the source router and follows the p: :::: path towards the

destination router. T'. 2 .* r i F '''I.UES TI, c carries:

Ti.. traffic identifier (source IP address, destination IP address, protocol
id :i ::, source port, and destination port),

T]. service class identifier (EF),

TU- band idth ir.- 'ement B.

In order to assist the admission control, each router keeps track of its resource

availability. Two variables are maintained for each outgoing ::- :-

EF,,: EFT1,a is the maximum sustainable bandwxidthi allowed to be used for
sending I traffic : : this interface









EFgg: EFagg is the .'i-:-regated bandwidth currently used by all EF traffic on
this interface.

EFmax is set at the configuration time, while EF,,gg is measured at run time.

When a router receives a REQUEST, it uses TRT to find the outgoing interface to

the next hop on the primary path. A simple acceptance test is performed at the

outgoing interface to see if there is enough bandwidth for the new traffic.

If B < EFmax Bagg,

the REQUEST is sent to the next hop.

If B > EFmax Bagg,

the traffic can not be admitted by using this outgoing interface. A QoS routing

protocol is t lii.--. -1I to find an alternative routing path. If an alternative path

is not found, a REJECT message is sent to the source router that rejects the

traffic or retries the admission control after certain delay. On the other hand, if

the REQUEST successfully arrives at the destination router or the QoS routing

protocol finds an alternative path, an ACCEPT message will be sent to the source

router. The source router will notify the source host to send data traffic.

3.4 QoS Routing

If the primary path has the bandwidth to support the new EF traffic stream,

the QoS routing protocol is not tlii.--. 1 II by the admission control. All data

packets will follow the primary paths directed by TRT because there is no matched

table entry in QRT. Under congestion conditions, however, an intermediate router

may not have the required bandwidth. As shown in Figure 3-2 (b), suppose i fails

the acceptance test at the outgoing interface connecting to j. The corresponding

link (i, j) is called an infeasible link, which is represented by a dotted line. A link

that passes the acceptance test is called a feasible link. The admission control

signaling can not proceed along link (i, j), and a QoS routing protocol is activated.










Ss OS s S s

REQUISI $ACCEPT data
REQUEST
RQE R ROUIlNG- ROUTING C dataX
m m
k k _3 X ACK k m m
SACK j j

ACCEPT \\


d d d d d
(a) (b) (c) (d) (e)

Figure 3-2: QoS routing



The proposed routing architecture is independent of any particular QoS routing

protocol. For the purpose of completeness, only one QoS routing protocol has

been implemented in this thesis to show how it fits in the architecture. One big

advantage of the protocol is that it relies only on the local state stored at each

router, which makes it scalable and easy to implement. The basic idea is as

follows: When an infeasible link is encountered, it is considered as an indication

of local congestion. The QoS routing protocol tries to find an alternative path by

detouring around the infeasible link. Without the knowledge about the extent of

the congestion, the protocol branches out towards multiple directions and searches

multiple paths for one that can support the new EF traffic.

In Figure 3-2 (c), i sends out ROUTING messages along all .i11i ient feasible

links. i is called the branching point. Apparently, a ROUTING message should not

be sent to the link from which the REQUEST was received, and it will not be sent

to (i,j), which is an infeasible link. A ROUTING message carries two IP addresses:

bpAddr, which is the address of the branching point, and nbAddr, which is the

address of the neighbor that receives the message. It also accumulates the delay of

the path it traverses.

After a ROUTING messages arrive at the neighbor node k (or m), it is routed

by TRTs from there on. Hence, the ROUTING message follows the primary paths









from k (or m) to the destination router. This has a very important implication:

in order to store an alternative path, it is sufficient to add a single table entry

in the QRT at i to direct traffic to k (or m). From k (or m) on, TRTs will be

used. Similar to REQUEST, a ROUTING message causes an acceptance test to be

performed at every router it traverses.

The ROUTING message is sent to the next hop only if the acceptance test is

passed. Therefore, if the ROUTING message successfully reaches the destination

router, an alternative path for the new EF traffic is found, the path that the

message has just traversed is. In this case, an ACK is sent back to the branching

point i, whose IP address is bpAddr that was carried in the ROUTING message.

The ACK copies nbAddr and the accumulated path delay from the ROUTING

message. Upon receipt of the ACK, i inserts a table entry in the QRT at the

incoming interface from which the REQUEST was received. The next hop in the

entry is set to be nbAddr. Also stored in the entry is the delay carried back by

ACK, which is the total expected delay for EF traffic on the alternative path. In

addition, i sends an ACCEPT message to the source router to admit the traffic.

As Figure 3-2 (d) shows, the source router will notify the source host. As

shown in Figure 3-2 (e), the data packets follow the primary path until it reaches

the branching point i, where the QRT at the incoming interface directs the packets

away from the primary path. Once the packets reach the neighbor router k,

they are again routed by TRTs. If multiple ROUTING messages arrive at the

destination router, then multiple alternative paths are found and multiple ACKs

are sent back to the branching point. When the branching point receives an ACK

and finds that there is already a table entry in the QRT for the EF traffic stream,

it checks if the delay in the ACK is smaller than the delay in the entry. If it is









smaller, the next hop in the entry is replaced by the nbAddr value in the ACK.

Therefore, the best found alternative path will be used. 1

When a router receives a ROUTING message, if the acceptance test fails,

it sends a NACK message back to the branching point. If the branching point

receives a NACK from every ACK sent out, it concludes that the QoS routing

protocol fails in finding an alternative path. A REJECT message is sent back to

the source router, indicating that the traffic can not be admitted at this moment.

The above routing protocol allows only one branching point to deviate from

the primary path. More sophisticated design may allow multiple branching points.

When a ROUTING message reaches a router that fails the acceptance test, the

router can branch again and send ROUTING messages to the neighbors other than

the one pointed by TRT. In such a design, every branching point needs a table

entry in QRT in order to store the alternative path

In order to cancel the alternative path and switch back to the primary path

whenever possible, the branching point periodically sends CHECK messages

down the primary path to see if the primary path can now support the EF traffic

stream. It is a mini-version of admission control. If the CHECK message passes the

acceptance test at all intermediate routers and successfully reaches the destination

router, the source router will be instructed to not send KEEPALIVE. The EF

traffic will automatically follow the primary path when the alternative path times

out.



1 An ACK for an alternative path with smaller EF d. 1li- may arrive later be-
cause the control messages are not EF traffic and hence may experience a different
d. 1 i









3.5 Sunmmary

chapter :: cs the new\ PAP routing architecture ::: : v domains

in detail. i .. PAP .- .... O.col can be used to find alternate routing *1i for

lF i` dite Forwarding traffic streams when the primary : :: protocol fails at

a branching point. Support for admission control and I-.'0* routing has also been

integrated in the new architecture to route Expe :ci Forwarding traffic class with

guaranteed bandwidth and minimum i '

i : next chapter describes a simulation that has been implemented to

demonstrate the advantage of the above : .:- ... .1 routing protocol in use with the

r. '. .-v domains. It .... ..-es the new protocol PAP with the traditional routing

protocols like the shortest .'. routing with I to the admission ratio (number

of requests that are admitted) and also considers the f. '" ce affected due

to the number of IT entries I1 sited 1. admitted flow on average. A GUI has

also been described which i 1 ---.1 graphically, the network topi 1 ,. source

and destination nodes selected and the I :'b as generated the two c< :::. :1

protocols. It also shows the branching point in case when the acceptance test fails

at a certain node along the shortest path and displays the i0 path ( as generated

by the new QoS protocol) from the branching point to the destination node.















CHAPTER 4
SIMULATION

This chapter describes the simulation and the GUI that has been implemented

to demonstrate the advantage of the PAP QoS routing protocol in the new routing

hierarchy for the differentiated services domains.

4.1 Overview

The simulation generates a number of network topologies based on the

Power-Law model. Each link is assigned randomly a link success probability. It

is the probability of the link that it will pass the acceptance test. A large link

success probability corresponds to a light load condition thus increasing the

probability that the particular link will be able to forward the traffic stream.

A low link success probability on the other hand corresponds to a heavy load

condition[2]. The network topology can be generated using either the Inet or the

Waxman topology model, which are described later in this chapter. For each of

the topologies generated, several thousand requests are generated which are routed

from a specific source to destination. The source and destination are selected at

random or can be input implicitly as a parameter. For this particular set of source

and destination nodes, the new routing protocol PAP is compared with the shortest

path routing protocol. The basis of comparison for the two protocols is:

Admissionratio (percentage of requests that are admitted)
AverageRTentries deposited per admitted flow(for PAP).

The GUI that has been implemented uses the same simulation design, but offers

several facilities with respect to generation of the topology by allowing configura-

tion of its parameters like the number of nodes, type of topology generator, the










out degree exponent value for Waxman model, minininium and maximum. -* 1 1 '

minimum and maximum link bandwidth. It generates a single request for a : :

source and destination node that can be selected by the user. It then displays

the path as generated by the shortest :1 routing protocol. If at certain point

along the shortest :i .i the acceptance test :- the*nthe ( ." routing :.: .1 wcol is

I- -' and the remaining ). "' path h* th l the branching point to the destination

is also: .: d. If the bandwidth : .;::':cmcnts are such that the existing links are

not able to support the t I :": request, then the routing and the 1 only

to the branching point is shown. It also d; : 1 ; the comparison results of the two

protocols.:' simulation is thus modelled in two parts.
1. Generate a single network topology by using the XWaxman t -- ology genera-
tion method,; y the source and destination for which the path is to be
found, i* a single 1re with the bandwidth requirement for the tr.h:' c
and select the protocol to be used.

2. Generate several network to ologies based either on the Inet model or the
Waxman model. Si ::, the number of requests to be generated along with
the min and max bandwidth and 1. values. Ti source and destination are
taken at random for each : :t.

: on results' the second simulation ;. :-t are shown in terms of the

factors stated above.

A brief overview of 1 generators and the -. : -lawi model has been

provided to get a brief knowledge of. .. I....- 7 generation methods used in the

i:::l.1 : : : and how the link success probabilities are : I- : 1 to the nodes in

the network.

4.2 Network Topology Generation Methods

internet can be decomposed into connected sub networks that are under

: :e administrative authorities. TI : sub networks are called as domains or

autonomous systems. I. -h the 1.. .. of the Internet can be studied at two

levels of granularities. At the router level, each router is represented by a node









and each link between the routers by an edge. At the inter-domain level, a node

represents each domain and each edge is an inter-domain connection. Protocols

are developed for both inter-domain and intra-domain communication. Network

protocols are designed to be independent of the underlying network topology.

While topology should not have an effect on the correctness of the protocol, it

does have a in i Pr impact on the performance of the network protocols[11]. Hence

topology generators are used often to generate realistic topologies in simulations.

These topology generators do not aspire to produce the exact replicas of the

current Internet, but they merely attempt to create network topologies that

embody the fundamental characteristics of real networks[12]. There are mainly

three categories of topology generators[11]:

1. Random,

2. Degree based,

3. Structure (hierarchical) based.

4.2.1 Metrics

The metrics that have been used to describe graphs are mainly the nodeout -

degree and the distance between the nodes. Given a graph, the out-degree of

a node is defined as the number of edges incident on that node. The distance

between two nodes is the number of edges of the shortest path between the nodes.

4.2.2 Random Topology Generators

The process of generating random topologies can be generally stated as follows:

Given an input of N nodes and a 2-dimensional plane of size n by m, first the

placement of the nodes is to be decided[3]. The nodes can be distributed uniformly

across the plane, or clustered around some region. The out degree for each node

is then decided, which is the number of nodes that it is connected to. After the

nodes are positioned and their out degree has been decided upon, the links are

to be identified to decide which nodes should be linked to which other nodes.









The probability of creating an edge (link) between two nodes can be uniformly

distributed or weighted by the Euclidean distance between them. The edges are

then added to the network until all the nodes have their out-degrees satisfied.

A minimum spanning tree can be built prior to the generation of other edges to

ensure that the graph is a connected graph. If the graph is disconnected then extra

edges can be added to nodes at random to ensure that the graph is connected.

Waxman model. Waxman introduced one of the most popular network models.

Waxman topology generator is a random graph topology generator. The generator

produces random graphs based on the Erdos-Renyi random graph model, but it

includes network specific characteristics such as placing the nodes on a plane and

using a probability function to interconnect two nodes, which is parameterized, by

the distance that separates them in the plane. The Waxman topology generator

uses the Euclidean distance between the nodes to govern their connectivity. It

starts by placing the nodes in a nxn plane. Once the nodes have been placed, it

calculates the probability of creating an edge between two nodes u and v using the

following probability function:

PFu,v) j( LiO

where

P(u, v) is the probability of linking nodes u and v,

d(u, v) is the Euclidean distance between u and v

L is the Euclidean diameter of the network 1 ,

a is the average out degree

3 determines the average edge length



1 Euclidean diameter is the maximum Euclidean distance between any two nodes
in the graph









Then a random number is generated between 0 and 1. An edge is created

between nodes u and v only if the random number is smaller than P(u, v) which

is calculated as above. Finally, a spanning tree can be connected to ensure that

the resultant graph is connected. The use of Euclidean distance now makes

the geographic distribution of nodes a factor in the topology. Thus Waxman is

concerned only with randomly generated networks. Waxman has been used in this

simulation GUI to generate such random network topologies with several nodes to

demonstrate the new routing architecture.

Inet model. The Inet model generates a topology by placing N nodes on an

nxn plane[3]. Each node is assigned and out degree based on Power Law 2. Then a

full mesh is used to connect the top 7r most connected nodes. For these nodes, 25'.

of their edges are connected randomly selected nodes with out degree 2. To create a

fully connected topology, the remaining nodes are either connected to one of these

nodes or connected to a node that can reach one of these r nodes. The Inet-1.0

model has a second phase where the top most connected nodes are expanded into

networks with r nodes each. This phase is used to expand the top most connected

autonomous systems into networks with router-level connectivity.

4.3 Simulation

4.3.1 Network Model

The network model used in the simulation is described below:

The simulation generates a random network topology based on the input

parameters given. The first part of the simulation in which the paths(shortest path

and/or QoS path) are graphically di-p lil- t1, a single topology is generated using

the Waxman topology generation method and a single request is considered. In

the second part where the simulation is run with several topologies and several

thousand requests, topology is generated using either the Waxman or the Inet

topology generation method.









The simulation takes as input the following parameters to model the network

topology:

Number of nodes
Number of requests

Number of topologies 2

Topology generation type (Waxman / Inet)
Minimum and Maximum bandwidth

Minimum and Maximum delay

For Waxman: the average outdegree a

A random number seed which will affect the assignment of links in the
Waxman model

The input parameters for a specific topology can be saved to a file and

later the parameters could be read from the file in order to re-generate the same

topology.

4.3.2 The Graphical User Interface

A view of the GUI that has been implemented to demonstrate the new routing

architecture is shown in Figure 4-1.

The main parts of the user interface can be stated as
1. The main display window The topology generated according to the given
parameters is di-i'l '1 in the main window.
2. Parameter Entry The input parameters stated above for the topology
generation are entered here
3. Multiple topology simulation parameters are entered below along with the
choice of topology type (Waxman / inet) and the number of requests

4. A text window which di-pliv the results of the simulation

5. The node information window which gives the properties of a selected node



2 For the first part of the simulation, the number of topologies = 1 and number
of requests = 1









































026 S Nodes

049 /(with id)


*17


02O 0 .io -28


'13


33 9

533 *39 *27


032
5 -
*22


19
46

Links


Node Information -

Node ID


Number of Links


Neghbours 2,5.40. 3
5 I 111II


Link Information
From Node 12


To Node, g


Get Link Informgion


Bandwidth


Delay F
6


Topology as generated by Waxman


model for the given parameters


Simublaon Help


I
7 i


Generate Topology

Generate Path


jrSmulalI


935



36 *23
34


L2





*47
037 4




*30 *1
t41:




f43


Figure 4-1: A view of the GUI implemented with all the component windows













































Figure 4-2: Network topology generated by Waxman method for 30 nodes with an
average out-degree of 3



6. The link information window which gives the properties for a specified link


The individual parts of the user interface are now described in detail:

Topology display window. Depending upon the parameters entered for the

simulation, a network topology is generated using the Waxman generation method.

The nodes are placed in a x y plane corresponding to the blank white area seen

on the display window.

Then using the Waxman probability function, the links are calculated and the

nodes along with the links between them are di-il '1 as shown in Figure 4-2.

The nodes are represented by blue circles and the links between them by gray


`25
021 t26


Z6 *23 01l
'17

2
211 0105 '28


'18

13 ^9

Nodes

027 /

4129
(1 1
\15
*22

I16

Links









































Figure 4-3: A denser network topology generated by Waxman method for 30 nodes
with an average out-degree of 5



lines. Each node is assigned a unique identity with an integer starting from 0 to the

number of nodes. Each node also has its corresponding ID di -p1 -i I1 besides it.

As stated previously, a higher value for the a out degree value for Waxman

will generate a denser network topology. This can be seen in Figure 4-3 which

shows a topology with all the same parameters as in Figure 4-2 but with a a value

of 5.

The Parameter entry window. The input parameters specified above will be

entered by the user in the parameter entry window as shown in Figure 4-4. The

default values for the input parameters are given in the following table

The bandwidth values for the links in the topology are assigned from the range

MinBandwidth MaxBandwidth and the delay values are assigned from the

range MinDelay Maxdelay. The average out-degree value for Waxman is given


"25
11 21 *26 0

f,6 23 *14
1':


22 0 11 5 P2 8





n139




'1
"29

,15
*22

'16
















- Topology Parameters

Number of Nodes 50

Rand Number Seed

AJpha Outdegree

Topology Type Waxman

Min Link Bandwidth 10

Max Link Bandwidth 110


Min link delay


Input parameters for Single
-- Topology, Single Request
Simulation




Always Generated by
Waxman


10


Max Link Delay ITOO


Figure 4-4: The parameter entry window with default values













Table 4-1: Default Values for Input Parameters


Parameter Default Value
Number of Nodes 50
Random Number seed 333
Alpha out-degree (Waxman) 3
Minimum Link Bandwidth 0
Maximum Link Bandwidth 100
Minimum Link Delay 0
Maximum Link Delay 100










Simulation Parameters

Number of Req Parameters for multiple topology,
multiple request simulation
Number of
Topologies
T Waxman Choice of Inet I Waxman
Topology Type
O net topology


Figure 4-5: The simulation parameter entry window with default values



by the parameter alpha. A higher value for a will result in denser topology while

a lower value will give a sparse topology. These values are also used when multiple

topology, multiple request simulation is run.

Simulation parameter entry window. Figure 4-5 shows the input boxes for the

parameters required for the multiple topology, multiple request simulation. It takes

as input the number of topologies to be generated, the number of requests and the

choice of the topology generation method to be used (Waxman/inet). The other

parameters are the taken from the parameter entry window as described above.

This generates a simulation with several topologies and chooses a source

and destination node at random from the generated topology for each request.

It generates several thousand requests as specified by the input parameter for

that particular source and destination and then compares the results of the new

protocol with the shortest path routing protocol, by calculating the averages of the

comparison parameters for the thousands of requests. The default values for the

window are given in the following table

Table 4-2: Default Values for Multiple Topology, Multiple Request Simulation
Parameters

Parameter Default Value
Number of Requests 6000
Number of topologies 10
Topology Type Waxman










Help

Exit
Number of Nodes


Figure 4-6: Reset parameter values to default for new simulation


Node Information

Node ID 20

Number of Links Node properties for any
S-clicked node in the
Neighbours 6,11,12,27;




Figure 4-7: The node information window displaying properties of a clicked node



After a path is generated or the simulation is run, the values in both the

parameter entry windows can be reset to the default values given in the tables by

clicking "Reset" from the "Simulation" option on the GUI as shown in Figure 4-6

The Node information window. The node information window di- pl' i the

following properties for a given node:

Node ID

Number of links for the node (its out degree)

Its neighbors


The neighbors of the node are the IDs of the nodes in the topology to which it

has a link. When any node in the topology is clicked, its corresponding properties

would be di -1 i 1 in the node information window. The window is shown in

Figure 4-7.

The Link information window. The link information window accepts the start

and end points of a node which are the node IDs of the nodes between which the









Link Information

From Node 12 End nodes of any valid
To Node -- link in the topology
To Node p19

Get Link Information

Bandvidth Properties for the link

Delay 6 specified



Figure 4-8: The link information window displaying properties of a specified link



link exists. Given the "start" and "end" nodes(IDs) of a link, clicking the "Get

Link Information" window will display the following properties of a link:

Bandwidth

Delay


The bandwidth for a link is taken from the range MinBandwidth -

MaxBandwidth and similarly the delay from the range MinDelay MaxDelay,

which are specified in the parameter entry window. This information is useful to

check and verify whether a particular link can pass the acceptance test for the

incoming request. The information can demonstrate how the new protocol chooses

an alternate path over the shortest path when the shortest hop from the branch-

ing point cannot support the requested bandwidth. Figure 4-8 shows the link

information window.

Selecting the source and destination nodes. For the single topology, single re-

quest simulation, once the topology has been generated, the source and destination

for the generated request can be selected by clicking the "Generate Path" button

on the parameter entry window.

The following window is di-I-h 1 as shown in figure 4-9. The source and

destination nodes can be specified along with the bandwidth requirement for the












Specify request
Enter Source Node ID F3 Bandwidth bandwidth
requirement
Enter Destination Node ID 11 Protocol Shortest Path Routing
C PAP Routing

OK | Cancel |

Select protocol to
Select source and destination be used
for which path is to be found


Figure 4-9: Selecting the source and destination nodes. The bandwidth require-
ment for the request is also specified.


request to be routed from the source to the destination. The request corresponds

to an EF traffic stream to be routed from the source to the destination with the

specified bandwidth requirement. The requirement states that every hop(link) on

the generated path from the source up to the destination should have a bandwidth

greater than the requirement specified, to ensure guaranteed delivery of the the

EF traffic stream. The link that has a bandwidth less than the specified required

bandwidth for the request cannot be used on the path.The protocol to be used for

the routing can be chosen here.

If ShortestPathRinl'ii.I protocol is chosen, then if any of the links in the
shortest path calculated by the protocol, does not pass the acceptance test,
then the protocol fails and the partial path from the source to the node of
failure is shown. The link at which the test fails is also highlighted. This link
is called as an InfeasibleLink as stated in the PAP protocol description in
chapter 3. An example later in this chapter will demonstrate such a case.

If the new PAP QoS protocol is chosen, it starts of with calculating the
shortest path between the source and destination nodes. But if any link along
the path fails to satisfy the EF request, then the QoS protocol is tlii .-:. I as
described in chapter 3. It looks for alternates paths from the branching point
which would satisfy the EF request. If it finds any, then the alternate path is
shown along with the partial shortest path. If the protocol is not able to find
even an alternate path, then only the partial path is di-p' '1 with the link
of failure highlighted.




















































Figure 4-10: Algorithm for path generation by PAP / SPR



Algorithm.The algorithm to generate and display a path between the selected

source and destination is shown as in Figure 4-10

SPR and PAP are successful, if they find a path such that all links on that

path have bandwidths assigned > required bandwidth.

4.4 Path Generation by Shortest Path Routing-Example 1

An example path generation by shortest path routing is first shown.

4.4.1 Input Parameters

The input parameters for the sample path generation are as given in the table

below.


I :1 i ii .li' I r [ i.v r'rl :
Generate the Topology using Waxman
Set the domain STATE by assigning bandwidths to the links
Select the source and destination for routing
Select the protocol to be used for routing
Generate a request by specifying the bandwidth requirement
IF Shortest Path Routing chosen
{
Call SPR() to do shortest path routing
IF SPR is successful
{
Display the Shortest Path Generated by SPR
}
ELSE
{
Display the partial path and the link of failure
}
}
IF PAP chosen
{
Call PAP() to do the QoS Routing
IF PAP successful
{
Display the Partial Shortest Path Generated
Display the QoS Path Generated from branching point
}
















Table 4-3: Parameter Values for Example SPR Simulation


- Topology Parameters

Number of Nodes 50

Rand Number Seed

Alpha Outdegree

Topology Type Waxman

Min Link Bandwidth

Max Link Bandwidth

Mmin link delay O

Max Link Delay


Figure 4-11: The parameter entry window for the example SPR path generation


Parameter Value
Number of Nodes 50
Random Number seed 333
Topology Type Waxman
Alpha Out degree 3
Minimum Bandwidth 0
Maximum Bandwidth 100
Minimum Delay 0
Maximum Delay 100





















Figure 4-12: Selecting the source and destination for the example SPR simulation


The parameter input window corresponding to the values above is shown in

Figure 4-11.

Given these parameters, a topology is generated using the Waxman model for

50 nodes and an average out-degree of 3.

4.4.2 Selecting Source and Destination

Once, the topology has been generated, the source and destination nodes are

selected, for the EF stream has to be routed. The EF bandwidth requirement is

also specified and the protocol to be used which would be Shortest Path Routing

in this case. As an illustration of the path generation, the following table gives the

values selected:

Table 4-4: Parameter Values for Example SPR Simulation Source and Destination

Parameter Value
Source Node ID 24
Destination Node ID 26
Bandwidth 10
Protocol SPR



The window corresponding to the selections made is as shown in Figure 4-12

4.4.3 SPR Successful

When the "OK" button is clicked, the Shortest Path generation algorithm

will calculate a shortest path by the Dijkstra's algorithm from the source to the


Enter Source Node ID Bandwidth FT


Enter Destination Node ID 26 Protocol Shortest Path Routing
C PAP Routing

OK I Cancel
















Destination


*17


20 42170



*1


I- Topology Parameters





















Generate Path










Rur SmulatonI


812





044



419
i]6


Node Informaton

Node ID |

Number of Links

Ne0ghbous



nk Information
From Node F

To Node

Get Link Informa1on

Bndwidth F

Delay


Shortest Path between

node 24 and node 26


Path Successful Generated by SPR protocol
TotalPath Delay 179








Figure 4-13: SPR protocol successful.The shortest path generated for the specified

source and destination is shown in GREEN.The total delay is shown

in the text window below



destination. If the acceptance test is passed by all the links along the shortest


path, then the protocol is successful. In this case, the topology window will display


the calculated shortest path with a green highlighting, showing all the links along


the path. For the example simulation input specified above, the shortest path


calculated is as shown in Figure 4-13. The source and the destination have been


shown in the figure. The green line represents the shortest path between the source


and the destination nodes, by which the EF traffic will be routed with guaranteed


bandwidth.


r 023


*'*2


Simulation Help


"13


30 *1 -*





*11 *22
'^4 "'S_.j .2





Source


0347
POWj "









This case results when the Shortest Path routing is successful and the EF

traffic stream is routed successfully from the source to the destination. If the

routing is unsuccessful, the partial path is di-pl li-t 1 along with the link of failure.

An example will be dealt with in the next section.

4.5 Path Generation by PAP Routing Protocol-Example 1

In the previous section, successful routing using the Shortest Path routing was

described. The new routing protocol described will come into picture when the

Shortest Path Routing fails and the PAP QoS protocol is tlii'---- I. Hence in order

to see an example of the new routing protocol, the case in which the shortest path

routing fails is first considered.

4.5.1 Input Parameters

Here, a different scenario is considered with the input parameters taken as

shown in the table below:

Table 4-5: Parameter Values for Example PAP Simulation-Example 1

Parameter Value
Number of Nodes 45
Random Number seed 333
Topology Type Waxman
Alpha Out degree 2
Minimum Bandwidth 0
Maximum Bandwidth 100
Minimum Delay 0
Maximum Delay 100



4.5.2 Selecting the Source and Destination

The values for the source, destination and bandwidth requirements for the

generated topology are given by the table shown below:

4.5.3 PAP Successful

When the OK button is clicked, the output that is di-pl .i-' 1 in the topology

window is as shown in Figure 4-14.










Table 4-6: Parameter Values for Example PAP Simulation-Example 1


Source


*25
*21


N0


364
'34


*2





40'37 '4


*30 1


*33 @39 *27


*32
-15


Destination


Partial Shortest Path


Link of Failure


SPR Protocol Not Successful
Failed at link. 31 -> 11
Link Bandwidth = 7






Figure 4-14: Example 1: SPR protocol fails. Green line shows partial shortest path
and red shows link of failure


Parameter Value
Source Node ID 8
Destination Node ID 42
Bandwidth 10
Protocol SPR


*1J5 *28




















Figure 4-15: Using PAP protocol for the same topology with the same parameters.
The EF request has the same bandwidth requirement for the same
source and destination


As seen in Figure 4-14, the shortest path routing fails because, it has link 31

- 11 on the shortest path which cannot pass the acceptance test. The bandwidth

for link 31 11 is 7 whereas the requested bandwidth for the EF traffic was 10.

Hence SPR fails at node 31. Link 31 -> 11 is the InfeasibleLink as described

in chapter 3. Figure 4-14 shows the partial shortest path with green color and

the infeasible link with red. Also seen in the figure is the bandwidth of the link at

which the routing failed.

This necessitates the use of a QoS protocol which will guarantee that the

EF request will be routed to the destination node 42. The PAP protocol is then

lt 22ij- II which looks for alternate paths at node 31(branching point) which have

bandwidth greater than 10 and which can route the EF request. To see how it

works, the same scenario is considered with the same values for input parameters.

The PAP protocol is now considered for the same source and destination and the

same bandwidth requirement. Figure 4-15 show this.

When the OK button is clicked, the PAP protocol gets invoked when SPR

fails at node 31 as shown above. The path calculated by PAP protocol is as seen in

Figure 4-16.

The figure shows the path as generated by the PAP routing protocol, with the

shortest path section and the QoS path section shown with different colors. The


Enter Source Node ID Bandwidth O

Enter Destination Node ID 42 Protocol Shoest PathRouting
P o PAP Routing

OK Cancel




































Topology Parameters

Number of odes 45

Rand Number Seed

pha Outdegree 12

Topology Type 0Waeman

Mn Link Bandwidth J

Max Link Bandwidth 0


Min Ink delay c

Max Link Delay


Generate Topolo i

Generate Path












Run Simulation


Node Informaton

Node ID


Number of Links


Neighbours



Link lformaton
From Node

To Node e


Get Link Information


Bandwidth


Delay


Partial Shortest Path

QoS Path by PAP


[od Path Delay 1BS


Figure 4-16:


PAP successfully routes the same request for which SPR fails at link

31 -> 11. QoS path is seen in BLUE, starting from the branching

point (Node 31)


012
Branching
Point




344



*19


Destination


Im i 1ni'


i









text window below di pl'iv the total delay and the different path sections by node

numbers.

At node 31, SPR chooses path 31 -> 11, which fails, since it has a bandwidth

(7) less than the required bandwidth. The PAP protocol is tlii.-. t. which

searches for an alternate path from the branching point node 31. It finds a link 31

-> 4 which has a bandwidth (47) greater than the required bandwidth (10). This

can be verified by finding the link information for links 31 11 and 31 -> 4 from

the link information window. This is shown in Figures 4-17 and 4-18. Hence

the PAP protocol will find the alternate path from node 4 onwards till it reaches

the destination node 42. It can be seen that the path shifts back to the remaining

shortest path which is from 11 42 later. Since the links on the shortest path

from 11 onwards can support the request, the PAP protocol follows the shortest

path again. After reaching node 42, an accept message will be sent to the source

thus forming this new QoS path from node 8 to 42 will be followed for all EF

traffic from node 8 to node 42. RT entries are deposited at the intermediate routers

accordingly. The branching point in this case is node 31 as shown in Figure 4-16.

There can also be a possibility that the QoS protocol does not find an alter-

nate path at the branching point which would support the EF request by ensuring

a bandwidth greater than the requested bandwidth. In such a case, the source node

is notified accordingly, and the PAP protocol also fails. A corresponding message is



The next example shows a case where the SPR fails, PAP is successful, and

PAP chooses a path which is totally different from the initial shortest path which

SPR would have chosen.

4.6 Path Generation by PAP Routing Protocol-Example 2

Here, a second example is presented to demonstrate the PAP routing protocol.

The difference between this example and the previous one is that in the previous























Link Information
From Node 31


To Node 11


Get Link Information]


Bandwidth 7


Delay 65




Figure 4-17: Link information for link 31 11 to demonstrate why SPR fails at
the branching point.






Link Information
From Node 31


To Node f4


Get Link Information


Bandwvidth 4


Delay 21




Figure 4-18: Link information for link 31 t 4 to demonstrate why this alternate
path is chosen by PAP.









case, PAP shifts back to the shortest path after choosing an alternate path over

the SPR link of failure. Here in this example, the PAP follows a different path

altogether to the destination.

4.6.1 Input Parameters

Here, a different scenario is considered with the input parameters taken as

shown in the table below:

Table 4-7: Parameter Values for Example PAP Simulation-Example 2

Parameter Value
Number of Nodes 45
Random Number seed 333
Topology Type Waxman
Alpha Out degree 3
Minimum Bandwidth 0
Maximum Bandwidth 100
Minimum Delay 0
Maximum Delay 100



4.6.2 Selecting the Source and Destination

The values for the source, destination and bandwidth requirements for the

generated topology are given by the table shown below:

Table 4-8: Parameter Values for Example PAP Simulation-Example 2

Parameter Value
Source Node ID 25
Destination Node ID 16
Bandwidth 25
Protocol SPR


4.6.3 PAP Successful

When the OK button is clicked, the output that is di-pl it 1 in the topology

window is as shown in Figure 4-19.

As seen in Figure 4-19, the shortest path routing fails because, it has link 4

- 31 on the shortest path which cannot pass the acceptance test. The bandwidth




















251
*21


e*:
0:3


"20 4105 *28

*40

18

'0.37


31


*30 C1


t33 -39


'32
* 5


SPR Protocol Not Successful
Failed at link- 4 -> 31
Link Bandwidth= G


Figure 4-19: Example 2: SPR protocol fails. Green line shows partial shortest path
and red shows link of failure









Link Information
From Node 4

To Node 131

Get Link Information

Bandwidcth

Delay g98



Figure 4-20: Link 4 31 has a bandwidth 6.Hence SPR fails at this link



for link 4 -> 31 is 6 (Figure 4-20), whereas the requested bandwidth was 25. Hence

SPR fails at node 4. Figure 4-19 shows the partial shortest path with green color

and the link of failure with red. Also seen in the figure is the bandwidth of the link

at which the routing failed.

The PAP protocol is t i- 1 I which looks for alternate paths at node 4

which is the branching point in this case. For the same source and destination

and bandwidth requirement, the PAP protocol generates the path as shown in

Figure 4-21.

In this case, however, the QoS path is completely different from the shortest

path after the branching point unlike example 1. The path from the branching

point is 4 -> 39 -> 27 -> 16; since link 4 -> 39 has a link bandwidth of 79 as shown

in Figure 4-22. The initial link chosen by shortest path routing at which it fails

(4 -+31) has a bandwidth of 6 as shown in Figure 4-20

The above two examples demonstrate the use of the new routing protocol

especially for the EF traffic in case of Differentiated Services, which requires

guaranteed delivery. In such cases, the new protocol will try to find out alternate

paths in order to guarantee the flow of EF request even if shortest path routing

fails at a certain point.
















Source


- ode Information

Node ID i


Numberof Links
-17


20 Ng, ours

*40 Link Informion

From Node 1

To Node F
3







019


Destination Partial Shortest Path


- QoS Path


Figure 4-21: PAP successfully routes the same request for which SPR fails at link

4 -+ 31. QoS path is seen in blue, starting from the branching point

(Node 4)



Link Information


From Node


4


To Node 39


Get Link Information


79


Figure 4-22: Link 4 -+ 39 has a bandwidth 79. Hence PAP chooses it for the alter-

nate path.


Simulation Help


I

I



I" r 1,,

I ,



I ,


Generate Path


030 V1


Branching Node : 4


I

I ,


J ,, -'









4.7 Multiple Request Multiple Topology Simulation

The first part of the simulation discussed in the previous section generated a

single topology and then compared the Shortest Path Routing and the new PAP

protocol by generating a single request with a specified bandwidth requirement.

The source and destination were chosen by the user and then the paths as gener-

ated by the two protocols were di- pl i-- 1 graphically on the topology generated.

In the second part of the simulation, multiple topologies are generated.

For each topology, a random source and destination node are selected from the

topology and several thousands of requests are generated to be routed from the

selected source to destination. Both the protocols are run for each topology and

each request and then the comparison results are di- p1 'i-, I in the results window

below. The two protocols are compared on the basis of LinkSuccessRatio which

is the percentage of requests that are admitted. The results of comparison will be

considered in the next chapter.

4.7.1 Simulation Steps

This section describes step wise how the multiple topology, multiple request

simulation has been designed.

Input. The simulation takes as input the same parameters as the simulation in

the previous section, with the following additional parameters:
Number of Topologies
Number of Requests
Topology Type (Inet/Waxman)

Algorithm:.

The simulation follows the algorithm given in Figure 4-23

The requests that are generated for each topology are not based on the

bandwidth requirement, but on the link success probability for each link in the

topology. For each value of link success probability ranging between 0.1 and









50















Take Input Parameters

For every topology DO
{
Generate Topology

Generate the specified number of requests

For link success probability from 0.1 to 1.0 DO
{
For each request DO
{
Select a random Source and destination

Set the link probabilities for all links

Call SPR() to do shortest path routing

If SPR is successful
I
Collect results for this request
(path and other statistics)

Call PAP to apply the PAP routing protocol

If PAP is successful
I
Collect results for this request
(path and other statistics)






I
For link success probability from 0.1 to 1 DO

Compute the link success ratio for both protocols

Compute the average RT entries for PAP

Display the results


Figure 4-23: Algorithm for the multiple topology, multiple request simulation










1.0(in increments of 0.1), each link is assigned a link success probability which

decides whether the link will pass the acceptance test or not.3 This domain state

is calculated each time for each request generated for each topology.Thus for each

different request generated, the link success probabilities will be different and hence

for each of the 10 iterations of the simulation run for link probability values from

0.1 to 1.0,

the average success ratio is calculated by the formula

successRatio "'Success
numRequests

where

numSuccess = number of successful routing attempts

numRequests = number of requests generated

The average number of RT entries deposited is calculated by the formula

avgRTentries nURentries
numSuccess

where

numSuccess = number of successful routing attempts

numRTentries = number of routing entries deposited for the successful routing

attempt

The final values for these two parameters for values of link success probabilities

ranging from from 0.1 to 1.0, are then di-p '1. These values form the basis for

comparison for the two protocols.

4.7.2 Multiple Topology, Multiple Request Simulation-Example

This section gives an example of a Multiple Topology, Multiple Request

Simulation.


3 The bandwidth in this case is 0 for all links









Input Parameters.

The following table gives the input parameters for the example simulation:

Table 4-9: Parameter Values for Multiple Topology Multiple Request Simulation
Example


This is shown in Figure 4-24.

Running the simulation. When the "Run Simulation" button is clicked, the

simulation is t lii.-. t. which then follows the algorithm given in the previous

section. After the requests are generated and processed for all topologies, the

results are di-1 i' '1 in the text window as shown in figure 4-25.

As seen in the Figure 4-25, the two protocols are compared on the basis of link

success ratio with values for link success probability ranging from 0.1 to 1.0. This

example shows the simulation run with the Waxman topology generation method.

The simulation can also be run with the Inet topology generation method.

The results for the simulation with same parameter values but run with Inet

topology generation method are as shown in Figure 4-26.

This chapter described the simulation that has been implemented to demon-

strate the new routing architecture and the use of the new PAP routing protocol.

It also presented its advantages over the traditional Shortest Path Routing. It was

seen that for traffic like EF traffic in Differentiated Services domains, guaranteed


Parameter Value
Number of Nodes 50
Random Number seed 333
Topology Type Waxman
Alpha Out degree 3
Minimum Bandwidth 0
Maximum Bandwidth 100
Minimum Delay 0
Maximum Delay 100
Number of Topologies 10
Number of Requests 6000
















Numbe


Rand

Alpha


-Topology Parameters

r of Nodes


Number Seed

Outdegree


Topology Type Waxman

Mmin Link Bandwidth 10


Max Link Bandwidth


Min link delay 0


Max Link Delay [


Generate Topology

Generate Path
- Simulation Parameters

Number of Req |6000


Number of
Topologies


10


Topology Type ( Waxman
0 Inet


Run Simulation





Figure 4-24: The input parameters for the multiple topology, multiple request
simulation example


SPR Protocol I Link Success Probability : 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0


Success Ratio 0 O 01 0.02

PAP Protocol: Link Success Probability 0 1 0.2


0.03 0.05 0.09 0.14 0.23 0.38 0.62 1.00

0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0


Success Ratio 01 0.02 0.03 0.0 0.10 0.17 0.28 0.44 0.68 1.00
Average RT Entries 0.01 0.06 0.08 0.13 0.15 0.16 0.17 0.15 0.09 0.00





Figure 4-25: The results of the multiple topology, multiple request simulation ex-
ample using Waxman. The protocols are compared on the basis of
link success ratio and average number of RT entries.










SPR Protocol: Link Success Probability 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
Success Ratio : 0.01 0.02 0.04 0.07 0.11 0.19 0.30 0.45 0.68 1.00
PAP Protocol. Link Success Probability : 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
Success Ratio 0.01 0.02 0.04 0.09 0.15 0.25 0.39 0.56 0.78 1.00
Average RT Entries 0.05 009 016 020 024 026 024 020 013 000



Figure 4-26: The results of the multiple topology, multiple request simulation
example using INET


delivery can be assured with the new protocol, by searching for alternate paths in

case the shortest path routing fails.

4.8 Summary

The chapter describes the simulation and the GUI that has been implemented

to demonstrate the new routing architecture. The SingleTopolb.i'i, SingleRequest

simulation di-pl 'i the paths as generated by the shortest routing protocol and

the PAP protocol for a selected source and destination for a requested EF traffic

stream. The MultipleTopolb.iii, MultipleRequest simulation gives statistical results

to compare the PAP protocol with the shortest path routing by generating several

thousand EF stream requests on a number of topologies. The next chapter will

discuss the results of comparison between the two protocols.















CHAPTER 5
CONCLUSIONS AND FUTURE SCOPE

The previous chapter described the simulation which demonstrated the use of

the new routing architecture and a sample protocol(PAP) that can be used with

the architecture to guarantee timely delivery of EF traffic in Differentiated Services

domains.

5.1 Comparison

The last section in the previous chapter described the comparison of the

PAP protocol with the traditional Shortest Path Routing. Several topologies were

generated with several requests routed on randomly selected source and destination

nodes. The protocols were compared on the following two parameters:
1. Average Link Success Ratio

2. Average Number of RT Entries

The link success probability values were varied from 0.1 to 1.0 with increments

of 0.1 and for each value, the above mentioned two parameters were calculated.

Figure 4-25 and Figure 4-26 shows the values for these parameters for Waxman

and Inet model respectively. The average result of the 6000 requests gives a data

point.

5.1.1 Link Success Ratio

The values for the link success ratio have been given in the following table for

the example simulation given in the previous chapter

From the values in the table, we observe that the link success ration for the

proposed QoS routing algorithm (PAP) is higher than the link success ratio for

Shortest Path Routing for link success probability values over 0.3, thus showing















Table 5 1: Link Success Ratio Values for PAP and SPR Using Waxman


Table 5 2: Link Success Ratio Values for PAP and SPR Using Inet


Link Success Probability SPIR PAP
0.1 0.01 0.01
0.2 0.02 0.02
0.3 0.03 (:::3
0.4 0.05 0.06
0.5 0 :: 0.10
( 0.14 0.17
0.7 0.23 0.28
0.8 0.38 0.44
0.9 0.62
1.0 l.- -i 1.00


Link Success Probability SPR PAP
0.1 0.01 0.01
0.2 0.02 (:
0.3 0.04 0.04
0.4 0.07 (-
0.5 0.11 0.15
0 '. 0.19 (
0.7 0. ::
0.8 0.45 0.56
0.9 0 0.78
1.0 1 -:: 1.00










0 1.2
PAP with Simple QoS Routing

0 1

C 0.8


0.6




a 0.2 -


00
0.4 0.5 0.6 0.7 0.8 0.9 1
link success probability

Figure 5-1: Admission ratios per admitted flow


that the new protocol does improve the number of requests that are admitted

successfully. Comparing with traditional routing, PAP thus improves the admis-

sion ratio (percentage of requests that are admitted) significantly, up to 110' .

Figure 5-1 shows this.

5.1.2 Average Number of RT Entries

The new protocol achieves this improvement in admission ratio at a small cost.

This can be seen from the values of the Average Number of RT entries deposited

for the PAP protocol. The table below gives the value for Average RT Entries for

the example simulation described in the previous chapter.

From the values in the tables, it can be seen that PAP incurs a very small cost

with respect to the number of RT entries deposited. In the worst case, it deposits

0.51 FigureRT entry per admitted flow on average. The reason for the less-than-one

average is that, for requests that can ae supported by the primary paths, PAP is

equivalent to traditional routing (TRT only), and no QRT entry is required.
equivalent to traditional routing (TRT only), and no QRT entry is required.















Table 5 3: Average IfT Entries Values for PAP Using Waxirnan


Table 5 4: Average 1RT Entries Values for PAP Using Inet


0.1 0.05

0.3 0.16
0.4
0.5 0.24

0.7 0.24
0.8 1 '
0.9 0.13
1.0 0.00


Link Success Probability Average l' i
0.1 0.01

I ; I : ,
0.4 0.13
I 0.15
0.16
0.7 0.17
0.8 0.15
0.9 0.09
1.0 0.00










0.6
PAP with Simple QoS Routing

c 0.5


S 0.4
-e

C 0.3


0 0.2


o 0.1

0 ---------------------
0.4 0.5 0.6 0.7 0.8 0.9 1
link success probability

Figure 5-2: QRT entries for PAP per admitted flow


This improvement can be seen in Figure 5-2.

5.2 Conclusion

In the paper by Dr. C'. i1 et al.[2], a new routing architecture for DiffServ

domains has been proposed. It integrates the traditional routing, QoS routing,

packet forwarding, and admission control. The admission control and QoS routing

ensure that the EF traffic admitted to the network is limited under the maximum

allowed quota so that the EF traffic al-i- receives assured bandwidth and low

d. 1 i-. Much care has been taken to reduce the size of the QoS routing tables. In

particular, the proposed QoS routing protocol requires only one table entry at a

branching point to store an alternative routing path.

The simulation and the GUI that has been implemented helps demonstrating

the advantages of the new protocol over the traditional protocols like the shortest

path routing. It di-pli .1' graphically how the protocol searches for alternate paths

when the shortest path routing fails at a certain node in the network. With the









help of the GUI, this can be verified by looking at the link bandwidths for the '-.:

of failure or the alternate links chosen by the new protocol. C<( : 4 : :: these two

protocols on the basis of the link success ratio gives a view of how the new 1x x. col

improves adminission control at a low cost. : 0 G UI gives a graphical view of

the paths generated thus giving an idea of the 0 >S routing in the internet w\0orld,

providing more opportunities i:. research in this area.



thesis discusses a new protocol and its implementation for the DiffServ

domains but it deals with the Expedite Forwarding T: 1 : P11 only. In chapter 2,

two classes of PHBs were seen the E : .:*. Services domains:

1. Expe ::i Forwarding (EF)

2. Assured Forwarding (AF)

T1 protocol proposed can be extended or modified to handle AF traffic

also. AF traffic defines : f : :: classes each with three
preccndences. This is mainly to provide :i : :l: levels of services to customers

and applications. Considering this, the protocol and/or the implementation can be

mo :i / extended to handle AF trE.i : class for each < the for\w\arding classes

that it defines.

Also, even for the EF t: I : class, the : I 1 can be c( :: : with several

other traditional routing protocols apart from the "1 test Path Routing and this

can be demonstrated 1- enhancing and < i- : :::; the implementation / GUI. This

could give a clear view of whether the new routing architecture does provide a

considerable a(d :::! :I- over most of the currently used routing protocols.

In this implementation, the PAP routing protocol uses the basic :.. .... of

finding a shortest, 1- from the source to the destination shortestt path algorithm)

even after finding an alternate :. It tries to 2.: : back to the original shortest

path to see if it can now support the requested bandwidth. If being compared









with other routing protocols, the method of finding the route to the destination

after the alternate path has been found from the branching node, could be made

more efficient than using the shortest path only. The approach could be recursively

applied at each hop along the path, which would be completely independent of the

initial shortest path, thus -i-i: -1ii-; the use of multiple branching points instead of

one.

The simulation uses only the Waxman and Inet topology generation methods.

Waxman has been used for the simplicity of displaying the topology since Waxman

provides well defined co-ordinates for the nodes that could be plotted. But there

are many other network topology generators which could be used in order to

simulate a more realistic network topology to model the DiffServ domain. Some of

the popular network topology generators that could be used are:
1. The NS-2 simulator from Stanford University[4],

2. The GT-ITA\ topology generator from Georgia Institute of Technology[13],

3. The BRITE topology generator from Boston Unil. ily[7],

Such enhancements could open new v--iv for further research in the proposed

protocol and its implementation.















REFERENCES


[1] Berghoff, G., "Introduction to QoS and Differentiated Services," Application
to Nokia's IP RAN, May 2002, Available at URL:
www-i4.informatik.rwth-aachen.de/Kolleg/Vortraege/Berghoff .pdf
Last Accessed: March 2004

[2] C'h. ii, S., Ling, Y. and C'!. ii, S., "A New Routing Architecture for DiffServ
Domains" International Conference on Communications, Internet and
Information T h, i, -. .,/;/ (CIIT 2003), Scottsdale, AZ, Nov 2003

[3] C'!h i;,, J., C'!. i, Q. and Jamin, S., "Inet: Intenet Toplogy Generator,"
Technical Report UM-CSE-TR-433 00, Available at URL:
http://topology.eecs.umich.edu/inet/inet-2.0.pdf
Last Accessed: March 2004

[4] Greis, M., "Tutorial for the Network Simulator "ns"," Information Sciences
Institute, Available at URL:
http://www.isi.edu/nsnam/ns/tutorial/index.html
Last Accessed: March 2004

[5] Kasari, A., "An Architecture for Differentiated Services," Research Seminar
on IP Qon.il;l Of Service, Department of Computer Science,University of
Helsinki, Oct. 2000, Available at URL:
http://www.cs.helsinki.fi/u/kraatika/Courses/QoSOOa/kasari.pdf
Last Accessed: March 2004

[6] Manner, J., "Short Overview of Differentiated Services," Oct 2003, Available
at URL:
www. cs helsinki fi/u/jmanner/Courses/seminar_papers/diffserv. pdf
Last Accessed: April 2004

[7] Medina, A., Lakhima, A., Matta, I. and Byers, J., "BRITE: Universal Topol-
ogy Generation from a User's Perspective," Computer Science Department,
Boston U,.:;. ,./; Apr 2001, Available at URL:
http://www.cs.bu.edu/brite/user-manual/BritePaper.html
Last Accessed: March 2004

[8] Microsoft Corporation, \ i rosoft Windows 2000 Server: A Short Overview
of QoS Mechanisms and their Interoperation" White Paper, Nov 1999,
Available at URL:
http://www.microsoft.com/windows2000/docs/QoSMech.doc









Last Accessed: March 2004


[9] Nortel Networks, "Introduction to Quality of Service(QoS)," White Paper on
Q;,.il;l of Service, 2003, Available at URL:
www.nortelnetworks.com/products/02/bstk/switches/bps/collateral/56058.25
022403.pdf
Last Accessed: March 2004

[10] Schildt, H., MFC p' '1. 'r',, ii':i, from the ground up, 2nd Edition,
Osborne/ IcGraw-Hill, New York, 1998.

[11] Tangmunarunkit, H., Govindan, R., Jamin, S., Shenker, S. and Willinger,
W., "Network Topologies,Power Laws and Heirarchy," Technical Report
USC-CS-01 746, Available at URL:
http://www.isi.edu/~hongsuda/publication/ccrNote01_2.ps
Last Accessed: March 2004

[12] Tangmunarunkit, H., Govindan, R., Jamin, S., Shenker, S. and Willinger, W.,
\. i.- ork Topology Generators: Degree Based vs. Structural," in Proceedings
of AC\f[ SIGCOMM'02, Pittsburgh, PA, Aug 2002. Available at URL:
http://www.acm.org/sigcomm/sigcomm2002/papers/topogen.pdf
Last Accessed: March 2004

[13] Thomas, M., Edwards, E. and Bhattacharjee, S., "Modeling Topology of
Large Internetworks," College of CorTnj''nl.II Georgia Institute of T h,.. 4.iP ;
May 1997, Available at URL:
http://www.cc.gatech.edu/fac/Ellen.Zegura/graphs.html
Last Accessed: March 2004

[14] Wilkins, S., Garg, S. and Ml ivyammai, S., MFC Development using Microsoft
Visual C++, Microsoft Press, Redmond, WA, 2000.

[15] Z1i io-- P., Kantola, R. and Aalto, S., "QoS Routing for DiffServ Networks:
Issues and Solutions (Draft)," Technical Report, Networking Labor il. ;
Helsinki LUu'. .- I,/ of T lii. i,/;/ Oct 2002, Available at URL:
www.netlab.hut.fi/tutkimus/ironet/papers/report-qosr-diffserv.ps
Last Accessed: March 2004















BIOGRAPHICAL SKETCH

i:: was born on AX :21 V27, 1 '1, in the city of Pune, Maharash-

tra India. lHe received his bachelor's ('. Bee, Bachelor of Engineering, in Computer

Science and Engineering i:' the Pune University, India in June

In August : -: he joined the University (." T. : da to pursue a master's degree

in computer science and engineering. During his master's study he has been a

Leaching Assistant at the D : tent of Computer and I::i. :::: : : Science and

Engineering at the IUnive. of Florida. His research interests include computer

networks, network security. He expects to complete his degree in ': 2004.