SE514485C2 - Förfarande och arrangemang för defragmentering - Google Patents

Description

25 30 514 '485 2 Med detta breda spektrum av tillämpningar som existerar idag och som kommer att tilltaga i framtiden, är det osannolikt att man skall kunna fortsätta att uppfinna nya, ibland globala, nätverk och en ny terminal för varje ny typ av tjänst. Istället behövs ett nytt integrerat tjänstenät- verk som understödjer redan existerande tjänster samt även nya tjänster. De övergripande målsättningarna för ett sådant nätverk är att det skall global storlek och utnyttjandet av kostbara komponenter blir maxi- vara skalbart upp till malt. Optisk transmissionsteknologi har visat sig ge nödvän- dig länkkapacitet till en tillräckligt låg kostnad för att göra integrerade tjänstenätverk till en realistisk lösning.

Ett nytt integrerat optiskt nätverk med mycket högre kapacitet kommer dock att medföra nya problem som inte finns i dagens mera specialiserade nätverk med lägre prestanda.

Till att börja med, när nätverkskapaciteten ökar och propageringsfördröjningen kvarstår på grund av ljusets hastighet, kommer den ökande produkten av capacitet och fördröjning att ställa högre krav på de mekanismer som isolerar an användares trafik från Ett telefonsamtal, t. användare öppnar en videokanal med hög kapacitet. Vidare övriga parters trafik. ex, bör inte påverkas av att en annan kommer tillämpningar och protokoll att vara tvungna att fungera på ett pålitligt sätt med en ökande mängd informa- tion i rörelse för att dra fördel av den ökande nätverks- kapaciteten. Detta resulterar i större skurar av information och större transaktioner i nätet.

Dagens nätverk som använder sig av förbindelselösa paketförmedlande protokoll, t.ex IP (Internet Protocol) har visat sig vara väldigt skalbara. De har utvecklats från små nätverk, som kopplar endast ett litet antal DARPA (Defense Advanced Research Projects Agency) forskningsdatorer i mitten av 70-talet till dagens universellt utspridda globala Internet. Lokala nätverk baserade på delat medium som t.ex. 10 15 20 25 30 514 485 3 CSMA/CD (Carrier Sense Multiple Access/ Collision (Fiber Distributed Data Interface) används inom Internet som enkla byggstenar, Detection), token ring och FDDI kopplade med routers eller bryggor. Kombinationen av enkel expansion, lågt växande kostnader beträffande noder samt tolerans av felaktiga noder, har resulterat i enkla, flexibla och robusta nätverk. Dessutom tillåter delat medium effektiv tillämpning av nya protokoll för multicast som t.ex IP multicast.

En nackdel med delat medium är, att det typiskt tillåter endast en terminal att sända en viss tid, och att alla nätverks-segment därmed inte används effektivt. Ett schema som tillåter mediets kapacitet att återanvändas kanske kommer att realiseras, men detta sker ofta på bekost- nad av komplexitet i hårdvara. Kontrollmekanismerna för accessen till det delade mediet är också kraftigt beroende av storleken på nätverket och är oftast effektiva endast inom lokala nätverk (korta distanser).

De två viktigaste nätverkstyperna är förbindelseorien- terade kretskopplade nätverk som används inom telefoni, och förbindelsefria paketväxlade nätverk, exemplifierade genom Internet. När ett kretskopplat nätverk används för data- kommunikation, behöver förbindelserna kontinuerligt vara etablerade mellan skurar av information, vilket ger dåligt utnyttjande av kapaciteten i nätet. Detta problem uppstår då upp- och nedkoppling tar lång tid jämfört med de dynamiska variationerna i användarbehov. En annan källa till ineffek- tivitet inom kretskopplade nätverk är användandet av symmetriska dubbelriktade kanaler, vilka introducerar 50% "overhead" när informationsflödet är enkelriktat. Den här begränsningen gör också koppel med flera mottagare (multicast) svåra att implementera och de blir ineffektiva.

Ett förbindelsefritt paketväxlat nätverk, å andra sidan, saknar resursreservering och måste därmed tillföra 10 15 20 25 30 514 '485 4 kontrollinformation till varje meddelande innan transmission kan börja. Dessutom kan inte fördröjningen i ett förbin- delsefritt paketväxlat nätverk med exakthet förutsägas och paket kan till och med förloras p g a överflöde i buffertar eller felaktiga pakethuvuden. De sista två faktorerna gör det svårt att stödja real-tidstjänster. Mekanismer som gör det möjligt att undvika överbelastning kan isolera olika användares trafikströmmar. Dessa mekansimer är dock begränsade och fungerar bara på en tidsskala jämförbara med en paketfördröjningen tur och retur mellan sändare och mottagare.

För att adressera ovan nämnda problem, fokuserar kommunikationsindustrin på utvecklingen av ATM (Asynchronous Transfer Mode). ATM har blivit föreslagen för LAN's och många framtida publika nätverk. CCITT (International Telegraph and Telephone Consultative Committee) har också antagit ATM som överföringsstandard för B-ISDN (Broadband Integrated Services Digital Network). ATM nätverk är förbindelseorienterade och etablerar virtuella kanaler, liknande koppel i kretskopplade nätverk, men använder sig av för informationsöver- små paket med fast storlek, celler, föring. ATM's paketväxlade karaktär innebär att nätverket behöver många nya mekanismer, som t ex reservering av buffertar och betjäningsalgoritmer för att kunna fastställa d v s en virtuell real-tidsgarantier för ett koppel, kanal.

En annan lösning för att kunna garantera real-tid koncentrerar sig på ett kretskopplat nätverk och måste sålunda adressera problemen med traditionell kretskopplings, såsom de har beskrivits ovan. Ett nytt kontrollprotokoll för delat medium tillämpas också, och sålunda måste även de allmänna problemen med delade media övervägas. Denna design, benämnd DTM (Dynamic Synchronous Transfer Mode), (se ex.

Christer Bohm, Per Lindgren, Lars Ramfelt och Peter Sjödin, 10 15 20 25 30 514 485 få The DTM Gigabit Network, Journal of High Speed Networks, 3(2):lO9-126, 1994, Björn Pehrson, Multi-gigabit networking based on DTM, Computer Networks and ISDN Systems, 24 (2) 119-139, April 1992) använder sig av kanaler som kommunikationsabstraktion_ och Lars Gauffin, Lars Håkansson, och Dessa kanaler skiljer sig från telefonkoppel på flera olika sätt. Till att börja med är uppkopplingsfördröjningen så kort att resurser kan anslås/avslås dynamiskt så fort användarbehovet ändrar karaktär. För det andra är kanalerna enkelriktade och minimerar således "overhead" vid kommuni- kationen är enkelinriktad. För det tredje erbjuder de multipla överföringskapaciteter för att stödja olika typer av behov hos användarna. Slutligen kan kanalerna ha obegränsat antal destinationer (multicast).

DTM kanaler delar många goda egenskaper med kretsar.

Det sker ingen kommunikation av kontroll information efter det att kanal har etablerats, vilket resulterar i väldigt högt användande av nätverk-resurser för stora data överföringar. Stödet av real-tidstrafik är naturlig; ingen övervakning av användarnas beteende, stocknings-kontroll eller flödeskontroll krävs inom nätverket. Kontrollinforma- tionen är skiljt från användar information, vilket gör kommunikation till flera destinationer mindre komplext.

Källfördröjningen är försumbar ( d v s mindre än 125 us) och risken för att data skall försvinna pga stockning saknas, p g a överfyllda köer så som inom ATM. Sannorliketen för bitfel beror direkt av den underliggande länk-teknologin, och kanal uppkopplingarna är enkla och snabba p g a strikt resurs-reservation vid kanalens etablering.

DTM kan även uppvisa god prestanda inom områden där traditionella kretskopplade nätverk uppvisar brister: dynamisk bandbredds-tilldelning, källfördröjning, och som nät med delat medium. 10 15 20 25 30 514 485 6 SAMMÄNFATTNING AV UPPFINNINGEN Ett av problemen med DTM när man använder optimeringen med block tokens, speciellt med en distribuerad token hanterare, är fragmentering.

Det genomsnittliga antalet angränsande lediga tidluckor i en nod inom ett DTM nätverk utan defragmenteringsmekanism blir normalt liten. Anledningen till detta är att tokens slumpvist förflyttas och delas för att kunna ge olika användare varierande kapaciteten beroende pà behoven. Detta resulterar i relativt långa uppkopplings fördröjningar (i storleksordningen millisekund) för kanaler med hög kapacitet, speciellt vid en måttlig till hög nätverkslast.

Syftet med uppfinningen är att lösa detta fragmente- ringsproblem. Detta åstadkoms genom en metod för defragmen- tering och ett arrangemang för ökning av den genomsnittliga blockstorleken hos lediga tokens inom noderna i DTM nätverket.

Defragmenteringen enligt uppfinningen omfattar definierandet av en hemnod för varje token vid nätverkets uppstart eller vid drift för att de tokens som delar samma hemnod ska definiera åtminstone en delvis oavbruten luck- nummerserie, och lediga tokens àtersänds till hemnoderna när en viss tid har passerat, samt att tvà eller flera angränsande tokens sätts samman till en token när de befinner sig i en och samma nods lediga pool.

Defragmenteringsmetoden enligt uppfinningen undviker det ovan nämnda problemet. Metoden àtersänder dessa tokens till deras hemnoder som ett sätt att öka sannorlikheten att vilket minskar två angränsande tokens kan sättas samman, fragmenteringen.

En fördel med uppfinningen är att den kan förverkligas både i en central och i en distribuerad modell för hantering Den av token, eller i en kombination av dessa två modeller. 10 15 20 25 30 514-485 7 största förbättringen när man ser till uppkopplingsfördröj- ningen får man i ett system som använder en distribuerad hanterare för token.

En annan fördel är att de nya hemnoderna kan definieras för tokens under drift.

Ytterligare en fördel är att tiden innan token skickas tillbaka till hemnoden kan väljas på ett flertal olika sätt: som efter att token varit outnyttjad en viss tid, som att en maximal tid innan token ska skickas hem eller efter att ett betydande antal nätverkstransaktioner skett, eller som en kombination av dessa sätt. Tiden väljs för att ge optimal prestanda; om tiden är för kort, kommer metoden och arrange- manget för defragmentering att bidra till att resursdel- ningen blir sämre, och om tiden är för lång kommer fragmen- teringen fortfarande att vara ett problem.

Ytterligare en fördel är att prestandan ökar när metoden kombineras med en metod för återanvändning av tid- luckor, vilken tillåter att tidluckor används i oberoende överföringar över åtskilda segment i nätverket. Metoden och arrangemanget för defragmentering kan då användas både i lucknummer- och segment-dimensionerna. Metoden och arrange- manget för defragmentering enligt uppfinningen kan före- trädesvis prioritera sammanslagning av segment före sammanslagning av tidluckor.

KORTFATTAD BESKRIVNING AV TECKNINGARNA Uppfinningen kommer att beskrivas mer detaljerat nedan, med avseende på den bifogade teckningen, i vilken fig. 1 illustrerar ett dubbelbuss DTM nätverk. fig. 2 hemnod för varje datatidlucka illustrerar ett DTM 125 ms cykel med en bestämd enligt uppfinningen. fig. 3 illustrerar en token karta som visar antal luckor samt segment, 10 15 20 25 30 514 485 fig. 4 illustrerar en tidlucka-segment karta, vilken visar återanvändningen av luckor enligt uppfinningen. fig. 5 illustrerar prestandan (genomströmning och åtkomstfördröjing, kontra den erbjudna lasten) för små (16 kbyte) och kapaciteter som simulerats, användarkrav för olika minimal-acceptans då man använt sig av en (token server) distribuerad enligt uppfinningen, fig. 6 visar prestandan för små användarkrav (16 kbyte) och för olika antal tillåtna försök innan förfrågan blockeras, som simulerats med hjälp av en distribuerad token server enligt uppfinningen, fig. 7 illustrerar åtkomstfördröjningen som en funktion av simulerad tid, med hjälp av A) defragmenteringsschemat samt ingen fragmentering vid simuleringens start, B) defragmenteringsschemat enligt uppfinningen samt maximal fragmentering vid simuleringens start, samt C) inget fragmenteringsschema och maximal fragmentering vid simuleringens start. fig. 8 illustrerar teoretisk genomströmning för en DTM dubbelbuss kontra erbjuden last för ett dubbelbuss DTM nätverk med och utan återanvändning av tidluckor, fig. 9 illustrerar prestanda för de olika paketstorlekarna som simulerats genom användning av en central token manager inom ett 10 km långt dubbelbuss DTM nätverk utan luck- återanvändning. fig. lO illustrerar prestanda för olika paketstorlekar som simulerats genom användning av en central token manager inom ett lO km långt dubbelbuss DTM nätverk med återanvändning av tidluckor enligt uppfinningen, fig. ll illustrerar prestanda för olika paketstorlekar som simulerats med hjälp av en central token manager inom ett 1 000 km långt DTM nätverk med återanvändning av tidluckor enligt uppfinningen, 10 15 20 25 30 51-4 4-85 9 fig. 12 illustrerar prestanda för olika paketstorlekar som simulerats genom användning av en distribuerad token manager i ett dubbelbuss nätverk med defragmentering och återanvändning av tidluckor enligt uppfinningen, fig. 13 illustrerar prestanda för olika buss-längder som simulerats med hjälp av en distribuerad token manager med defragmentering och återanvändning av tidluckor enligt uppfinningen, och fig. 14 illustrerar prestanda för olika trafikförhållanden som simulerats med hjälp av en distribuerad token manager i ett dubbelbuss nätverk med defragmentering samt återanvändning av tidluckor enligt uppfinningen.

DETALJERAD BESKRIVNING AV UTFORMÄNDET Till att börja med skall DTM MAC (Medium Access Control) protokoll beskrivas. Den grundläggande topologin i ett DTM nätverk är en buss med två enkelriktade optiska fibrer som sammankopplar alla noder, som illustrerats i fig. 1. Åtskilliga bussar med olika hastigheter kan kopplas samman för att tillsammans forma ett godtyckligt flerstegs nätverk. I dagens prototyp implementation, kan bussar kombineras till ett tvådimensionella nät. En nod vid föreningspunkten av två bussar kan synkront växla data i tidluckor mellan de två bussarna. Detta tillåter effektiv växling med konstant försening genom noden. Den primära kommunikationsabstraktionen i DTM är en kanaler som kan vara av olika kapacitet och nå multipla mottagare (multicast).

DTM MAC protokollet är ett tidsmultiplexerad schema.

Bussens bandbredd är uppdelad i 125 ms cykler (8 kHz), vilka i sin tur är uppdelade i 64-bit tidsluckor (eller bara luckor, i förkortning) vilket är illustrerat i fig. 2.

Antalet luckor i en cykel är därmed beroende av nätverkets bithastighet; t ex, på ett 6.4 Gbit/s nätverk finns det ungefär 12500 luckor per cykel. 10 15 20 25 30 514 485 10 Luckorna är uppdelade i två olika grupper, kontrolluckor samt dataluckor. Kontrolluckor används för att bära med- delanden åt nätverkets interna operation, t ex meddelanden för kanaletablerande samt omfördelning av bandbredd.

Dataluckor används för att sända användardata och tolkas inte av mellanliggande nätverksnoder. Mellanliggande noder är noder mellan källan och destinationen.

I varje nätverksnod finns en nodkontrollant (NC eller node controller), vilken kontrollerar tillgången på dataluckor och utför management-operationer, som t ex vid nätverkets uppstartande samt felsökning. De viktigaste uppgifterna som nodkontrollanten har är att skapa och avsluta kanaler då detta krävs av användarna, och att sköta nätverksresurserna i enlighet med användarkrav och i bakgrunden.

Kontrolluckor används enbart för meddelanden mellan nodkontrollanter. Varje nodkontrollant har tillåtelse att skriva till minst en kontrollucka i varje cykel som den använder för att sända kontrollmeddelanden nedströms till andra noder. Eftersom tillåtelse att skriva till kontroll- luckor är exklusivt, har nodkontrollanten alltid tillgång till sina kontrolluckor, oavsett andra noder samt nätverks- belastning. Antalet kontrolluckor som en nod använder kan variera under driften av nätverket.

Nätverket är inte begränsat till en dubbelbuss, utan kan tillämpas med andra sorters strukturer, t ex en ring- struktur med ett godtyckligt antal noder. Transmissions- mediet kan, förutom optiska fibrer, vara koaxialkabel eller någon annan sorts transmissionsmedium med hög bandbredd.

Hädanefter kommer transmissionsmediet att benämnas optiska fibrer. Bandbredden i DTM dubbelbuss inom det föredragna utformandet är uppdelad i 125 ms cykler, vilka i sin tur är uppdelade i 64-bit tidsluckor. Uppfinningen är inte begrän- 10 15 20 25 30 514 485 11 sad till DTM nätverk med detta värde, utan kan användas inom nätverk med cykler och tidluckor av godtycklig storlek.

Principerna för resurshantering (benämnt token management) kommer att beskrivas nedan. Majoriteten av luckorna inom en cykel är datatidluckor. Tillgång till dataluckor ändras inom en tidsrymd, beroende på trafikkrav.

Tillàtelse att skriva till luckor kontrolleras av luck- (eller enbart tokens, En nodkont- tokens som förkortning). rollant kan skriva in data i en lucka bara om den äger mot- svarande token. Token protokollet garanterar att tillgången till luckor skall vara fri från konflikter, villket innebär att åtskilliga noder inte skriver in data i samma lucka.

Kontrollmeddelanden för kanaletablerande och band- breddsallokation bär uppsättningar av luckor eller tokens Ett kontrollmeddelande är dock 64 bitar och kan därför bara ha ett litet antal parametrar. som parametrar.

Detta inne- bär, att om en användare begär en stor bandbreddsöverföring, kan det bli nödvändigt att att sända åtskilliga kontroll- meddelanden för att skapa kanalen. Detta innebär extra åtkomstfördröjning och slukar signaleringskapacitet.

Vi överväger ett flertal mekanismer för att minska mängden information som behöver sändas under kanalens skapande och vid omfördelning av tokens. Det första optimala sättet inom token management är att introducera block tokens. Ett block token översänds i ett enda kontrollmedde- lande och representerar en grupp tokens, men kan bara använ- das i särskilda kombinationer av tokens. T ex, i simulatorn betecknas ett block token av ett lucknummer som anger luckans position i cykeln och ett nummer som delger antalet angränsande luckor i gruppen. Detta optimala block token exempel förutsätter att token poolen inte är fragmenterad i små delar. Detta kommer att benämnas token poolens fragmen- tering. 10 15 20 25 30 514-485 12 Token-protokollet garanterar att en datalucka aldrig kan användas av två noder simultant på bussen. Ibland är detta protokoll för konservativt. Fig. 3 visar ett exempel (A, B och C) kanaler. Noderna är hopkopplade av buss-segment och kanaler- på hur tre tokens är reserverade för tre na använder sig typiskt av en underuppsättning segment på bussen (grå färg) och resten är reserverade (vit färg) men finns kvar oanvända och slösar således med delade resurser.

Ett bättre alternativ är att låta kanalerna enbart reservera kapacitet på segmenten mellan sändaren och mottagaren som exemplet i fig. 4. En enda lucka kan i detta exempel använ- das åtskilliga gånger på bussen. Kanal D och E använder samma luckor som kanal A och C, men på olika segment. Detta benämns luck-återanvändning (slot reuse). Luck-återanvänd- ning möjliggör simultana transmissioner i samma lucka över åtskilda segment på bussen.

Luck-återanvändning är en generell metod för att bättre kunna använda delade länkar i ring och buss-nätverk. Luck- àteranvändningsalgoritmerna i DQDB (Distributed Queue Dual Bus), Simple och CRMA (Cyclic Reservation Multiple Access) är beroende av kontrollinformation i luckorna. Bufferinsätt- när de är kombinerade med frigörande av som i METARING, kan återanvända kapaciteten i individuella länkar och upplösa ningsnätverk, destinationer (destination release) eventuell konflik genom att försena den inkommande paket- strömmen genom en elastisk buffer.

Med luck-återanvändning ökar komplexiteten inom åtkomstschemat, oavsett om det blir gjort i hårdvara som i DQDB, Simple och CRMA; som i DTM. När det implementeras i andra system än i DTM, tillför också luck- eller i mjukvara, återanvändningen komplex hårdvara till den kritiska hög- hastighetsvägen genom en nod, och därför ökas nodförse- ningen. 10 15 20 25 30 514 *485 13 För att kunna tillåta luck-återanvändning i DTM, förlängs block token formatet enligt uppfinningen så att det inbegriper parametrar som beskriver segmenten som det representerar. Token management protokollet är också enligt uppfinningen modifierat för att kunna undvika konflikter i lucknummer-dimensionen såväl som i segment-dimensionen. Det viktigaste antagandet är att inga hårdvaraförändringar i den ursprungliga prototypimplementeringen tilläts eller krävdes.

Prestandavinsten är alltså väldigt tydlig: på en dubbelbuss där källa- och destinationspar är uniformt fördelade har det visat sig att genomströmningen kan ökas med det dubbla.

Prestandavinsten kan till och med bli högre i andra nätverkssorter: t ex i en dubbelringsstruktur med käll- samt destinationsnoder som är uniformt fördelade, kan genomström- ningen ökas med det fyrdubbla. Om käll och destinationsnoder inte är uniformt fördelade, kan vinsten bli ännu mycket högre.

Det potentiella problemet av luck-återanvändning i ett DTM nätverk är, emellertid, den högre algoritmkomplexiteten och slutligen högre börda för nodkontrollanten och signaleringskanalerna (särskilt om den genomsnittliga kanal- varaktigheten är kort).

Två token management scheman har utvärderats. Den första och enklaste är att låta en enda nodkontrollant styra alla fria tokens för en fiber. Denna typ av centraliserade (server) mekanism har också använts i system som te x CRMA, där huvudändsnoden distribuerar fiberkapaciteten till alla andra noder. Simulatorn var inrättad på så sätt att för varje fiber fanns en nod som förhöll sig på en tredjedel av distansen från luck-generatorn, och denna var token server (med 100 noder på en buss-nod blir nummer 33 och nummer 67 "token servers"). Detta motsvarar mitt~punkten på kravet för var och en av de två enhetsinriktade fibrerna på så sätt att 10 15 20 25 30 514 485 14 en token manager kommer att ha samma mängd trafik på båda sidor.

Varje gång en användarförfrågan anländer vid en nod, kräver noden först och främst tokens från sin manager och låser dem sedan under hela kanal-livstiden. När användaren sänder meddelandet att kanalen skall kopplas ifrån, åter- sänds tokens omedelbart till sin manager. Alla förfrågningar blir fördröjda under begäran av token och själva åtkomsten serialiseras genom en central manager.

Den distribuerade "token manager" är fundamentalt mer Vi försökte att hålla den I vår metod sänder varje nod regel- komplicerad än den centraliserade. så enkel som möjligt. bundet status information beträffande hur många lediga tokens den har. De andra noderna lagrar den här informatio- nen i sina status tabeller. En nod som vill ha ökad kapacitet konsulterar sin status tabell för att utifrån den bestämma från vilken nod den skall begära luckor. Proto- kollet på den initierande sidan fungerar på följande sätt.

När en användarförfrågan anländer till en nod: l. Om noden har tillräckligt många lediga tokens för att kunna tillfredsställa kravet, allokerar noden den fordrade mängden luckor till användaren, och startar upp kanalen genom att sända ett etableringsmeddelande till destinationsnoden, och användaren sänder sedan data genom att använda de reserverade luckorna. 2. Annars markerar noden sina tillgängliga tokens som reserverade, och kontrollerar sedan sin status tabell: om den totala mängden lediga tokens i nätverket inte är tillräcklig för att tillfredsställa kravet, avvisas kravet (blockering). I annat fall begär noden tokens från noder med outnyttjad kapacitet.

Om en av dessa noder som erhåller en tokenförfrågan inte har den fordrade mängden lediga luckor, lämnar den i 10 15 20 25 30 514 485 15 vilket fall som helst ifrån sig alla sina tillgängliga luckor. I varje fall skickar den ett svar till den fordrande noden. En nod fullföljer inkommande krav i sträng FIFO (First In First Out) ordning.

När en nod får ett svar på ett token krav, markerar den luckorna som den erhåller i svaret (om den får några tokens) som reserverade. När noden har erhållit svar på alla förfrågningar som den har skickat, startar den antingen kanalerna eller avvisar användar kravet, beroende på om den har eller inte har fått tillräcklig kapacitet. Om användar kravet avvisas, markeras de reserverade luckorna som lediga igen.

Vid starten distribueras samtliga lediga tokens bland nätverkets noder och varje nod tar åtminstone en av sina lediga tokens, flyttar den (dem) till ett aktivt skick och annonserar den (dem) som kontrollucka(or). Användarförfràg- ningar kan nu accepteras och tokens kan flyttas mellan noder på begäran.

En svaghet med detta schema är att omallokering av tidluckor bara kan påbörjas med hjälp av användarförfråg- ningar, och användarförfrågningar fördröjs i avvaktan på omallokering av tokens. En optimering som vi har implemen- terat för att åtgärda detta är att också utöva reallokering av tidluckor i bakgrunden. Detta resulterar i ett mindre behov av att reallokera tokens för krav som är små och upp till mellanstorlek.

Poolen som innehåller lediga tokens kan distribueras på andra sätt än jämna sådana för att öka sannolikheten för lyckad omfördelning och för att öka utnyttjandegraden. Om färre noder sköter poolen, minskar kanalblockeringen p g a att risken att token reallokering skall misslyckas är mindre. Den kompletta token-poolen är i detta fall propor- tionerligt distribuerad (noder som ligger nära luck-genera- torn får fler tokens än noderna som befinner sig långt från 10 15 20 25 30 514 485 16 den) bland alla noder. Token förflyttningar kan inträffa mellan vilket nodpar som helst istället för att alltid engagera (server) noden. När den lokala noden innehåller tillräckligt många tokens för att tillfredsställa en inkommande användarbegäran, kan kravet accepteras utan någon token reallokering. Dessutom är det så, att så länge de anländande användarförfrågningarna passar bra till pool distributionen behövs inte någon reallokering. Åtskilliga frågor behöver besvaras innan något beslut kan tas om hur token poolen skall distribueras. Följande skall vi ta ställning till här: l. När de lokala resurserna i noden inte är tillräckliga för att tillfredsställa en användarförfrågan, vilken annan nod skall då tillfrågas om fler tokens? 2. Om en nod ber om tokens från ett flertal noder, hur många tokens skall den då be om och borde noden avvisa förfrågan om den erhåller en bråkdel av den efterfrågade kapaciteten? 3. Om tokens rör sig fritt bland noderna, kommer token poolen att fragmenteras i små bitar och visa att block token optimeringsschemat är värdelöst? Det bestämdes att status meddelanden skulle användas för att distribuera information om poolen med lediga tokens.

Status meddelande information används för att hjälpa en nod att välja en lämplig nod när den ber om ytterligare resurser. Denna metod gäller den första ovan nämnda frågan.

Vårt schema fungerar enligt följande. Varje nod sänder regelbundet status information om hur många lediga tokens den har. De andra noderna lagrar den här informationen i sina status tabeller. En nod som behöver mer kapacitet konsulterar sin status tabell för att bestämma från vilken nod den kan begära luckor. Den utsända förhållande informationen ger en ungefärlig syn på det innevarande 10 15 20 25 30 514 485 17 förhållandet av token information, så att token krav kan avvisas för att de skickades till noder som inte längre hade några tokens att lämna ifrån sig.

Status tabeller är mjuk information på så sätt att systemet fungerar även om de är föråldrade eller icke tillgängliga. De bör emellertid förbättra sannolikheten att reallokationsprocedurerna lyckas.

Vid jämförelse av den centraliserade och den (fig. 12) kan man se att det finns en ny sorts avvisningar som är (fig. 9) distribuerade "token managers" grundprestanda frekventa i den distribuerade versionen när resurserna fortfarande är oanvända i systemet.

En nod använder status tabellen för att välja nod(er) från vilka den kan begära tokens. När kravet når målnoden kan mängden tillgänglig kapacitet ha ändrats och en mindre mängd än den begärda kan bli återsänd till den begärande noden, vilket resulterar i ett användaravvisande.

Denna situation resulterar i än mera onödigt token- omflyttande och därför ökar också troligheten att andra noder erhåller färre tokens än vad de begärt. Dessa tokens som förflyttas på detta vis är också låsta och oanvända under förflyttningen.

Om poolen är proportionerligt distribuerad bland ett stort antal (100-tals) noder, kommer den normala poolens storlek att bli ganska liten. När belastningen är hög, minskar antalet lediga tokens i poolerna ännu mer. Om noder också etablerar och frigör kanaler i ett högt tempo, kommer mängden av ledig kapacitet i de individuella noderna att hoppa mellan att behålla en väldigt liten mängd kapacitetet och ingen alls. Om nu medelkapaciteten som krävs av en användare är stor jämfört med antalet lediga tokens i en nod, kommer åtskilliga noder att behöva tillfrågas för att kunna tillfredsställa kravet. Vid detta tillfälle ökar 10 15 20 25 30 514 485 18 troligheten att en av de tillfrågade noderna inte har någon ledig kapacitet, villket leder till användaravvisande.

Det finns flera sätt att ta itu med detta problem utan att återgå till en centraliserad modell. Först och främst kanske vi inte behöver skänka några tokens alls när den kompletta begäran inte kan tillfredsställas.

Detta protokoll används enbart om bara en enda nod tillfrågas om lediga tokens, men om ett flertal noder tillfrågas kan det ändå resultera i att tokens blir förflyttade eller låses i ett outnyttjat tillstånd. För det andra, om tokens har blivit efterfrågade och vi får färre tokens än vad vi begärde, kan vi helt enkelt försöka med en ny token begäran procedur flera gånger. Detta ökar sannolikheten att en användarbegäran accepteras och att erhållna tokens kommer att användas. Kostnaden för ett nytt försök blir ökad signallering samt ökad åtkomstfördröjning , och det kan försämra prestandan i ett överbelastat nätverk.

Dessutom introducerar användarens återförsök längre "set-up" fördröjning för fordringar som skall försökas igen. För det tredje kan det ibland hända att användaren vill acceptera en kanal med lägre kapacitet än vad som ursprungligen krävts hellre än att avvisas.

Om en användare t ex erhåller 50% av det begärda kanske han accepterar detta. I fig. 5 är genomströmningen, som är ration mellan transporterad användardata och det totala antalet bits som är översända av fibrerna, och tillgàngs- fördröjning, som är tiden mellan anländandet av en användar- begäran till sändningen av den första begärda datan, för små (16 kbyte) användar krav med varierande minimi-acceptabla (lO0% 40 luckor), 50% (20 luckor) lucka) planerade kontra erbjuden last. Ett lägre medel- kapaciteter samt 5% (l minimum av acceptabel bandbredd kommer att resultera i högre genomströmning. I fig. 6 visas prestandan som blir resultatet om användaren (vilken begär ett 16 kbyte data 10 15 20 25 30 514~ 485 19 överflyttande) gör återförsök upp till 8 gånger innan begäran till slut blockeras. Utnyttjandet ökar (och blockeringen minskar) på bekostnad av ökat signalerande samt längre fördröjning. Ett flertal återupprepade försök motverkar produktiviteten om det händer ofta.

Det är tydligt att om användaren har ett flexibelt krav, blir sannolikheten att avvisas lägre och genomström- ningen blir allt som allt högre. Vilken som helst av de konfigurationer som presenterats i fig. 5 och fig. 6 kan bestämmas vid ankomsttiden för en begäran. En användare som har strikta krav på en kanals kapacitet kan göra återförsök tills tillräcklig kapacitet har allokerats, men en annan kanske hellre accepterar en kanal med lägre kapacitet än den begärda mängden. De återstående simuleringarna som presente- rats här är den acceptabla minimi-bandbredden definierad' som 50% av den begärda kapaciteten.

Rent generellt är det genomsnittliga antalet angrän- sande lediga block i en nod litet, p g a det slumpvisa förflyttandet av tokens, och den varierande kapaciteten av användarnas krav. Denna fragmentering gör block token optimering värdelös, och àtkomstfördröjningen är relativt lång (millisekunder) för kanaler med hög kapacitet. För att kunna göra blockallokering effektivt är det nödvändigt att reducera fragmenteringen av lediga tokens, annars kommer fragmentering att vara den främsta bidragande orsaken till åtkomstfördröjning för höga bandbreddskanaler vid någorlunda hög last. Kanaler med låg kapacitet kommer nästan alltid att ha en väldigt kort kanaletableringsfördröjning oavhängigt av innevarande grad av fragmentering. I fallet med luck- återanvändning är fragmenteringsproblemet ännu större, då fragmentering kan inträffa i både luck- samt segmentdimen- sioner (tids- samt rumsdimension) (se fig. 4). Detta är i en centraliserad server version en speciell tillämpning av det generella dynamiska lagrings-allokeringsproblemet. I en 10 15 20 25 30 514 485 20 distribuerad token manager är det mesta av fragmenteringen ett resultat av användandet av många lediga pooler (en för varje nod). Två lediga intilliggande tokens kan endast sammanfogas om de finns inom samma nod.

Ett distribuerat schema som försöker undvika fragmen- tering om möjligt och som ökar medelstorleken på fria tokens block i noderna har implementerats. Detta schema används både med och utan luck-återanvändning.

Schemat fungerar som följer: 1. Fixera en hemnod för varje token då nätverket startas upp och distribuera tokens på så sätt att tokens som delar samma hemnod alltid fixerar en oavbruten luck-räckvidd.

Resultatet blir ett stort genomsnitts-tokenområde i token kartan som visas i fig. 4. 2. När två tokens med luckor som följer på varandra med samma luck- eller segment-räckvidd existerar i den lediga poolen skall de sammanslàs till ett enda token (ibland krävs en upprepad klyvnings- och sammanslagningsopera- tion). När sammanslagning sker skall segmentsammanslag- ning alltid prioriteras fore lucknummer-sammanslagningen.

(Anledningen till detta är att tokens räckvidd över bara ett litet antal segment är mindre användbara för andra noder än då tokens räckvidd sträcker sig över många segment.) Två tokens efter varandra följande i segment, vilka representerar åtminstone delvis samma luck-räckvidd och som existerar i en nods lediga pool, klyvs för att uppnå tokens som följer efter varandra i segment och som representerar samma luck~räckvidd, vilka sammanslås till ett enda token. 3. När en nod får en token-begäran från sin lokala användare eller en användare som befinner sig på långt avstånd, skall en token från token poolen väljas genom användning av den bäst passande algoritmen (best-fit algorithm) i 10 15 20 25 30 514 485 21 ett lucknummer- och segmentnummerdimension (se fig. 4).

Värdet av ett token räknas ut som omrâdet i ett token i tokenkartan och vi försöker att välja det token som har det minsta området som ändå tillfredsställer den begärda kapaciteten. En kostnadsfunktion kan också definieras som en funktion av t ex antalet luckor, antalet segment, placering av luckor och placering av segment; denna funk- tion bör emellertid minimeras men kan ändå tillfreds- ställa den begärda kapaciteten. Denna mekanism kan också användas av servers då de använder en centraliserad token manager. 4. När en nod behöver begära tokens från andra noder frågar den inte efter små bitar från åtskilliga noder om det är möjligt att fordra större bitar från färre noder. Status tabellerna tillhandahåller denna information.

Förflyttning av tokens är därför mer effektivt, och leder till färre etableringsmeddelanden och mindre fragmentering. 5. Lediga tokens skickas tillbaka till hemnoderna när de har varit overksamma under en betydande tidsperiod eller efter en lång förflyttning.

Detta schema återsänder tokens till hemnoderna som ett sätt att öka troligheten att två efter varandra följande tokens kan sammanslås i den lediga listan som minskar fragmente- ringen. Om hemnodens "gravitation" är för stark, blir schemats resultat färre delade resurser samt onödigt signalerande. Om den är för svag, kommer fragmentationen att kvarstå som ett problem. "Gravitationen" kan ändras under bussens operation.

För att kunna utvärdera defragmenteringsmekanismen utförde vi några andra simuleringar. Tre olika simulatorer (A,B,C) konfigurerades. Simulator A var konfigurerad på så sätt att den inte skulle ha någon som helst fragmentering vid simuleringens start-tid och att den skulle använda sig 10 15 20 25 30 514 485 22 av defragmenteringsschemat som har beskrivits här ovan. B startade med den kompletta resurs poolens maximala fragmentering. Alla tokens hade en enda lucka och inga tokens i "hem" noderna innan defragmenteringsmekanismen aktiverades. Slutligen startades simulator C utan att använda defragmenteringsmekanismen och med maximal fragmentering i poolen. I alla fallen aktiverades luck- àteranvändning och lasten bestämdes till 80%.

I fig. 7 visas àtkomstfördröjningen som en funktion av simulerad tid för ett lO km långt nätverk. Simulator C startade med lång åtkomstfördröjning och fördröjningen ökade då de signalerande kanalerna blev överbelastade och meddelandeköerna växte. Simulator B som använde sig av defragmenteringsmekanismen fungerade lika dåligt som C vid starten, men redan efter 10 millisekunder blev den genom- snittliga åtkomstfördröjningen mindre än 500 mikrosekunder.

Senare, när en sekund av simulerad tid hade passerat, hinner B-kurvan nästan ikapp A, d v s den sammanlöper i simulatorns prestanda trots att den startar nästan utan någon fragmente- ring överhuvudtaget. Sammanlöpningshastigheten beror på mängden av ledig kapacitet inom nätverket och därmed också på lasten. Lasten under samtliga dessa simuleringar var 80%.

Defragmenteringsmekanismen förbättrar tydligt åtkomsfördroj- ningen och gör också block token optimering meningsfull i den distribuerade modellen.

Två sorters prestandamätningar är av yttersta vikt: utnyttjandegrad samt åtkomstfördröjning. Utnyttjandegraden är den del av nominell nätverkskapacitet som faktiskt används för dataförflyttning, och det mäter effektiviteten i nätverket. Åtkomstfördröjning är tiden från en användar- begärans anländande till sändningen av den första datan i begäran, vilket är ett viktigt mått på hur trafik från datorkommunikation kan stödjas. 10 15 20 25 30 514 485 23 Till att börja med finns det två viktiga faktorer som har inflytande på utnyttjandegraden i DTM. För det första har varje nod signaleringskapacitet i form av kontrolluckor, vilket betyder att det finns färre tillgängliga luckor för dataförflyttande på en buss med många noder, för en given länkkapacitet. För det andra introduceras "overhead" i och med token reallokering eftersom då en luck-token reallo- keras mellan noder, kan inte den motsvarande luckan användas för dataförflyttning. Ãtkomstfördröjning beror huvudsakligen av lasten kontrolluckorna, och på hur många kontrollmeddelanden som behöver sändas för att kunna etablera en kanal. Tillgångs- fördröjningen är typiskt en sammanfattning av nâgra fördröj- ningar: t e x en nodkontrollants processfördröjning (5 ms), fördröjning i sökning och allokering av lediga tokens (100 ms), väntan pà att den första tillgängliga kontrolluckan skall passera (50 ms), och slutligen väntan på att den första allockerade dataluckan skall fyllas med användardata (62.5 ms). Härtill kommer att meddelanden blir fördröjda i köer vid inkörsporten till nodkontrollanter som väntar på sin process. I de simulationer som har presenterats nedan är den genomsnittliga fördröjningen upp till några hundra mikrosekunder.

Resultat från simuleringar där DTM är utsatt för trafikmönster som mer liknar de relativt kortlivade över- föringar (4-4000 kbyte) som kan ses i datakommunikation kommer här att presenteras. Trafiksorterna sker med skurvis uppträdande tider mellan ankomsterna, klient - server orienterade liksom med exponentiellt distribuerade amkomst- tider. I simuleringsmodellen börjar varje överföring med anländandet av ett nytt "paket" med information. Nodkont- rollanten försöker allokera resurser för överföringen, sänder datan och frigör slutligen kanalen. Detta är en förenkling av mekanismerna inom ett riktigt system, där 10 15 20 25 30 514 485 24 kanalens etablering, data~överföring samt kanalens frigörande är självständiga operationer som initieras av användaren. Som exempel kan nämnas att en användare som vet att en överföring skall äga rum kan "gömma" kanaletable- ringsfördröjningen genom att begära en kanal i förväg, så att den redan är etablerad när överföringen påbörjas. Under tiden mellan etablerandet och en frigörandet är kapaciteten inom kanalen helt och hållet reserverad för användaren. Den rakaste användningen av en kanal är för en enda överföring, som t ex en filöverföring eller en videosändning.

Beroende på applikationens karaktäristik, kan det vara möjligt att optimera användandet av en kanal. En kanal kan t ex användas för att överföra sekvenser tillhöriga högre nivåers meddelanden som t ex ATM celler eller IP paket (detta liknar användandet av en enda VC för all IP trafik i ett ATM nätverk). Om kanalen har flera destinationer (multicast), kan meddelanden till olika destinationer multiplexeras på kanalen. Detta innebär att varje meddelande kommer att nå varje mottagare pà multicast kanalen och mottagarna måste kunna filtrera meddelandena. En alternativ lösning är att skapa och förstöra kanalen för varje men reservera tokens mellan meddelandena så att det meddelande, dessa tokens alltid skall finnas tillgängliga för följande meddelandet i sekvensen.

Denna typ av användaruppförande finns inte inkorporerat i simulationerna, eftersom de är optimeringar för särskilda applikationer. Istället ligger fokus på hur nätverket fungerar utan optimeringar på användarnivå.

Sändaren kan börja sända data så snart resurserna har allokerats, t o m innan mottagaren erhåller kanal etableringsmeddelandet. Detta kallas snabb kanaletablering.

Mottagaren kommer till slut att svara med ett kontroll meddelande som bekräftar eller avvisar kanalen.

Användarbegäran har följande parametrar: 10 15 20 25 30 514 485 25 0 Paketstorlek, som är mängden användardata som förflyttas mellan kanal etableringen och kanal frigörandet. Vi simulerar paketstorlekarna från några få kbytes upp till några få Mbytes. 0 Begärd kapacitet för en kanal, vilket är antalet luckor som en nod försöker allokera. För alla simuleringar i denna text är den begärda kapaciteten fixerad till 40 luckor eller 20.48 Mbit/s. 0 Den minimala acceptabla kapaciteten. En nod blockerar en begäran om den inte kan allokera detta antal luckor. Detta är normalt inställt pà 40 eller 20 luckor (l00% eller 50% av den begärda kapaciteten). 0 Källadress. 0 Destinationsadress.

Käll- och destinationsadresserna generaras slumpmässigt (samtliga noder med samma sannolikhet) och tiderna mellan en användares ankomsttider är exponentiellt distribuerade.

Simuleringarna undersöker hur effekten av signalerings- kapacitet samt "overhead" pga luck-reallokering inverkar på utnyttjandegrad, kanaletableringsfördröjning samt blocke- ring. Vi simulerar varierande trafikförhållanden, för en topologi med följande karaktäristik: 0 Ett dubbel-bussnätverk med 100 noder. teoretiskt möjligt att sammanbinda många fler noder till Trots att det är en buss, tror vi att nätverkshanteringen av nätverk med fler än 100 noder på en buss kommer att vara en opraktiskt. Med 100 noder är kapacitetsdelningen tillräckligt signifikant för att utöva och testa token management protokollet. av 6.4 Gbit/s. detta är realistiskt för vad som är genomförbart inom ett 0 Varje buss har en kapacitet Vi tror att eller ett par år; 2.4 Gbit/s optiska länkar har funnits tillgängliga i nägra år, och det har annonserats att 10 10 15 20 25 30 514 485 26 Gbit/s länkar snart kommer att finnas på marknaden. 6.4 Gbit/s motsvarar 100 MHz luckfrekvens, vilket är den hastighet som den luck-processerande MAC hårdvaran skulle arbeta med denna uppnåbara hastighet med i befintlig CMOS teknologi. 0 Den totala signalkapaciteten är densamma för alla noder, men luckorna är uppdelade mellan två fiberriktningar proportionellt, beroende på var noderna är placerade på bussen. Ju närmare en nod befinner sig till luck- generatorn, desto mer kontrollkapacitet behövs det. Summan av kontrollkapacitet på båda bussarna kommer emellertid att vara densamma för alla noder. I nätverket med två token "servers" har dessa "servers" mer kontrollkapacitet och högre processeringskapacitet än de andra noderna. 0 Bussens längd är lO km, vilket ger ett tillräckligt stort nätverk, så att effekterna av spridningen inte är försumbara. Resultat från studier av effekterna av spridningsfördröjning i simuleringar med olika busslängder presenteras i figurerna ll och 13. 0 Två olika modeller för token management simuleras: ett asymmetrisk schema där alla tokens på en fiber sköts av en enda token server och ett symmetriskt schema där varje nodkontrollant sköter en liten del av den globala token poolen.

När man analyserar DTM dubbelbuss-nätverkets prestanda, måste frågan om maximal teoretisk prestanda betraktas och jämföras med den simulerade prestandan. Den maximala teoretiska prestandan används också i denna text för att jämföra de olika modeller och implementationer som vi utvärderar.

Den maximala genomströmningen i ett dubbel-buss system utan luck-återanvändning kan definieras som två gånger länk- kapaciteten, om förhållandet är så att båda fibrerna 10 15 20 25 30 514 485 27 erhåller samma trafik. I ett system med luck-återanvändning, beror systemets genomströmning också,på fördelningen av käll-/destinationspar. För att dubbelbussen skulle kunna erhålla denna genomströmning, använde vi en Monte Carlo simulering där käll- och destinationsadresser var uniformt distribuerade (se vänster graph av fig. 8). Vid jämförelse med ett DTM nätverk (simulatorkonfiguration såsom definierats nedan vid användning av en centraliserad token manager) där användaren begär stora överflyttningar (4 MB vid 20 Mbit/s kapacitet) och signaleringskapaciteten inte är en flaskhals (se höger graph av fig. 8), är utnyttjandet nära nog idealiskt. Verklig trafik som beter sig på detta sätt är bulk-data överföringar och audio/video strömmar.

Olikheterna som visas är resultat av: En del kapacitet inom DTM används av kontrolluckor som sänker antalet tillgängliga luckor som kan användas vid dataöverföringar. Slumpgenera- torerna för DTM systemet generar inte exakt samma mängd trafik i riktningarna uppströms och nedströms. Detta kan resultera i blockering av en av riktningarna när kapacitet finns tillgänglig i den andra. Under kanaletableringen kan resurserna tillfälligtvis låsas outnyttjade, vilket slösar bort en del kapacitet.

I fallet med den centrala token manager som tidigare nämnts, behöver de två noder som står för skötseln mer signaleringskapacitet än övriga noder (åtta gånger fler kontrolluckor tilldelas en servernod än till övriga noder).

Resultaten från den första uppsättningen simuleringar presenteras i fig. 9. Kanaler med 20 Mbit/s användarbegäran, tiderna mellan ankomsterna är exponentiellt distribuerade (genererade av en Poisson process) och simuleringarna utförs med olika paketstorlekar. Om hela kapaciteten för en kanal inte kan allokeras, avvisas förfrågan och tokens återsänds till sin token server. Paketstorlekar varierar från 4 Mbyte 10 15 20 25 30 514 4485 28 till 4 kbyte, vid detta läge börjar man se en försämring av genomströmningen.

Försämring av genomströmningen kan inträffa om process- kapaciteten i noderna eller kapaciteten i kontrollkanalen är för liten. Servernoderna kan vara speciellt överbelas- tade. Resultatet blir att köerna som innehåller kontroll- meddelanden börjar bli väldigt stora. Kontrolltokens representerar outnyttjad kapacitet, och därför försämras genomströmningen.

I simuleringarna för 4 kbyte per kanal är kontroll- kapaciteten den begränsande faktorn, och om fler kontroll- luckor (signaleringskapacitet) adderas, kan 4 kbyte och t o m mindre paket mer effektivt understödjas.

Den_följande uppsättningen kurvor i fig. 10 visar hur luck-återanvändningsmekanismen förbättrar systemets prestanda. Genomströmningen ökar med nästan en faktor två innan något signifikant antal kanaler avvisas. Den uniforma fördelningen av käll- och destinationsadresser för kanalerna begränsar mängden ökad kapacitet som man vinner på luck- återanvändning. Det har visat sig att om källan och destina- tionen är jämnt genererade, som vi har gjort, kan genom- strömningen fördubblas på en dubbelbuss. I simuleringarna kan man också se att bortom en erbjuden last pà 2.5 kan man faktiskt få en genomströmning som är högre än 2.0. Denna nivå av genomströmning kan emellertid inte uppnås utan att några kanaler avvisas. Kanalerna med den högsta sannolik- heten att bli avvisade är de som använder många luckor eller segment. Av denna anledning filtrerar systemet de mindre giriga användarkraven och kastar bort de andra. Detta är normalt sett inte ett acceptabelt beteende och vi undersöker därför inte detta närmare. Genomströmningsförsämring inträffar vid en erbjuden last på 1 vid överföringar på 4 kbyte. Även om tillräckliga resurser är tillgängliga inom token servern är det inte möjligt att etablera och frigöra 10 15 20 25 30 51-4 485 29 kanaler tillräckligt snabbt eftersom kontrollkanalen är överbelastad. Dessutom kan man också se en genomströmnings- försämring av 8 kbyte simuleringar vid en erbjuden last på 1.8, av samma anledning.

Man kan dra slutsatsen från simuleringarna i fig. 10 att luck-àteranvändningsmekanismen nästan fördubblar systemets genomströmning med endast smärre förändringar i det centraliserade token protokollet, så länge som kontroll- och server processing-kapaciteten inte är en flaskhals. I kurvorna kan man också oväntat se att åtkomstfördröjning faktiskt minskar när lasten ökar från 0.1 till 0.5. Detta är ett resultat av hur luckorna är tilldelade inom en kanal och inte från ett snabbare tokenkravs-förlopp. Den tid det tar att begära tokens från en server ökar strikt.

När man jämför DTM orestandan i fig. 10 och de teoretiska värdena i fig. 8 kan man se att även de korta skurarna (några få millisekunders varaktighet) kan understödjas effektivt.

När en enda token server används, kräver varje kanaletablering ett token som skall begäras från en server innan noden kan etablera kanalen. Om busslängden ökas kommer token begäran att ta längre tid och kan därför begränsa genomströmningen och öka àtkomstfördröjningen.

I fig. 11 visas resultatet av simuleringarna, i vilka busslängden ökas från 100 till 1000 km (nod till nod distans är nu 50 ms). Både åtkomstfördröjningen samt genomströmningen är nu begränsade av utbredningstiden tur och retur till en token server. Åtkomstfördröjningen i det här fallet beror på avståndet till servers, men är oberoende av överföringsstorleken. Utnyttjandegraden beror mycket på överföringsstorleken eftersom etableringsfasen kan amorteras under en lång dataöverföringsfas. Kanaler som överför stora 10 15 20 25 30 514 485 30 mängder information, som t ex 256 kbyte, med en varaktighet av en tiondels sekund kan fortfarande effektivt understödjas när busslängden är 1000 km.

När en centraliserad token manager används får man många fördelar. Klienter kan vara enkla, eftersom de bara innehåller tillståndsinformation som är relaterad till deras egna öppna kanaler. Luck-återanvändningen är också enkel och effektiv, då en token server har samtliga lediga tokens att välja bland när den försöker tillfredsställa ett användarkrav. En server kan också implementera andra policy- relaterade funktioner som t ex uppkopplingskontroll (admission control) samt rättvisa (fairness). Den lediga poolens fragmentering inom en server är normalt väldigt blygsam, vilket resulterar i väldigt få etableringsmeddelan- den per kanal, även då det gäller användarkrav som begär hög kapacitet.

Det finns också nackdelar. En användare som ofta etablerar och frigör kanaler kan introducera överskridande signalering genom att alltid återsända tokens efter användandet, för att sedan begära dessa tokens igen inom en kort tidsperiod. Processing-kapaciteten hos server noden kan bli överbelastad om det finns många noder på bussen eller om den genomsnittliga paketstorleken är väldigt liten. Om media-längden är väldigt stor i relation till produkten av Utbred- ningshastigheten tur och retur till en server kan också bit-period, bitar per paket samt mediahastighet. begränsa prestandan. Slutligen innehåller server noden information om tillstånd, som alla noder är beroende av för att kunna skapa kanaler. En server nods misslyckande kan därför ha en effekt på samtliga noder.

I nästa stycke simuleras och undersöks egenskaperna av en helt och hållet distribuerad token manager.

När man utvärderar prestandan för en distribuerad token manager med luck-återanvändning samt defragmentering, 10 15 20 25 30 51-4 485 31 använder man sig av samma trafik och parametrar som i fallet med en central token manager, men med en policy där kraven accepteras om 50% av den begärda kapaciteten kan allokeras.

Resultaten som presenteras i fig. 12 är från en en helt och hållet statusmeddelanden som beskriver simulator med luck-återanvändning, distribuerad token manager, hur mycket kapacitet en nod äger, och defragmenterings- schemat. Samtliga noder har samma processing-kapacitet och processing-lasten är mycket lägre än det som mottagarna i 10 erhåller. vilket resulterar i fig. Beroendet mellan noderna är också mycket mindre, en högre tillförlitlighetsgrad.

Systemet fungerar bättre än något annat system som inte tillhandahåller luck-återanvändning, men inte så bra som det centraliserade systemet luckåteranvändning som beskrivits tidigare.

När man jämför den här konfigurationens prestanda och den centraliserade token manager i fig. 10, ser man att blockeringen är högre och vissa krav kan blockeras vid en mycket lägre last i den distribuerade implementationen.

Ett oväntat resultat var att prestandan faktiskt minskade när paketstorleken ökade! Efter en ytterligare kontroll av resultaten fann man att en stor genomsnittlig överföringsstorlek resulterar i mindre token-rörelse och att förhållande-informationen faktiskt ger en ännu sämre syn på fria resurser inom nätverket än för korta överföringar. I detta fall avvisas en begäran om man inte tror att man skall hitta några resurser. Denna mekanism introducerades för att undvika att kontrollkapacitet skulle slösas bort när IêSuISefna Var Utarmadê .

Anledningen till detta är att statusmeddelandena bara beskriver "globala" tokens som täcker alla segment på bussen. Ett globalt token kan användas av vilken nod som helst och är det enda sortens token i ett DTM system utan luck-återanvändning. Vid en last som är högre än 1.00 10 15 20 25 30 514 485 32 segmenteras ett stort antal tokens och återanvändnings- schemat behöver dem för att kunna använda dem till nya förfrågningar. Därför är mekanismen med statusmeddelanden som används (och som utvecklades för ett system utan återanvändning) begränsad i sina möjligheter att tillgodose nya krav i deras sökande efter ledig kapacitet, och kan i värsta fall resultera i högre blockering.

Genomströmningen och åtkomstfördröjningen i en distribuerad token manager med busslängder från 1 km till 1000 km presenteras i fig. 13. Ett litet 16 kbyte paket sänds mellan etablering och frigörande av en kanal, för stora paket (100-tals kbytes) är genomströmningsprestandan i systemet mycket mindre påverkat av busslängden. Bussarna som är 1 km och 100 km ger ungefär samma resultat vad avser genomströmning och åtkomstfördröjnings som den 10 km långa' bussen, eftersom fördröjningen som introduceras när en 125 ms cykel används, dominerar över utbredningstiden inom systemet. Beträffande den 1000 km långa bussen kan man se att åtkomstfördröjningen blir mycket kortare än i 1000 km systemet då man använder en centraliserad token server, speciellt vid låg last, då man finner tokens väldigt nära noden till vilken användarförfrågan anländer och fördröj- ningen är ungefär densamma i alla system. T o m vid väldigt hög börda är åtkomstfördröjningen ungefär en millisekund kortare än i systemet med en centraliserad server.

Det centraliserade token manager systemet har samma prestanda nästan oberoende av trafiken så länge som processing- och signaleringskapacitet är tillräckliga. För att kunna utvärdera det distribuerade systemet använde vi oss av två andra trafikgeneratorer. Först använde vi en generator som simulerar användarkrav som anländer i skurar.

När en begäran anländer definierade vi att en ny begäran skulle anlända med 90% trolighet efter 200 ms. Resultatet blev, att en skur av fordringar anländer till en nod och 10 15 20 25 30 514 '485 33 tvingar hög temporallokkalitet hos källadresserna. För det andra, för att generera trafik som är mer lik klient-server beteendet, ökades mängden trafik som anlände till 5 server 25, 50, 75 och 99. Troligheten att finna en server-destination är också högre. noder: nummer 0, I fig. 14 presenteras prestanda av genomströmning samt åtkomstfördröjnings i det distribuerade token server systemet.

Det är uppenbart att den distribuerade modellen har flera fördelar men också nackdelar jämfört med en centrali- serad token server. Noderna kan dela processing-lasten, behovet av hög-presterande token servers är lägre, redundan- sen kan vara högre och åtkomstfördröjning kan vara kortare för lägre kapacitetskrav. Nackdelarna är högre blockering för en oflexibel användare som därför kanske måste åter- upprepa försök många gånger för att få tillgång till de nödvändiga resurserna. Det är också uppenbart att status- meddelanden och mekanismen med statustabell måste ändras för att undvika onödig blockering när luck-återanvändning är tillåten.

När bördan ökar över en viss grad, blir det svårt att finna lediga tokens, blockeringen blir betydlig och utnytt- jandet ökar endast marginellt med lasten. Graden av blocke- ring vid en given last beror mest på minimikapacitets-kraven i användarens begäran. Ju lägre minimikapacitet, desto högre är troligheten att noden skall kunna tillfredsställa kravet.

Dessutom sänds bara en omgång token-krav ut för varje användarbegäran i dessa simuleringar. Utnyttjandet kan ökas om man genomför flera omgångar (d v s använder återförsök), på bekostnad av längre åtkomstfördröjning.

Om man antar att de ovan nämnda väntetiderna är obero- ende, kommer den genomsnittliga åtkomstfördröjningen, om en enda kontrollucka finns och om nätverket har en lätt belast- ning, och lånandet är inte är tätt, att resultera i en 10 15 20 25 30 514485 34 genomsnittlig àtkomstfördröjning på ungefär 125 ms (en enda cykel).

Dessutom kan det behövas många kontrollmeddelanden för att kunna etablera en kanal, p g a fragmentering, vilket ökar lasten på kontrollkanalen ännu mer, och därmed också åtkomstfördröjningen. Faktum är, att utan något effektivt "defragmenteringsschema" blir fragmentering den dominerande bidragande orsaken till åtkomstfördröjningen i simule- ringarna. I En konsekvens av DTM's luck-reallokeringsmekanism är att det tar längre tid att etablera kanaler som kräver hög bandbredd. Denna kompromiss kan rättfärdigas: Den typen av trafik som behöver kort genomsnittlig åtkomstfördröjning är oftast mindre känslig för mängden bandbredd som har allokerats för överföringen, och sådan trafik kan därför accepteras utan speciellt mycket engagemang av realloke- ringsprotokollet. För överföringar som kräver hög bandbredd, kommer àtkomstfördröjningen att bli mycket längre och kommer nästan alltid att engagera reallokeringsprotokollet. Gene- rellt sett, kommer emellertid höga bandbreddsöverföringar förmodligen att vara mindre känsliga för åtkomstfördröjning.

Dessa simuleringar har visat att DTM's protokoll för snabb kretskopping uppvisar god prestanda för en dubbel-buss med delat medium. Två modeller för token management har analyserats och båda presterar väl och kan dra fördel av luck-återanvändning. Den centraliserade modellen ger den prestanda som närmast liknar det idealiska fallet och resulterar också i en enkel implementation. Det distribue- rade systemet är mer känsligt för användar-beteendet och måste därför stå i ett beroendeförhållande till statusinfor- mation som sänds ofta och till metoden och arrangemanget för defragmentering enligt uppfinningen, för att minska antalet kontrollmeddelanden som krävs för kanal-etablering och luck- reallokering. Om man använder defragmenteringsmetoden på 10 15 514 485 35 långa bussar, uppvisar den distribuerade modellen bättre prestanda än den centraliserade modellen (jämför figurerna ll och 13). Ett resurs management system som kombinerar den centraliserade och den distribuerade modellen genom användning av en liten uppsättning token server noder är också möjligt.

Dessutom kan "overhead" pga kanaletablering hållas väldigt låg, vilket resulterar i högre utnyttjande även inom små (några få kbytes) överföringar. Åtkomstfördröjning befinns vara några hundra mikrosekunder även vid hög last.

Metoden för återanvändning av tidluckor kan öka prestandan med en faktor två utan att introducera någon ytterligare hårdvara i noderna. Vid användandet av metoden för återanvändning av tidluckor är det viktigt att man använder metoden och arrangemanget för defragmentering enligt uppfinningen, eftersom fragmentering kan inträffa i både tidlucke- och segmentdimensionerna.

Claims (17)

10 15 20 25 514 '485 36 Patentkrav

1. Plan för defragmentering för att öka den genomsnittliga blockstorleken av fria token i noderna inom ett DTM (Dynamic Synchronous Transfer Mode) nätverk, kännetecknad av -att en hemnod definieras för varje token vid nätverkets uppstartande eller under operation av nätverket på så sätt att tokens som delar samma hemnod kommer att definiera en åtminstone delvis oavbruten följd av kontinuerliga tidluckor - att lediga tokens skickas tillbaka till sina respektive hemnoder när en signifikant tid har passerat och, - att två eller flera tokens som representerar en följd kontinuerliga tidluckor sammanslås till ett enda token när de existerar i en nods fria pool.

2. Plan för defragmentering enligt kravet l, kännetecknad av att en enda hemnod definieras för samtliga tokens vid nätverkets uppstartande eller under operation av nätverket.

3. Plan för defragmentering enligt kravet l, kännetecknad av att samtliga noder definieras som hemnoder bland vilka tokens distribueras vid nätverkets uppstartande eller under operation av nätverket.

4. Plan för defragmentering enligt kravet 1, kännetecknad av att en uppsättning noder definieras som hemnoder, bland vilka tokens är distribuerade vid nätverkets uppstartande eller under operation av nätverket.

5. Plan för defragmentering enligt något av kraven l - 4, kännetecknad av att tokens kan omfördelas till nya hemnoder under operation av nätverket. 10 15 20 25 514 485 37

6. Plan för defragmentering enligt något av kraven 1- 5, kännetecknad av att lediga tokens återsänds till sina respektive hemnoder när de har varit oanvända under en signifikant tid.

7. Plan för defragmentering enligt något av kraven 1 - 5, kännetecknad av att lediga tokens återsänds till sina respektive hemnoder när de inte har varit hos sin hemnod en signifikant tid, en s k sista hemtid. 1 - 5, kännetecknad av att lediga tokens återsänds till sina

8. Plan för defragmentering enligt något av kraven respektive hemnoder efter ett signifikant antal signalöverföringar.

9. Plan för defragmentering enligt något av kraven 1 - 8, kännetecknad av att när en nod erhåller ett begöran om token skall ett token väljas från den lediga token poolen i en nod, och från en lokal användare eller en avlägsen användare, använda en algoritm för bästa möjliga anpassning, i vilken det token med lägst antal luckor som ändå kan tillfredsställa kravet på tillräcklig kapacitet skall väljas.

10. Plan för defragmentering enligt något av kraven 1 - 8, kännetecknad av att när en nod behöver begära ett token från andra noder och inget token finns som kan tillgodose den begärda kapaciteten, skall antalet nödvnändiga tokens minimeras.

11. ll. Plan för defragmentering enligt något av kraven 1 - 10, kännetecknad av att den kombineras med en metod för återanvändning av tidluckor i vilken 10 15 20 25 30 514 485 38 - DTM block token formatet förlängs för att inbegripa parametrar som beskriver segment(en) mellan käll- och destinationsnod. - block token kapaciteten reserveras enbart på segment(en) mellan käll-och destinationsnod, och - simultana transmissioner i samma lucka över åtskilda segment inom nätverket möjliggörs.

12. kännetecknad av att tvâ eller fler segment-åtföljande tokens Plan för defragmentering enligt kravet ll, som motsvarar samma grupp av tidluckor sammanslås till ett enda token när de samexisterar i en nods fria pool.

13. Plan för defragmentering enligt kravet ll, kännetecknad av att två eller flera luck-åtföljande tokens som representerar samma grupp av segment sammanslås till ett enda token när de samexisterar i en nods fria pool.

14. Plan för defragmentering enligt kravet 13, kännetecknad av att två segment-åtföljande tokens, som åtminstone delvis respresenterar samma grupp av tidluckor och samexisterar i en nods fria pool, delas för att erhålla segment-åtföljande tokens som representerar samma grupp av tidluckor, vilka sammanslåss till ett enda token.

15. Plan för defragmentering enligt något av kraven ll - 14, kännetecknad av att när en nod erhåller en begäran om token från en lokal användare eller från en avlägsen användare, väljs ett token från token poolen och en algoritm för bäst anpassning i tidluckenummer- och segmentnummerdimensionerna används, i vilken algoritm det token med det minsta området i token kartan eller den lägsta kostnadsfunktionen och som ändå kan tillgodose den begärda kapaciteten väljs. 10 15 514 485 39

16. Plan för defragmentering enligt något av kraven ll - 14, kännetecknad av att när en nod behöver begära ett token från andra noder och inget token finns som kan tillgodose den begärda kapaciteten, skall antalet nödvändiga tokens minimeras.

17. Ett arrangemang för defragmentering för att öka den genomsnittliga block storleken hos lediga tokens i noderna inom ett DTM (Dynamic Synchronous Transfer Mode) nätverk, kännetecknad av att det omfattar - hemnoder, för vilka tokens definieras på så sätt att de tokens som delar samma hemnod definierar åtminstone delvis en oavbruten följd av kontinuerliga tidluckor, - noder arrangeras så att de återsänder lediga tokens till sina respektive hemnoder när en signifikant tid har passerat och, - noder arrangeras så att de sammanslår två eller flera lediga tokens för kontinuerliga tidluckor till ett enda token.