Abstract-Comparative prestandamätningar av distribuerade applikationer och nätverksprotokoll kräver tillgång till lämpliga nätverksmiljöer. Nätverksemulering är ett flexibelt sätt att efterlikna egenskaperna hos en mängd olika nätverk. Befintliga emuleringsverktyg fungerar antingen med centraliserade simuleringskomponenter i realtid, vilket begränsar scenariostorleken och maximal trafik, eller fokuserar på emulering av vissa nätverksegenskaper vid en enda punkt. Vi föreslår ett verktyg för realistisk emulering av nätverkslänkar, och visar hur flera emulerade länkar kan kombineras för att reproducera en omfattande nätverksmodell. Dessutom kan modellen omfatta byte av nätverksegenskaper, t.ex. Utgående från partner i mobil kommunikation. Detta underlättar den distribuerade emuleringen av ett omfattande, dynamiskt nätverksscenario för att stödja repeterbara prestandamätningar. , Det är viktigt att analysera inverkan av olika nätverksmiljöer på deras prestanda. Medan matematiska analyser och simuleringar ofta används i tidiga utvecklingsstadier, måste mätningar stödja de teoretiska resultaten så snart implementationer blir tillgängliga. Eftersom målnätverksscenarierna sannolikt inte är tillgängliga i detta skede, finns det behov av syntetiska, konfigurerbara miljöer för att utföra jämförande prestandamätningar inom dem. Dessa miljöer måste efterlikna ett visst nätverk så nära som möjligt. För att underlätta emuleringen av mobila nät måste miljön också stödja dynamiska förändringar av respektive nätverksparametrar. En avgörande del av en emuleringsanläggning är ett emuleringsverktyg som påverkar nätverkstrafiken på ett specifikt sätt. I detta dokument anger vi först vilka krav ett emuleringsverktyg måste uppfylla. Sedan visar vi hur befintliga strategier tar itu med dessa frågor: Centraliserade emuleringsverktyg kan fungera med dynamiska scenarier, men utgör en flaskhals till det emulerade systemet och därmed begränsa scenariot i storlek och bandbredd. Flera emuleringsverktyg körs på ett antal värdar för att ställa upp ett scenario stöder högre bandbredder, men saknar en central, dynamisk modell. Som en kompromiss mellan centraliserad och distribuerad emulering föreslår vi ett emuleringsverktyg som kan köras på flera noder som bildar ett omfattande scenario, och kontrolleras i realtid av en central dynamisk nätverksmodell. Vi anger hur vårt verktyg fungerar i operativsystemets kommunikationsstapel och introducerar de angivna nätverksparametrarna på ett realistiskt sätt. Slutligen visar vi hur uppdateringar i den centrala nätverksmodellen kan spridas till respektive emulatorfall på ett effektivt sätt. För att kunna beskriva vilka krav ett emuleringsverktyg måste uppfylla, introducerar vi först emuleringssystemens struktur i allmänhet och definierar några grundläggande termer. Syftet med alla nätverksemuleringsmetoder är att efterlikna beteendet hos ett specifikt nätverksscenario för att analysera effekterna av detta scenario på programvara som kommunicerar över nätverket (se bild. 1 )............................................................................................................... Därför behöver varje emuleringsmetod en nätverksmodell där det önskade nätverket och dess egenskaper definieras. Nätverksemuleringsanläggningen är programvara, hårdvara eller en kombination av båda som tillhandahåller nätverkstjänster till den programvara som testas (SUT). SUT kan vara applikationer eller protokoll på olika lager. Emuleringsanläggningen måste tillhandahålla gränssnitt (inträdespunkter, EP) mellan det emulerade nätet och SUT, som representerar olika platser inom nätverket. Emulation faciliteten kan erbjuda tjänster på olika lager, vi kallar detta emulation abstraktion lager. Användbarheten av ett emuleringsverktyg för ett specifikt ändamål är i hög grad beroende av det emulationsabstractionskikt som det erbjuder SUT. Vi identifierade tre emulationsabstractionlager som används genom emuleringsmetoder: • Transportlager emulering syftar till reproduktion av vissa processkommunikationskanalegenskaper, t.ex. En TCP-kanals prestanda. Emulering på detta abstraction skikt kan användas för att mäta prestandaeffekterna av kanalegenskaper på applikationer. • Nätverkslager emulering efterliknar end-to-end beteende hos ett nätverk som ansluter värdar, t.ex. paketförseningar, överbelastningsförluster osv. Utöver tillämpningen av transportskiktsemulering kan den också användas för utvärdering av transportprotokoll. • Länkskiktsemulering koncentreras på emulering av enskilda nätverkslänkar, t.ex. begränsad bandbredd, bildfördröjning, etc. Förutom tillämpningen av transport- och nätskiktsemulering underlättar emulering på länkskikt även utvärderingen av nätskiktsprotokoll. Det primära målet för varje nätverk emulering tillvägagångssätt är att uppnå maximal möjlig överensstämmelse med beteendet hos ett verkligt nätverk. Varje aspekt av den emulerade delen av ett nätverk måste övervägas för att uppnå detta, inklusive fysiska effekter, maskinvarudesign och protokollfrågor. Det är uppenbart att realistisk emulering på ett högre abstraktionsskikt är svårare att uppnå än på ett lägre skikt, eftersom fler faktorer måste beaktas. T.ex., nätverkslager emulering måste efterlikna effekterna av nätlager problem (dynamisk routing, köer etc.) för att vara realistisk. Däremot kan strategier som fokuserar på den realistiska emuleringen av länkar använda det faktiska genomförandet av nätverkslagerprotokoll för att skapa dessa effekter. I allmänhet, lägre emulation abstraktion lager kommer att leda till mer realistiska resultat. Vi upplevde att emulering på länklager är den lägsta möjliga emulering abstraktion som är möjlig utan att använda speciell hårdvara. Med hänsyn till detta mål kan vi ange vilka krav ett nätemuleringssystem ska uppfylla: • Länklagerabsorbering: För att ge högsta möjliga realism, och för att kunna inkludera nätverkslagerprotokoll som SUT, är det nödvändigt att en nätverksemuleringsanläggning tillhandahåller tjänster på länklager. Resterande delar av detta dokument är därför inriktade på nätemulering av länkskikt. • Emuleringsparametrar: Nätverksemulering på länklager måste efterlikna beteendet hos en faktisk nätverkslänk så nära som möjligt. Alla parametrar som påverkar prestanda måste beaktas. Dessa parametrar är [8]: Bandbredd begränsning (inklusive ram serialisering fördröjning uppstår från en begränsad bandbredd), spridning fördröjning (vanligtvis fast), medium åtkomst fördröjning (kan variera från ram till ram) och ram förlust (korruption förlust). • Öppenhet: SUT:s och det emulerade nätets anslutning genom respektive ingångar måste vara helt öppen för SUT. Detta underlättar för SUT att utvärderas i sin ursprungliga, omodifierade form. • Dynamisk modell: Särskilt i mobila trådlösa nätverk är nätverksparametrar föremål för permanent förändring. Eftersom de beror på en mängd olika fysiska effekter, parametrar som anslutning, förlust egenskaper, genomströmning etc. är långt ifrån konstanta. Men även i trådbundna nätverk, länkparametrar kan ändras (fysiska länkfel, uppringda anslutningar etc.). För att kunna efterlikna dessa effekter måste nätverksmodellen innehålla dynamiska förändringar. Som ett resultat, emulering anläggningen måste ge möjlighet att ändra sina inställningar under drift. • Minimera biverkningar: Mata nätverkstrafiken till en emuleringsanläggning skapar några oundvikliga overhead (en ytterligare fördröjning). Denna overhead är en nätfastighet som inte är en del av det angivna scenariot och därför måste minimeras. Parameteruppdateringar som krävs för att emulera dynamiska nätverk kan också medföra oönskade effekter, särskilt om de inträffar ofta. Parameteruppdateringsmekanismen måste därför vara utformad för att fungera effektivt, utan att störa emuleringsprocessen. Denna förordning träder i kraft den tjugonde dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning. RELATERAT ARBETE Eftersom simuleringen av kompletta nätverksscenarier redan har behandlats i detalj [3] är det rimligt att det finns flera insatser för att återanvända befintliga simulatorer för emuleringsändamål. Simulatorer kan arbeta med komplexa nätverksmodeller, och deras simulatorkärna kan beräkna de effekter specifika nätverksegenskaper har på nätverkstrafiken som leder modellen. Detta utgör redan huvuddelen av en emuleringsanläggning. Vanligtvis fungerar nätverkssimulatorer med modeller på länka abstraktion lager. Det finns två grundläggande problem som måste lösas för att underlätta kopplingen av en simulatorkärna med SUT. För det första fungerar vanliga nätverkssimulatorer med diskreta schemaläggare. Händelser behandlas så snart effekterna av alla tidigare händelser har utvärderats. För att interagera ordentligt med SUT, måste schemaläggaren modifieras för att synkroniseras med realtid. För det andra måste ett gränssnitt för paketfångst och generering tillhandahållas (ingångspunkterna). Dessa frågor har redan behandlats för de vanligaste nätsimulatorerna [7, 10]. Kravet i realtid verkar bli ett problem när man flyttar till högre bandbredder. I viss utsträckning kan detta åtgärdas genom parallellisering av den diskreta händelsesimulatorn [16]. Andra liknande metoder anger uttryckligen att de syftar till emulering av länkar med låg bandbredd endast [5, 11]. Medan simulatorbaserade metoder syftar till att modellera en hel nätverksscenario inom en simulering, vilket ger flera ingångspunkter för SUT, finns det också verktyg som syftar särskilt till emulering av en enda länk. Dessa verktyg påverkar nätverkstrafiken direkt inom protokollstacken i en nodbehandlingstrafik. I de flesta fall kommer detta att vara noden där trafiken uppstår, men det är också möjligt att påverka trafiken på den mottagande noden eller ens på en mellanliggande nod som fungerar som router eller transparent bro. Olika verktyg har föreslagits för detta ändamål, men endast ett fåtal stödlager emulering. Den ursprungliga Dummynet verktyg [15] fångar samtal från TCP till IP i FreeBSD stacken och kan införa en fast fördröjning och paket förlust. Det erbjuder också en FIFO kö med konfigurerbar utgångshastighet för bandbredd strypning. Det nuvarande genomförandet, som ingår i FreeBSD-distributionerna, genomförs som en del av brandväggskoden inom nätverkslagret. Därför är den inte längre bunden till ett särskilt transportprotokoll. Regler anger om ett paket ska påverkas eller inte. Dessa regler kan baseras på enhetsadresser. Därför kan den aktuella versionen av Dummynet ses som ett länklager emuleringsverktyg. En ny metod kombinerar insamling och uppspelning av nätverksparametrar för att efterlikna den föränderliga prestandan i en mobil miljö [14]. I insamlingsfasen mäts nätverksegenskaper mellan två värdar och reduceras till fördröjning och paketförlust. Reprisfasen använder ett emuleringsverktyg som arbetar mellan nätverkslager och enhetsdrivrutin för att introducera de insamlade parametrarna igen. Medan det faktiska samlingsförsök som beskrivs i papperet uppmätta end-to-end egenskaper, emuleringsverktyget som används för att återspela data kan länka lager emulering. De flesta moderna operativsystem erbjuder möjligheten att begränsa bandbredden hos nätverksenheter under nätverksskiktet (t. ex. [2] ). Vanligtvis läggs en drop-tail kö med önskad utgångshastighet över enhetsdrivrutinen. Även om dessa metoder medför förseningar och paketförluster, framstår de som en bieffekt av drop-tail-kön, och kan därför inte användas för att emulera spridningsfördröjning och korruptionsförlust. Därför, bandbredd strypning ensam kan inte betraktas som fullständig länk lager emulering. Det finns andra emuleringsverktyg som fungerar i kommunikationsstacken, men som arbetar på högre lager. Försening [9] ger transportskikt emulering genom en anpassad uttag implementation. För att använda verktyget måste ett program omkompileras för att ringa Delayline uttag. Därför är verktyget inte öppet för tillämpningar. Försening kan emulera både spridningsfördröjning och paketförlust av en opålitlig kommunikationskanal innan paketen skickas till de faktiska uttag som tillhandahålls av operativsystemet. NISTNet [4] är ett verktyg som arbetar inom Linuxkärnan. Liksom Dummynet, kan det införa bandbredd begränsning, fördröjning, och paket förlust, men lägger till fördröjning variation, paket omordning, och paket dubblering. NISTNet har som mål att emulera nätverkslager och kan därför endast konfigureras på grundval av nätverkslageradresser. Länklager emuleringsverktyg som arbetar i protokoll stacken är utformade för att köra på en eller två maskiner, som efterliknar en länk mellan två nätverksenheter. Genom att använda upp ett antal anslutna noder som kör ett emuleringsverktyg kan ett omfattande nätverksscenario sättas upp. Utah Network Testbed [12] använder en enda nätverksbeskrivning baserad på ett OTcl-skript (liknande ett ns-2 simuleringsinställningsskript) för att definiera en nätverksmodell. Flera FreeBSD noder som kör Dummynet används för att emulera nätverkslänkar. Kombinationen av en central nätverksmodell och användningen av verktyg för emulering av länkskiktet utgör en komplett nätverksemuleringsanläggning som arbetar med kopplingsskiktets abstraktion. Nätverksmodellen innehåller dock inte någon dynamisk ändring av parametrar. Vi angav kraven för nätemuleringsanläggningar ovan. Det finns ingen befintlig emuleringsmetod som uppfyller alla våra krav: Vissa emulatorverktyg som utvecklats från simulatorer kan arbeta med dynamiska nätverksmodeller och stödja korrekt emulering på länklager abstraktion [10, 11]. Eftersom all trafik inom nätet måste skickas till en central emuleringsprocess är den totala trafiken begränsad till det belopp som emuleringsprocessen kan hantera. Därför, emulering med en centraliserad emulator instans fungerar för scenarier med få noder och låg bandbredd endast. Befintliga verktyg för emulering av länkar tar inte hänsyn till alla parametrar som påverkar prestandan. T.ex. stöder Dummynet [15] inte en variabel fördröjningsparameter. Den gemensamma bandbreddsbegränsningen i nätverkslänkemulatorer är att införa en drop-tail kö med en specificerad utgångshastighet. Ett program som använder ett transportprotokoll med flödeskontroll kommer att uppleva genomströmningen för att matcha bandbredden som anges vid emulatorn. Vissa algoritmer på nätverksskikt kommer dock inte att fungera mer som förväntat: Om en verklig länk är mättad, kommer köa algoritmer som rättvis köa [13] att försöka ge varje avsändare sin rättvisa andel av resursen. Om en länk stryps av en vanlig emulator, skulle dock den extra droptail kön dränera de andra köerna omedelbart och förhindra effekterna av rättvis köning (se bild. 2 )............................................................................................................... Detta innebär att emuleringsprocessen inte är transparent för högre skikt. Även om det finns metoder för att kombinera flera länkskikt emuleringsverktyg för att bilda ett omfattande nätverksscenario [12], har dynamiska scenarioförändringar ännu inte beaktats.  I detta avsnitt kommer vi att presentera "NETShaper", 1 ett nätverk emuleringsverktyg som övervinner begränsningarna i de tillvägagångssätt som nämns ovan. NETShaper ger emulering på länklager som är helt transparent från applikationer och även protokoll ner till nätverkslagret. Därför kan NETShaper användas för att utvärdera t.ex. routingprotokoll i sin ursprungliga form (dvs. utan kodändringar). NETShaper använder en bandbredd throttling metod som exakt efterliknar det faktiska beteendet hos mättade nätverksenheter, och fungerar därför med köa algoritmer som tillhandahålls av nätverkslagret. Ytterligare emuleringsparametrar inkluderar fast fördröjning, variabel fördröjning och ramförlust. På grund av sin modulära arkitektur kan den infogas och tas bort utan omstartssystem. Först ska vi visa hur vårt emuleringsverktyg passar in i kommunikationsstacken och varför denna placering är ett bra val för transparent, realistisk emulering av nätverkslänkar. Sedan illustrerar vi hur flera fall av vårt verktyg kan köras i lämplig testbädd hårdvara för att bilda ett omfattande nätverksscenario. Slutligen beskriver vi hur en central, dynamisk nätverksmodell kan användas för att utlösa parameterförändringar i det emulerade scenariot automatiskt. NETShaper implementeras som en Linuxkärnmodul. Den använder samma programmeringsgränssnitt som nätverksdrivrutiner, och behandlas därför som en riktig nätverksenhet av operativsystemet. Flera fall av NETShaper kan ställas in på samma maskin. Varje instans kan vara bunden till en befintlig nätverksenhet. Nätverksadressen för det verkliga gränssnittet kan tilldelas emulatorenheten. Detta gör det möjligt för emulatorn att avlyssna utgående nätverkstrafik när den är på väg att skickas till nätverksdrivrutinen (se bild. Denna förordning träder i kraft den tjugonde dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning. NETShaper hanteras av ett enkelt konfigurationsverktyg som körs i användarutrymme som använder IO-CTL-samtal för att kommunicera med kärnmodulen. Packet avlyssning på denna position underlättar transparent, effektiv emulering på länklager av följande skäl: • Eftersom NETShaper fungerar i kärnan, är dess närvaro helt dold från användarens rymdprogram. All programvara för användarutrymme som använder de vanliga UNIX-kommunikationsgränssnitten (sockets, råuttag) kommer att påverkas av de angivna nätverksegenskaperna. • Den overhead som införs av det ytterligare lagret ett paket måste passera är marginell. Eftersom vi arbetar i kärnrymden får paketdata inte vidröras eller kopieras till olika minnesområden (som med användarrymdens tillvägagångssätt). Kommunikation via gränssnitt utan NETShaper påverkas inte alls. • Eftersom NETShaper fungerar under nätverksskiktet kan nya transport- och nätverksprotokoll analyseras med hjälp av emulerade länkar utan ändringar. Detta gör det möjligt för oss att göra mätningar för några av de mest lovande områdena inom nätverksforskning (t.ex. Multicast, geocast, routing i ad hoc-nätverk. • Eftersom NETShaper använder samma gränssnitt för nätverkslager protokoll som en faktisk nätverksenhet, kan vi använda samma bandbredd throttling mekanismer som nätverksenheter drivrutiner. Om en nätverksenhet inte kan bearbeta fler paket, sätter den en flagga för att förhindra att nätverkslagerprotokoll skickar paket till den. Eftersom NETShaper också använder denna flagga för att strypa bandbredden till den angivna hastigheten, kommer nätverkslagret protokollet ovanför NETShaper att uppfatta ingen skillnad mot en riktig nätverksenhet. Detta innebär i synnerhet att köa algoritmer på nätverkslager kommer att fungera med NETShaper, vilket gör vår bandbredd stryper mer realistisk än den gemensamma drop-tail köbaserade metoder (se ovan). För att bevisa att vårt emuleringsverktyg fungerar på ett effektivt sätt genomförde vi några mätningar 2. Den overhead som infördes av det ytterligare lagret i protokoll stacken visade sig vara marginell: Traversing NETShaper modul försenar ett paket med högst 3 mikrosekunder, om ingen fördröjning anges. Som Fig. 4 visar bandbreddsbegränsning skalar upp till den fysiska gränsen (100 Mbps i detta fall). Skillnaden mellan angiven bandbredd och nyttolast genomströmning uppstår från det faktiska protokollet overhead som införs av nätverk och transportskikt, och är därför realistisk. Bilda. 5 visar att den emulerade förökningsfördröjningen i viss utsträckning kan variera från det angivna värdet. Även om den genomsnittliga fördröjningen av 1000 paket som skickades via NETShaper (avbildad av den kontinuerliga linjen) matchade den angivna förseningen mycket väl, skickades enstaka paket ut upp till 9 ms för tidigt. Detta beteende är ett resultat av den begränsade timernoggrannheten hos operativsystemet vi använde (Linux för x86-arkitektur, timergranularitet 10 ms). Mätningar med andra emuleringsverktyg för UNIX-system visar samma problem [14, 15]. Om en finare fördröjning emulering behövs kan NETShaper användas på system med reducerad timergranularitet. Timer granularitet kan enkelt ändras genom att omkompilera operativsystemets kärna med olika inställningar. Finare timers 1. Vår emulator uppstod från ett verktyg för att "forma" (smooth out) nätverkstrafik. kommer att komma till priset av en ökad schemaläggning overhead [1]. Naturligtvis påverkar dessa inställningar alla timers i systemet. Som ett resultat kan beteendet hos andra koder också påverkas (t.ex., TCP retransmit timers kommer att vara mer exakt). I denna punkt visar vi ett möjligt sätt hur flera NETShaper fall i kombination med lämplig testbädd hårdvara kan utgöra en omfattande nätverk emuleringsanläggning. Nätverket Emulation Testbed (NET), som för närvarande håller på att inrättas vid University of Stuttgart, består huvudsakligen av en 60 nod PC kluster ansluten av både en hög prestanda switch och ett separat kontrollnätverk (Fig. 6).................................................................. Anslutningen mellan noder kan konfigureras av virtuella LANs (VLANs) som definieras i omkopplaren. En VLAN med två deltagande noder skulle motsvara en separat koppling mellan dessa två noder. Om en nod är en del av flera VLANs, operativsystemet kan adressera varje VLAN med en separat virtuell nätverksenhet, transparent för protokoll och program. Genom detta koncept kan VLANs användas för att ställa in någon virtuell topologi. Var och en av de virtuella nätverksenheter har en separat NETShaper instans bifogas, påverkar respektive utgående trafik på länken. En central administrativ nod ansvarar för att skapa nätverksscenariot och kontrollera experimentet. När en nätverksmodell har tillhandahållits den administrativa noden, kommer scenariot att skapas automatiskt. Kombinationen av anslutning topologi emulering med VLANs och länk parameter emulering med NETShaper skapar en omfattande nätverksscenario emulering, med möjlighet att fästa SUT på varje nod inom nätverket topologi. Emuleringen av en dynamisk nätverksmodell kräver ytterligare en funktionalitet: Enligt ändringarna i nätverksmodellen måste inställningarna för respektive emuleringsverktyg uppdateras i realtid. Därför har vi utökat konfigurationsverktyget som körs på varje nod med NETShaper instans för att fungera som en konfigurationsdemon (se bild. 7 ) och 7 )............................................................................................................... Daemon väntar på parameteruppdateringar i UDP-paket och sprider dem ner till NETShaper-fallen. Uppdateringsmeddelandena kommer från en central uppdateringscontroller, som distribuerar ändringar i en dynamisk nätverksmodell till respektive konfigurationsdemoner. Det finns många möjligheter att utlösa ändringar i nätverksmodellen. Vi specificerar dynamiska nätverksscenarier i ett XML-baserat språk, inklusive tabeller och tillståndsscheman för att beskriva parameterförändringar [8]. Med detta tillvägagångssätt kan en rad intressanta scenarier utformas med låg insats (t.ex. fel eller blekning länkar, sprickbildning förluster, etc.). Vi utförde tester med upp till 1000 uppdateringsmeddelanden per sekund, vilket avslöjar att noggrannheten i emuleringen inte påverkas på något sätt av uppdateringsprocessen. Processorn användning av en nod bearbetning en uppdatering meddelande varje ms ökade med endast 2-3%.
Ett alternativt tillvägagångssätt består i att använda ett förutbestämt scenario för att styra en trafikformare, som i Network Emulation Testbed REF, som gör det möjligt att använda XML-formaterad scenarii för att emulera trådnät.
A dynamic network scenario emulation tool
{'venue': 'Proceedings. Eleventh International Conference on Computer Communications and Networks', 'journal': 'Proceedings. Eleventh International Conference on Computer Communications and Networks', 'mag_field_of_study': ['Computer Science']}