SE515901C2 - Resursadministrering, plan och arrangemang - Google Patents

Description

20 \ 515 ëm tillämpningar sàsom fax, post- och filöverföring, och för- dröjningskänsliga tillämpningar med realtidskrav, såsom audio och video. Dessa olika tillämpningar har traditionellt stöt- tats av olika nätteknologier. Asynkron kommunikation har till- handahàllits av datanät som är datapaketförmedlade och an- vänder lagrings- och -sändningstekniker (store-and-forward techniques), såsom Internet. Realtidskommunikation å andra sidan har tillhandahällits av kretskopplade, tidsmulti- plexerade telefonnät.

Kretskopplade nät har många attraktiva egenskaper. Kretsar isoleras fràn varandra i den betydelsen att trafik på en krets är opåverkad av aktiviteter på de andra. Detta gör det möjligt att tillhandahålla garanterad överföringskvalitet med konstant fördröjning, vilket är lämpligt för tillämpningar med tidskrav. Vidare är data och styrning separerade i kretskopplade nät. Bearbetning' av styrinformation. sker bara vid upprättande och nedrivning av kretsar och den aktuella dataöverföringen kan göras utan att bearbeta dataströmmen, stockningsstyrningen etc. Detta medger att stora volymer data kan överföras effektivt. Vi tror att detta kommer att bli än viktigare i framtiden emedan utvecklingar i fotonik kommer att dramatiskt minska transmissionskostnaden och omkopplare kommer att bli de stora kommunikationsflaskhalsarna_ Den statiska naturen hos ordinära kretskopplade nät gör dem olämpliga för vissa typer av trafik. Traditionellt har kretsar fixerad kapacitet, lång upprättandefördröjning och dåligt stöd för fleradressering. Dessa nackdelar gör det svårt att 10 15 20 2:25 515 9 o 1 g: effektivt stödja exempelvis datakommunikation i ett kretskopplat nät. Detta är motivet för att försöka undersöka alternativa lösningar och den mest framträdande uppfattningen är att nästa generation telekommunikationsnät kommer att vara cellkopplade, baserade på ATM. Celler är små paket med fixerad storlek så att detta är en orientering mot datapaket- förmedling. Detta innebär att många av svagheterna hos datapaketförmedlingar, nu även finns i cellkopplade nät, särskilt i området för att tillhandahålla garanterad servicekvalitet. Därför behövs ytterligare mekanismer, såsom tillträdeskontroll, trafikreglering, tidsbestämmande paket på länkar och återsynkronisering vid mottagaren för att integrera stöd för olika typer av paket. En av huvudangelägenheterna med datapaketförmedlade nät i allmänhet, och ATM i synnerhet, är om det är möjligt att realisera dessa mekanismer på ett kostnadseffektivt sätt.

DTM, dynamiskt synkront överföringssätt, är en bredbandsnät- uppbyggnad som försöker kombinera fördelarna med kretskoppling och datapaketförmedling j. det att det är' baserat på snabb kretskoppling förstärkt med dynamisk reallokering av resurser, stöder fleradresskanaler och har medel för att tillhandahålla kort accessfördröjning. DTM-uppbyggnaden spänner från medium- access, däri ingående en synkroniseringsplan, upp till diri- gering och adressering av logiska portar vid mottagaren. DTM år konstruerad att understödja olika typer av trafik och kan användas direkt för tillämpnings-till-tillämpnings- kommunikation, eller som ett bärarnät för andra protokoll, såsom ATM eller IP. Ett prototypförverkligande baserat på 622 10 15 20 “fšzß 515 9 01 gi: Mbit/s optiska fiber har varit i drift under två år och arbetet fortgår med en våglängd-divisionsmultiplexerad version med fyra våglängder. En översikt av DTM med en mera detaljerad beskrivning av prototypförverkligandet är tidigare publicerad.

Snabb kretskoppling föreslogs för användning i telefonsystem redan tidigt 1980-tal. Ett snabbt kretskopplat telefonnät försöker allokera en transmissionsbana med en given datahastighet till en uppsättning nätanvändare_endast när de Detta aktivt sänder information. innebär att en krets upprättas för varje informationsskur. När tystnad detekteras reallokeras transmissionskapaciteten snabbt till andra an- vändare. I den form som används i TASI-E, har snabb kretskoppling utvecklats för interkontinental kommunikation mellan Europa och Förenta staterna. Skuromkoppling är en annan form för snabb kretskoppling där en skur (bestående av ett startpaket, en godtycklig mängd data och ett avslutningstecken) sänds tidstilldelningskanalen med fixerad bithastighet och sammanflätas således med andra skurar. Detta gör att skuromkoppling skiljer sig från snabb datapaketförmedling där paketen sänds en i taget med full länkbandvidd. Vidare är längden för en skur, i motsats till ett paket, ej bestämd före starten för överföring.

Det har visat sig att signalfördröjning associerad med skapande och nedrivning av kommunikationskanaler bestämmer mycket av effektiviteten hos snabb kretskoppling. DTM är därför konstruerat att snabbt skapa kanaler, inom några hundra mikrosekunder. DTM skiljer sig från skuromkoppling i det att 10 15 20 va...

.Läs 515 901 kontroll och data är separerade och fleradresserade, högkapacitiva multihastighetskanaler används för att stödja en mängd olika trafikklasser. Detta innebär t.ex. att det är möjligt att öka eller minska de allokerade resurserna hos en befintlig kanal. Även om ett DTM-nät kan ha potentialen att skapa en kanal för varje meddelande så tror vi inte att denna väg är lämplig för alla trafikklasser. Det är snarare upp till användaren att besluta owl han skall upprätta *en kanal per informationsskur eller att hålla kanalen upprättad även under passiva perioder.

Syftet med detta dokument är att studera prestandan hos snabb kretskoppling i DTM, med fokus pà en dynamisk resursad- ministreringsplan och med målet att demonstrera hur denna kan stödja trafik sonx består av korta, frekventa överföringar.

Detta dokument är organiserat såsom följer. Sektion 2 ger en introduktion till DTM, beskriver kanalkonceptet och resursad- ministreringsplanen och diskuterar hur några av problemen med traditionell kretskoppling behandlas. Sektion 3 rapporterar och diskuterar simuleringsresultat för olika konfigurationer såväl för enstaka som multi- hoppförbindningar (multi-hop connections). Slutligen dras slutsatser i sektion 4. 2 DTM-dynamiskt synkront överföringssâtt DTM är konstruerat för ett enkelriktat medium med multipel åt- komst, dvs. ett medium med kapacitet delad av alla anslutna noder. Det kan byggas med flera olika topologier, såsom ring, omvikt buss eller dubbelbuss. Vi väljer dubbelbussen emedan den har kortare genomsnittligt internodavstànd än en omvikt 10 15 _w2O 5:25 515 901 buss och DTM's synkroniseringsplan befanns vara lättare att förverkliga pà en dubbelbuss än på en ring.

Den tjänst som tillhandahålls baseras pá kanaler. En kanal är en uppsättning tidluckor med en sändare och ett godtyckligt antal mottagare; det garanteras att data kommer att nà motta- garna vid den hastighet som ges av kanalens kapacitet.

Kanalerna på det fysiskt delade mediumet realiseras genom en tiddelningsmultiplexplan (TDM)(fig. 1). Den totala kapaciteten uppdelas i cykler om 125 mikrosekunder som ytterligare uppdelas i 64 bits tidluckor eller luckor.

Luckorna är separerade i data- och styrluckor. Varje nod har access till åtminstone en styrlucka som används för att sända styrinformation till de andra noderna. Styrmeddelanden kan sändas på begäran från en användare, som svar pà styrmedde- landen från andra noder eller spontant för administreringssyf- ten. Styrluckorna utgör en liten bråkdel av den totala kapaci- teten under det att den större delen av luckorna är dataluckor som uppbär nyttolast. Vid systemets uppstart allokeras data- luckorna till noderna enligt någon fördefinierad distribution.

Detta innebär att varje nod "äger" en del av dataluckorna. En nod behöver äganderätten till en lucka för att sända data in i denna och äganderätten till luckor kan ändras dynamiskt bland noderna under nätdrift. 2.1 Luckallokering DTM använder en distribuerad algoritm för luckreallokering där poolen av fria luckor distribueras bland noderna. Det fanns 10 15 20 N.Éj25 515 901 två huvudskäl för att använda en distribuerad plan i stället för en central pool av luckor. För det första, när en nod kan upprätta en kanal utnyttjande bara luckor från den lokala poolen finns det mycket lite overhead i kanalupprättandet. För det andra är en distribuerad algoritm inte beroende av en enda nod så den har viss tolerans mot nodfel. Den huvudsakliga nackdelen med ett distribuerat förverkligande är overhead hos kommunikation och synkronisering mellan noder.

Vid mottagande av en användarbegäran kontrollerar noden först sin lokala pool för att se om den har tillräckligt med luckor för att tillfredställa begäran och, om så, sänder den omedelbart ett kanalupprättandemeddelande till nästa hopp. I annat fall mäste noden först begära flera luckor från de andra noderna på bussen. Varje nod håller en statustabell som inne- hàller information om de fria luckorna i andra noder och när flera luckor behövs så konsulterar noden sin statustabell för att besluta vilken nod han skall fråga om luckor. nod Varje sänder regelbundet ut statusmeddelanden med information om sin lokala pool av luckor. Statusmeddelanden har lägre prioritet än andra styrmeddelanden så att det sänds bara när styrluckan i annat fall skulle vara oanvänd.

Vidare är reallokeringsalgoritm inte beroende av noder för att bearbeta alla statusmeddelanden så en nod kan helt säkert ignorera statusmeddelanden om den är upptagen.

Proceduren för luckreallokering är enkel och arbetar som följer: om en användare begär en kanal med M luckor och noden har N fria luckor där N är mindre än M sänder den begäran och 10 15 fï2O "If25 515 901 ber om M-N luckor. Noden startar genom att sända en begäran till den närmast belägna noden med fria luckor. Om denna nod inte har tillräckligt många fria luckor enligt statustabellen sänds också en begäran till den andra närmaste noden med fria luckor och så vidare. Noden väntar till ett svar på var och en av hans begäran har mottagits och godkänner eller kasserar ka- nalbegäran beroende på utgången av reallokeringsproceduren.

En nod som har viss' mängd J fria luckor och mottager en luckreallokeringsbegäran om K luckor kommer alltid att ge bort minimum av J och K luckor. Noden svarar genom att sända en luckreallokeringsbekräftelse som indikerar vilka luckor som noden ger bort. Om den begärda noden inte har några fria luckor svarar den med ett luckreallokeringsavslag i stället.

Förutom denna algoritm kan resurser styras av ett nätadministreringssystem. För att exempelvis hindra nätet från utsvältning kan en nod konfigureras att ge bort alla dess luckor men hålla en viss bråkdel av dess initiala del. 2.2 Omkoppling Ett DTM-nät kan expanderas genom att förbinda flera bussar med kopplingsnoder (se fig. 2). decentraliserad DTM använder omkoppling' i den meningen att varje nod ansluten till två eller flera bussar kan koppla om data mellan dem. En fördel med detta är att omkopplingskapaciteten kan gradvis ökas genom att lägga till flera kopplingsnoder. Ömkopplingen är synkron vilket innebär att omkopplingsfördröjningen är konstant för en kanal. Detta innebär att en multi- hoppkanal har i stort sätt samma egenskaper som en kanal på en enstaka buss. Den enda 10 15 20 515 901 skillnaden är att en omkopplad kanal har något längre fördröjning (upptill 125 mikrosekunder för varje hopp).

Förutsatt att en kopplingsnod kan buffra en datacykel för var och en av dess bussar så kan det i den noden inte bli någon stockning eller spill.

Synkroniseringen. mellan bussar görs på en per-cykel-basis; cykler startas med samma frekvens på alla bussar. Detta upp- fylles genom att låta en nätnod vara ansvarig för periodisk generering av cyklerna på alla dess utgående bussar. För varje ny cykel genererar denna nod en cykelstartmarkör som sänds vi- dare till alla bussar i nätet. För varje buss finns en kopp- lingsnod som är ansvarig för vidarebefordran av markören till bussen. Dessa kopplingsnoder behöver organiseras på så sätt att markören når varje buss exakt en gång. När markören når en buss återstartar cykeln på denna buss. Läsaren hänvisas av- seende mera detaljer till synkroniseringsschemat.

Cykeltiden och luckstorleken är båda konstanta för alla bussar vilket innebär att synkroniseringsplanen medger olika bussar att köras vid olika bithastigheter. Detta gör det möjligt att uppgradera eller rekonfigurera individuella bussar i ett nät utan att påverka resten av nätet. 2.3 DTM-kanaler Kanalabstraktionen i DTM skiljer sig.fràn vanliga kretsar i det att kanaler har följande egenskaper. lO 15 ï-.Emào 'íflgs 515 901 10 0 Simplex: en kanal sätts upp från sändare till mottagare. En duplexförbindelse består av två kanaler, en i vardera rikt- ningen. 0 Multihastighet: kanaler kan bestå av ett godtyckligt antal dataluckor, vilket innebär att kanalkapaciteten kan vara varje multipel av 512 kbit/s, upp till hela bussens datakapacitet. 1 0 Fleradress: en kanal kan ha flera mottagare.

En nod skapar en kanal genom att allokera en 'uppsättning dataluckor för kanalen och genom att sända ett styrmeddelande om kanalens etablering. Styrmeddelandet adresseras antingen till en enda nod eller till en fleradressgrupp och annonserar att kanalen har skapats och vilka luckor den använder.

För att skapa en kanal måste luckor allokeras vid sändaren och vid varje kopplingsnod längs kanalens väg. Således allokerar kopplingsnoder luckor för en kanal på uppdrag av sändaren.

Kopplingsnoderna börjar sedan omkoppla kanalen genom att kopiera kanalens luckor från den inkommande till den utgående bussen; Ett försök att upprätta en multi- hoppkanal misslyckas om någon av kopplingsnoderna som är inblandade inte kan allo- kera den begärda mängden luckor. I detta fall måste en annan väg försökas. I en gallerstruktur finns det normalt flera vägar mellan varje par noder. Den aktuella versionen av pro- tokollet använder källvägval tillsammans med en adressplan baserad på koordinater i gallret. (x,y) En enkel belastnings- balanseringsplan för två hopp uppnås genom att låta varje 10 15 fï2O 515 901 ll kopplingsnod använda statusmeddelanden för att sända informa- tion om mängden fria luckor pà dess utgående bussar. Så exempelvis finns det två möjliga vägar mellan nod 1 och nod 4 i fig. 2 så om noden 1 vill sätta upp en förbindelse med noden 4 kan den välja mellan att använda kopplingsnoden 2 och kopplingsnoden 3. Noden 1 mottar statusinformation från noden 2 och 3 och kan göra sitt vägvalsbeslut baserad. på denna information. Denna algoritmen fungerar bra för täta gallernät där de flesta vägar bara använder tvà hopp 'men en allmän vägvalsalgoritm behövs för flera godtyckliga topologier. 2.3.1 Fleradresskanaler En traditionell krets är en punkt-till-punktförbindelse mellan en sändare och en mottagare. DTM använder ett delat medium som till sin natur understödjer fleradress emedan en lucka kan läsas av flera noder pà en buss. En fleradresskanal kan lätt utökas att spänna över flera hopp emedan kopplingsoperationen i verkligheten är en fleradressoperation i den betydelsen att den duplicerar data pà en annan buss (se fig.-3). 3 Nätprestanda I denna sektion undersöker vi genomströmning och fördröjning under varierande trafiktillstánd. Vi har utfört simuleringar för två olika nättopologier: 0 En dubbelbuss med 100 noder. 0 Ett helt förbundet galler av dubbelbussar med 20x20 noder. lO 15 20 5 1 5 9 0 1 :it-f 12 I simuleringsmodellen mottar noder överföringsbegäran från en trafikgenerator och styrmeddelanden frán andra nätnoder. Dessa händelser läggs i en inmatningskö vid noden och noden bearbetar en händelse åt gången. Tiden för att behandla en händelse är 5 ndkrosekunder. Överföringsbegäran genereras av Poissonprocesser och käll- och destinationsadresser dis- tribueras likformigt. För varje överföringsbegäran försöker en nod att allokera luckor och, om detta lyckas, etablerar kanalen, överför data och tar ner kanalen. Detta innebär att luckorna frigörs (lediggörs) så snart som överföringen är gjord.

Simuleringarna genomföres för olika överföringsstorlekar (1- 256 kbytes) för olika typer av användarkrav' och för olika internodavstånd (0.0l-10 kilometer). Länkens bithastighet är 4.8 Gbit/s som ger en luckhastighet av 75 MHz och en cykelstorlek av 9600 luckor. Varje överföring begär 40 luckor per cykel. Detta svarar mot 20.48 Mbit/s-kanaler vilket som, exempel innebär att en 16 kbytes överföring tar omkring sex millisekunder.

Vi beräknar* genomströmningen. genonl att dividera den totala mängden. Överförd användardata. med. den simulerade tiden och normaliserar detta värde mot kapaciteten hos en dubbelbuss (9.6 Gbit/s). Den maximala genomströmningen som är möjlig att emedan viss uppnå är alltid mindre än länkkapaciteten, kapacitet används för styrmeddelanden. I dubbel- bussimuleringarna, med 100 noder, är styrkapaciteten 5 10 15 20 ...m- _35 515 901 13 styrluckor per nod, vilket svarar mot 5% overhead. Maximalt möjliga genomströmning är då 0.95.

Gallret har fler noder än den enstaka dubbelbussen men färre noder "per buss (20 i stället för 100). Emedan trafikbe- lastningen på en buss distribueras över dess noder så innebär detta att vid en given bussbelastning kommer gallret att ha mer trafik till och från varje nod. En nod i gallret behöver därför flera styrluckor. Emellertid har en _nod begränsad kapacitet att behandla styrmeddelanden och vi har funnit att med 5 mikrosekunders händelsebearbetningstid uppnås mycket liten prestanda genom att använda mer än 10 styrluckor per nod. Vi använder därför 10 styrluckor per nod i gallret vilket ger en maximalt möjlig genomströmning av 0.98.

Accessfördröjning är genomsnittstiden från den tidpunkt då en begäran anländer till noden. till dess att dataöverföringen startar. Det är ett mått på overheaden vid kanaletablering och innefattar' den tid det tar att allokera. luckor, sända ett kanaletableringsmeddelande till mottagaren~ och sända den första luckan av data. I multi-hoppfallet väntar sändaren på bekräftelse från mottagaren att kanalen har upprättats på båda bussarna innan den startar datasändningen. För det enstaka hoppfallet skapar sändaren ensam kanalen till mottagaren och kan därför starta datasändning så snart som luckorna har allo- kerats. 3.1 En dubbelbuss 10 15 20 _:25 14 Den första uppsättningen simuleringar avser prestanda hos en dubbelbuss. Syftet med dessa simuleringar är huvudsakligen att studera luckallokeringsplaner för olika användarkrav. Emedan luckallokeringar pà olika bussar är oberoende operationer så är dessa resultat i allmänhet tillämpbara för även multi- hoppfall. 3.1.1 Strikt kapacitetsefterfrågan utan att utföra nya försök Fig. 4 visar resultatet av en bassimulering där en nod gör högst ett försök att allokera den begärda kapaciteten för en kanal och avslår begäran om den fulla begärda kapaciteten inte kan allokeras. Överföringsstorlekar emellan l och 256 kbytes simuleras. Simuleringarna kunde inte utföras för de minsta överföringarna (1 och 2 kbytes i fig. 4) vid hög belastning beroende på att simulatorhändelsekön växte och blev alltför stor vilket indikerar att styrkapaciteten är uttömd.

Vid-làg belastning accepteras de flesta överföringsbegäranden omedelbart och genomströmningen ökar därför linjärt med belastningen. Vid högre belastning blir luckreallokering frek- vent, några överföringsbegäran kasseras och genomströmningen ökar bara marginellt med belastningen. Om belastningen blir än högre uttöms signalkapaciteten och genomströmningen ökar inte (eller går ned såsom i fallet för 1 kilobyte överföringar i fig. 4). Mindre överföringar behöver mera frekvent styrsignalering än stora överföringar vid en given belastning och därför är genomströmningen lägre för mindre överföringar än för större (på sin höjd uppnås 0.47 för en kilobyte överfö- vilket är 50% ringar, av maximalt möjlig genomströmning, 10 15 _"2O 515 901 15 jämfört med 85% för 256 kbytes överföringar). Genomströmning begränsas således genom strikt användarbeteende, krävande hela den begärda kapaciteten att allokeras i ett enda försök. Nedan rapporterade simuleringar visar att genomströmningen kan ökas genom att koppla av detta krav.

Accessfördröjningen består, vid låg belastning, huvudsakligen av den tid det tar för en nod att behandla överföringsbegäran, vänta på första tillgängliga styrlucka (för kanaletable- ringsmeddelande), och sedan på den första dataluckan (tillsam- mans 80 ndkrosekunder som ett genomsnitt). När belastningen ökar måste noder begära luckor från andra noder och ytterligare fördröjning införes. 3.1.2 Strikt kapacitetsefterfrågan med nya försök Det är möjligt att öka genomströmningen genom att låta en nod försöka på nytt, dvs. göra fler än ett försök att allokera luckor för en kanal. Fig. 5 visar genomströmning och åt- komstfördröjning för olika värden av maximalt tillåtet antal nya försök. När noder medges försöka på nytt kan flera kanaler upprättas och genomströmningen öka (upptill 92% av naximalt möjliga genomströmning), men på bekostnad av längre accessfördröjning och mer signalering. Således är flera försök bäst lämpade för tillämpningar som har strikt bandbreddsefterfrågan men kan tolerera någon accessfördröjning. Om emellertid ett stort antal begäran envist omfràgas (som i en överbelastningssituation), så kommer prestandan att försämras. Fig. 5 visar att prestandan minskar när belastningen är hög och noder medges att göra nya försök 10 15 ffgo fàß 515 9Ü1 16 20 gånger vilket indikerar att signalkapaciteten inte är tillräcklig för 20 omfràgningar. 3.1.3 Flexibel kapacitetsefterfrågan En tillämpning med mindre stringenta efterfrågningar av kapacitet kan iordningställas för att acceptera kanaler med mindre kapacitet än vad som begärts. Detta medger att flera kanaler' kan. etableras 'vid. ett enda luckreallokeringsförsök.

Fig. 6 visar genomströmning och fördröjning för tre fall: när användaren nöjer sig med vilken kapacitet som helst (minimum 1 lucka), kräver åtminstone halva den begärda kapaciteten (20 luckor), och behöver den fulla kapaciteten (40 luckor). Genom- strömning går upp när användaren är mindre krävande. När an- vändaren begär endast en lucka är den uppnådda genomström- ningen 94% av maximalt möjliga genomströmning. Luckrealloke- ringsproceduren är emellertid densamma i alla tre fallen, vilket förklarar varför accessfördröjning är praktiskt taget densamma i dessa tre fall. 3.1.4 Prestanda som en funktion av avstånd När avståndet mellan noder ökar så tar det längre tid att utbyta styrmeddelanden för luckreallokering. Detta kan ses i fig. 7 som visar genomströmning och accessfördröjning för olika busslängder (med strikt kapacitetsefterfràgan utan omförsök, dvs. samma luckallokeringsprincip som i. fig. 4).

Accessfördröjningen ökar signifikant när bussen blir längre.

Men detta påverkar i huvudsak frambringandet av kanaler och genomströmningen är därför relativt oberoende av avstånd. En lO 15 _H2O “f ïfi25 515 901 17 annan effekt med ökad busslängd är att det tar längre tid att sprida statusinformation, vilket kan öka möjligheten för luckreallokeringsfel. Detta skulle huvudsakligen påverka genomströmning men- simuleringsresultaten indikerar att det bara har en mindre effekt. 3.2 Gallernät Fig. 8 visar resultatet av en simulering för multi-hopp- kanaler. Nätet är ett helt ut förbundet gallernät med 20x20 noder. Kanaler använder högst två hopp och vägvalsbeslutet ba- seras på informationen från statusmeddelanden. Luckalloke- ringsprincipen är densamma som i fig. 4, dvs. strikt efter- frågan utan omförsök.

Med likformig distribution av källdestinationspar är den teoretiskt maximala genomströmningen hos ett fullt förbundet galler n/2+1, där n är antalet bussar. Med 2.l% signaloverhead har 20x20-gallret en maximalt möjlig genomströmning av ungefär 20.6%. Fig. 8 visar att för 256 kilobyte överföringar är den maximala genomströmningen 37.5% av det möjliga maximala, jämfört med 95.1% för 16 kilobyte överföringar. Detta är signifikant mer än i fallet en dubbelbuss (fig. 4) och vår förklaring till detta är att det finns mindre noder per buss i gallret vilket innebär att poolen fria luckor är mindre spridd och därför finns det en högre möjlighet att luckreallokering lyckas.

Accessfördröjningen för en multi-hoppkanal kommer att vara längre än på ett enkelhopp, emedan luckor mäste allokeras på 10 15 20 .Lås 515 901 18 två bussar. För 256 kbyte-överföringar är accessfördröjningen grovt sett 50% längre i multi-hoppfallet jämfört med det enkla hoppfallet. Man skulle kunna förvänta att accessfördröjningen i gallret var längre än detta. Det finns två huvudskäl varför detta inte är fallet. För det första finns det en viss mängd parallellism i kanaletableringen över tvâ hopp. För det andra är intervallen mellan styrluckor kortare i gallret så att en nod tillbringar mindre tid med att vänta på styrluckor. För 16 kbyte överföringar ökar emellertid fördröjningen dramatiskt för högre belastningen vilket indikerar att signalkapaciteten är otillräcklig. 4 Konklusion och framtida arbete Det dynamiska synkrona överföringssättet (DTM) är en nät- uppbyggnad för integrerade tjänster. Den är baserad på snabb kretskoppling och tillhandahåller multihastighet, fleradress- kanaler med kort upprättandetid. En kanal ger garanterad kapacitet och konstant fördröjning vilket gör den väl lämpad för realtidstrafik, såsom video och audio. I motsats till traditionella kretskopplade nät, tillhandahåller DTM även dynamisk reallokering av resurser mellan noder för att understödja dynamiskt varierande trafik.

Vi har rapporterat prestandaanalys genom datorsimuleringar för olika konfigurationer. Analysen är fokuserad pà paketliknande trafikmönster emedan denna typ av trafik anses vara den mest utmanande för ett nät baserat pä kretskoppling. Intentionen är att studera hur nätutnyttjande och accessfördröjning påverkas när kanaler frekvent etableras och frigöres. Vi använder 20 10 15 20 1.225 515 9Û'i 19 Mbit/s-kanaler där en kanal är etablerad för varje överföring och överföringsstorleken varierar mellan. 1 och 256 kbytes.

Analysen utfördes för två typer av topologier: en dubbelbuss och ett galler av dubbelbussar. Protokollet kräver att en viss bråkdel av den totala kapaciteten reserveras för styrinforma- tion: vi använder omkring 5% för dubbelbussen och 2% för gallret.

Resultatet visar att när trafiken består av korta, frekventa överföringar (av några kbytes) bestäms prestandan av mängden tillgänglig signalkapacitet. För dubbelbussen uppnås goda resultat även när nätet är belastat med överföringar som bara är några få kilobytes långa under det att gallret mättades vid 16 kbytes överföringar. Sammanfattningsvis visar dokumentet att snabb kretskoppling, såsom tillämpad i DTM, fungerar bra även för pakettrafik utnyttjande kortlivade förbindningar.

Detta i kombination med dess inbyggda stöd för realtidstrafik gör snabb kretskoppling ett tilltalande alternativ för B-ISDN.

För framtida arbete antyder prestandaresultaten att för att sända paket på DTM behöver man hitta en plan för multiple- xeringspaket över till kanaler som grupperar samman paket till något större enheter. Under antagande att datorer genererar trafik som överensstämmer med tågmodellen (skurar av paket där många av paketen inom en skur har samma destination) synes en enkel plan liknande de som används i tidiga snabba kretskop- plade nät korrekta. I en sådan plan år kanalen stängd och dess resurser frigivna när sändaren har varit passiv under mer än en viss period. Detta år emellertid ett område som behöver 10 15 ~'É'2o '::É25 515 901 20 undersökas ytterligare. Prestandaresultaten är uppmuntrande och vi kommer att ytterligare undersöka effekterna av icke likformiga trafikmodeller, såsom skurkällor och asymmetriska sändare-mottagardistributioner_ Dessutom \üJJ. vi förverkliga och investera mekanismer såsom snabb kanalskapande och luckåteranvändning i simulatorn.

B. Prestandaanalys av tidluckeadministrering i DTM-nät 1 Sammanfattning Detta dokument presenterar prestationsresultat och analyser med avseende på ett linjärt DTM-nät, ett nytt höghastighetsnät baserat på snabb kretskoppling. Prestationsanalysen hänför sig till utnyttjande, fördröjning och. blockering. De flesta av resultaten är riktade mot paketförmedling som anses vara den svåraste tjänsten att tillhandahålla i ett nät baserat på kretskoppling.

Resursstyrning använder tokens för att garantera konfliktfri access till tidluckor. Modellen inkluderar och simulerar två olika tokenstyrningsplaner. Den första är en asymmetrisk plan baserad på en central tokenstyrning som hanterar alla fria tokens. Den andra är en symmetrisk plan baserad pà en token- styrning där alla noder delar tokenpoolen. Tokens i den dis- tribuerade planen förflyttas genom ett omfördelningsprotokoll.

Ett tokenfragmenteringsproblem identifieras för den distribue- rade planen och en lösning baserad på en defragmenteringsmeka- nism presenteras. Båda modellerna stöder tidluckeåteran- vändning och en plan för att upprätta snabb förbindelse. 10 15 20 515 9 01 21 Trafikgeneratorer för simuleringen genererar trafik antingen med exponentiella distributioner eller antagande skur- eller asymmetrisk client-servertrafik. Resultaten visar att förbin- delseupprättandetsf overhead är tillräckligt låg för att utnyttjandet kan vara högt och att cmåördelningsprotokollet arbetar bra även om en krets etableras för varje individuellt paket. När tidluckeàteranvändningsplanen kopplas på ökar utnyttjandet med nästan en faktor av tvâ och andra prestationsmetriks förbättras likaså. Slutligen identifierar resultaten signalering som den viktigaste parametern om genomsnittspaketets storlek är liten. 1. Introduktion Nya högkapacitiva kommunikationsnät och protokoll utvecklas ständigt av kommunikationsindustrhn och inom den akademiska världen. Denna utveckling är dynamisk och nya resultat är viktiga för tillämpningsutvecklare som integrerar realtidsaudio, video, och asynkrona kommunikationstjänster i olika tillämpningar. Tillämpningarna kan återfinnas på ett brett område av nätaccessterminaler. Terminalerna fungerar som nätvärdar och kan vara nästan varje typ av elektronisk anordning, inkluderande sma ficktelefoner eller multimedia arbetsstationer och televisionsapparater, superdatorer i miljondollarklassen. Dessa värdar skiljer sig i storleksordningar vad avser deras behov av processeffekt och deras krav på kommunikationstjänster. Dessa olika behov återspeglas för närvarande i en uppsättning oberoende nät- klasser. Varje nätklass optimeras för dess särskilda trafik 10 15 20 Äšïïzs 515 901 22 och tillämpningar: kabeltevenät använder enkelriktade sändningsnät där kapaciteten är uppdelad i storleksmässigt fixerade subkanaler som uppbär video. Ett telefonnät använder bara 64 kbit/s duplexkretsar med garanterad genomströmning och effektivt styrda fördröjningsvariationer. såsom Datornät, Internet, medger stort antal parallella nätstationer genom att utnyttja förbindelselös paketomfördelning. De använder också statistisk multiplexering för att effektivt utnyttja länkar.

Ett grundnät för mobila system behöver extra styrnings kapacitet (eller signaleringskapacitet) för att dynamiskt spåra alla aktiva terminaler.

Med detta breda spektrum av tillämpningar som idag finns och som skall utvidgas i framtiden, är det omöjligt att konti- nuerligt uppfinna nya, ibland globala, nät och ett nytt termi- nalgränssnitt för varje ny typ av tjänst. I stället behöver ett integrerat tjänstenät som stödjer alla "gamla" och nya tjänster att utvecklas. De överskuggande målen för ett sådant nät är uppgradering till global storlek och maximal delning av kostnaden. dyra nätkomponenter för att minimera Optisk transmissionsteknologi har visat sig tillhandahålla den nödvändiga länkkapaciteten till ett tillräckligt lågt pris för att göra integrerade tjänstenät till en realistisk lösning.

Ett nytt integrerat optiskt nät med. mycket högre kapacitet kommer emellertid att föra in nya problem som inte finns i da- gens mera specialiserade nät med lägre prestanda. Först, när nätkapaciteten ökar och informationöverföringen blir begränsad av ljusets hastighet kommer den ökande bandbreddförse- 10 15 20 15:25 515 901 23 ningsprodukten att ställa högre krav på mekanismer som isolerar en användares trafik från en tredje parts nättrafik.

Så exempelvis borde inte ett telefonsammanträde påverkas av en annan användare som öppnar en högkapacitets videokanal. För det andra, tillämpningar och protokoll kommer att behöva fungera tillförlitligt med en ökande mängd information i transit för att dra nytta av den ökade nätkapaciteten. Detta kommer att leda till större skur- och transaktionsstorlekar i nätet.

Nuvarande nät som använder statuslösa paketomfördelnings- protokoll, såsom Internet-protokollet (IP) har visat sig vara i hög grad skalbara. De har utvecklats från små nätverk som förbinder endast ett fåtal Defense Advanced Research Projects Agency (DARPA) forskningsdatorer på sena sjuttiotalet till för närvarande globala och allmänt förekommande Internet. Delade mediumlokalomràdesnät (LAN's) såsom CSMA/CD, tokenring och FDDI används i Internet som enkla byggblock förbundna medelst vägval eller bryggor. Kombinationen av lätt expansion, låg inkrementell nodkostnad och tolerans mot felaktiga noder har resulterat i enkla flexibla och robusta nät. Det delade mediet medger också effektiv tillämpning av nya fleradressändnings~ protokoll, såsom IP-fleradressändning En nackdel med det delade mediet är att det typiskt medger att endast en terminal sänder vid vilken tidpunkt som helst, ej effektivt utnyttjande alla nätsegment. En plan som medger att mediets kapacitet àtervändes kan konstrueras, men detta sker ofta på bekostnad av komplexiteten i hårdvarans höghastighets- 10 15 20 515 901 24 accessstyrning. Accessstyrningsmekanismer för ett delat medium beror i hög grad på nätets storlek och är vanligen effektiva endast för lokala omràdesmiljöer.

De två huvudtyperna av -nät är anslutningsorienterade kretskopplade nät använda för telefonin och förbindelselöst paketförmedlade nät exemplifierade av Internet. När ett kretskopplat nät används för datakommunikation behöver kretsarna förbli öppna mellan informationsskurarna vilket slösar bort nätkapacitet. Detta problem uppstår emedan krets- styrningsoperationerna är långsamma jämfört med dynamiska variationer i användarbehovet. En annan källa för overhead i kretskopplade nät är begränsningen av kravet på symmetriska duplexkanaler, som introducerar 100% overhead när informationsflödet är enkelriktat. Denna ofrihet gör också att fleradressändningskretsar blir svåra att realisera samt ineffektiva. Ett förbindelselöst paketförmedlat nät saknar å resursreservation och andra sidan måste lägga till startpaketsinformation till varje meddelande före överföring.

Bundenhet vid ett förbindelselöst paketförmedlat nät kan vidare ej på ett noggrant sätt förutses och paketen kan även gå förlorade pá grund av förvanskade överspill eller startpaket. De senare två faktorerna gör det svårt att stödja realtidstjänster. Stockningsundvikande mekanismer kan isolera trafikströmmar för olika användare. Dessa strukturer är begränsade att fungera på en tidsskala som är jämförbar med rundtrippaketfördröjning_ lO 15 20 515 9G? 25 För att adressera ovan nämnda problem fokuserar sig kommunikationsindustrin på utvecklingen av asynkront överfö- ringssätt (ATM).

ATM har föreslagits för LAN's och många framtida allmänna nät. International Telegraph and Telephone Con-sultative Committee (CCITT) har också antagit detta för att användas som överföringsstandard vid bredband-ISDN (B- ISDN). ATM-nät är anslutningsorienterade och upprättar en kanal just såsom kretskopplade nät men använder små stor- leksfixerade paket benämnda celler för informationsöverföring.

ATM's paketförmedlade natur innebär att nätet behöver ha nya mekanismer, såson1 bufferresursstyrare och länkfördelare för att upprätta realtidsgarantier för den virtuella banan/kretsen.

Vår lösning för att tillhandahålla realtidsgarantier kon- centreras på ett därför kretskopplat nät och vi måste adressera kretskopplingsövervägande såsom ovan beskrivits. Vi utnyttjar också ett nytt delat medium-styrningsprotokoll och måste således överväga gemensamma delade nædiumproblem. Vår konstruktion, benämnd dynamiskt synkront överföringssätt (DTM), använder kanaler såsom kommunikationsabstraktion. Våra kanaler skiljer sig fràn telefonikretsar på olika sätt. För det första är upprättandefördröjningen kort så att resurser kan allokeras/deallokeras dynamiskt så snabbt som nu För det och användarkraven ändras. andra är de simplexa minimerar därför overhead när kommunikationen är enkelriktad.

För det tredje erbjuder' de multipla. bithastigheter för att stödja stora variationer med avseende på kapacitetskraven. lO 15 20 fås 515 901 26 Slutligen är de fleradressändare som medger varje antal destinationer.

DTM-kanaler delar många goda egenskaper med kretsar. Det finns ingen överföring Aav styrningsinformation efter kanalupp- rättande vilket resulterar i mycket högt utnyttjande av nätre- surser för stora dataöverföringar. Stöd för realtidstrafik är naturlig; det finns inget behov för övervakning, stocknings- kontroll eller flödeskontroll inom nätet¿ Kontrollin- formationen är separerad från data som gör fleradressändning mindre komplex. Transmissionsfördröjningen är negligérbar (dvs. mindre än 125 ps) och det finns ingen risk för dataförlust på grund av bufferspill såsom i ATM.

Bitfelhastigheter beror på de underliggande länkteknologierna och omkopplarna är enkla och snabba beroende på strikt reservation av resurser vid kanalupprättande. Målet med detta dokument är att studera. prestandan för DTM i områden där traditionella kretskopplade nät inte räcker till: dynamisk bandbreddallokering, kanalupprättandefördröjning, och som delade medianät. Principer för resursstyrning (benämnd tokenadministrering) presenteras och. utvärderas. Vi rappor- terar resultat från simuleringar där vi utsätter DTM för trafikmönster som mera liknar de relativt kortlivade överfö- sett 5. datakommunikationstrafik ned ringarna (4-4000 kbyte) skurformad, client-server likaväl som expontentiellt dis- tribuerade ankomster.

Sektion 2 beskriver DTM-protokollet och dess kanalkoncept. I sektion 3 beskrivs tokenprotokollet. Sektion 4 följer upp med 515 901 27 en diskussion av simuleringsuppsättningen och sektionerna 5.2 och 5.3 presenterar simuleringsresultaten för olika konfigurationer. Slutligen dras slutsatser i sektion 6. 10 15 çzo :tis 28 2. DTM MAC-protokoll Bastopologin i ett DTM-nät (se fig. 9) är en buss med två enkelriktade optiska fibrer som förbinder alla noder. Flera bussar med olika hastigheter kan förbindas för att bilda ett godtyckligt flerstegsnät. I den aktuella prototypen kan bussar kombineras till ett tvàdimensionellt nät . En nod vid korsningen för två bussar kan synkront kopplad om datatid- luckor mellan de två bussarna. Detta medger effektiv omkoppling med konstant fördröjning genom noden. Ett DTM-nät använder fleradressändningskanaler som den primära kommunikationsabstraktionen.

DTM-mediumaccessprotokollet är ett tidsdelat multiplexerat schema. Bussens bandbredd är uppdelad i l25ps cykler (fig. 10) som i sin tur är uppdelade i 64 bitars tidluckor (eller luckor som en förkortning). Antalet luckor i en cykel beror således på nätets bithastighet; så exempelvis finns det på ett 6,4 Gbit/s-nät ungefär 12.500 luckor per cykel.

Luckorna är 'uppdelade i tvâ grupper, styrluckor och data- luckor. Styrluckorna används för att bära meddelanden för nä- tets interna operation, såsom meddelanden för kanalupprättande och reallokering av bandbredd. Dataluckorna används för att överföra användardata och tolkas inte av mellannätnoder. Mel- lannoder är noder mellan källan och destinationen.

I varje nätnod finns en nodstyrenhet som styr accessen till dataluckor och utför nätadministrationsfunktioner, såsom uppstart av nätet och felàterställande. 10 15 515 901 29 Huvuduppgifterna för nodstyrenheten är att skapa och avsluta kanaler på begäran från användare och för att administrera nätresurser som svar på användarbegäran och i bakgrunden.

Styrluckorna används exklusivt för meddelanden mellan nodstyrenheterna. Varje nodstyrenhet har skrivtillàtelse till åtminstone en styrlucka i varje cykel som den använder för att sända styrmeddelanden nedströms till andra noder. Emedan skrivaccess till styrluckan är exklusiv' har _nodstyrenheten alltid access till dess styrluckor oberoende av andra noder och nätbelastning. Antalet styrluckor som en nod använder kan variera under nätfunktionen. 3. Tokenadministrering Majoriteten luckor i en cykel är dataluckor. Access till data- luckor ändras över tiden i med trafikkraven. enlighet Skrivaccess till luckor styrs av lucktokens (eller som en för- kortning, tokens). En nodstyrenhet kan skriva in data i en lucka endast om den äger motsvarande token. Tokenprotokollet garanterar att luckaccessen är konfliktfri, vilket innebär att flera noder inte skriver data i samma lucka.

Styrmeddelanden för bandbredden kanalupprättande och reallokering av har uppsättning av luckor eller tokens som parametrar. Men ett styrmeddelande är 64 bitar och kan därför ha endast ett litet antal parametrar. Detta innebär att om en användare begär en stor bandbreddsöverföring kan det vara nödvändigt att sända flera styrmeddelanden för att skapa lO 15 :'ÉïšC 515 901 30 kanalen. Detta medför extra accessfördröjning och förbrukar signalkapacitet.

Vi överväger' ett flertal mekanismer för att minska rnängden information som behöver sändas under kanalupprättande och tokenreallokering. Den första optimeringen med avseende på tokenadministration är att införa blocktokens. En blocktoken överföres i ett enda styrmeddelande och representerar en grupp av tokens men kan bara användas för särskilda kombinationer av tokens. Så exempelvis anges i simulatorn en blocktoken med ett lucknummer och en förskjutning som ger antalet intilliggande luckor i gruppen. Blocktokens optimering förutsätter att tokenpoolen inte fragmenteras i små stycken. Detta kommer att betecknas som fragmentering av tokenpoolen. 3.1 Luckåteranvändning Tokenprotokollet garanterar att en datalucka aldrig kan an- vändas samtidigt av två noder pà bussen. Ibland är detta protokoll alltför konservativt. Fig. ll visar ett exempel på hur tre symboler (A, B och C) är reserverade för tre kanaler.

Noder' är förbundna genom bussegment och kanalerna använder typiskt en delmängd av segmenten. på bussen och (grå färg) resterande är reserverade (vit färg) men lämnade oanvända och slösar således med delade resurser. Ett bättre alternativ är att låta kanaler endast reservera kapacitet på segmenten mellan sändaren och mottagaren, såsom i exemplet i fig. 12. En enda lucka kan. i detta fall användas åtskilliga gånger på bussen. Kanalerna D och E använder samma luckor som kanalen A 10 15 515 901 31 och C men på olika segment. Detta betecknas som luckàteran- vändning. Luckåteranvändning möjliggör samtidig överföring i samma lucka över ej förbundna segment i bussen.

Luckàteranvändning är en allmän metod för att bättre utnyttja delade länkar i ring- och bussnät.

Luckåteranvänd- ningsalgoritmerna i DQDB, simple och CRMA beror på styrinformation i luckorna. Buffertinföringsnät i kombination med destinationsfrigöring som i METARING kan återanvända kapacitet hos individuella länkar och löser eventuell överbeläggning genom att fördröja den inkommande paketströmmen genom en elastisk buffert.

Med luckåteranvändning ökar accessschemats komplexitet oavsett om det är gjort i hårdvara såsom i DQDB, simple, och CRMA; eller i mjukvara, såsom i DTM. När luckåteranvändning genomföres i system andra än DTM, bygger den också upp komplex hårdvara till den kritiska höghastighetsbanan genom en nod och därför ökar nodfördröjningen.

För att medge luckåteranvändning i DTM är blocktokens format utökat att innefatta parametrar som beskriver det eller de segment som den representerar. Tokenadministrationsprotokollet är också modifierat för att undvika konflikter med avseende på lucknummerledd samt också segmentledd. Det viktigaste antagandet är att ingen hårdvara ändrar till den ursprungliga prototyprealiseringen, där så behövs. medges eller Prestandavinsten är således helt klar: på en dubbelbuss, där käll- och destinationspar är jämnt fördelade, har det visat sig att genomströmningen kan ökas med en faktor av två. Den 1% lO 15 20 515 9 01 32 möjliga nackdelen med luckåteranvändning i ett DTM-nät är dock den högre algoritmkomplexiteten och eventuellt högre be- lastning pà nodstyrenheten och signalkanalerna (särskilt om medelvärdet för kanalvaraktighet är kort). 3.2 En central tokenadministrering Två tokenadministreringsscheman. utvärderades och. det första och enklaste är att«låta en enda nodstyrenhet administrera alla fria (lediga) tokens för en fiber. Denna typ av centrali- serad servermekanism har också använts i system, sådana som CRMA, där huvudändnoden distribuerar fiberkapaciteten till alla andra noder. Vi utvecklade simulatorn så att för varje fiber är en nod på en tredjedel av avståndet från luck- generatorn tokenserver (med 100 noder på en buss kommer noden 33 och 77 att vara tokenserver). Detta motsvarar mittpunkten för kravet för vardera av de två enkelriktade fibrerna så att en tokenserver kommer att ha samma mängd trafik på båda sidorna.

Varje gång en användarbegäran anländer till en nod så begär noden först tokens från servern och reserverar dem sedan för kanalens livstid. När användaren utfärdar en begäran att frånkoppla kanalen återgår tokens omedelbart till administre- ring. Alla önskemål fördröjs under tokensbegäran och accesser serialiseras genom den centrala administreringen. 3.3 En distribuerad tokenadministrering Den distribuerade tokenadministreringen är fundamentalt mer komplicerad än den centraliserade. Vi försökte hålla det så 33 enkelt som möjligt. I vårt förfarande sänder varje nod regel- bundet statusinformation om hur många fria tokens den har. De andra noderna lagrar denna information i sina statustabeller.

En nod som vill ha mer kapacitet konsulterar dess statustabell 5 för att avgöra från 'vilken nod luckor skall begäras.

Protokollet på den initierande sidan arbetar som följer. När en användarbegäran anländer till en nod: l. Om noden har tillräckligt många fria tokens för att till- fredställa begäran allokerar den begärda mängden luckor till 10 användaren och startar kanalen genom att sända ett kanalupprättandemeddelande till destinationsnoden och sedan sända data med utnyttjande av de reserverade luckorna. 2. I annat fall markerar noden dess tillgängliga tokens såsom varande reserverade och kontrollerar sedan dess statustabell: 15 om den totala mängden fria tokens i nätet inte är tillräckliga för att uppfylla begäran så avslås begäran (blockeras). I annat fall begär noden tokens från noder med oanvänd kapaci- tet.

Om en av dessa noder som mottar en tokenbegäran inte har den 20 begärda mängden fria luckor så ger den fortfarande bort alla G luckor som den har. I varje fall sänder den ett svar tillbaka till den begärande noden. En nod uppfyller inkommande önskemål --..~ i strikt FIFO (First In First Out)-ordning. :ff När en nod mottar ett svar på en tokenbegäran så markerar den -ÅÉS luckan som den mottar i svaret (om sådant finns) såsom varande "~f reserverad. När noden har mottagit svar på alla önskemål som 10 15 20 ..l§¿'5 515 901 34 den har sänt startar den kanalerna eller avslår användarbegäran beroende på om den har eller inte har erhållit tillräcklig kapacitet. Om användarbegäran avslås så markeras de reserverade luckorna som varande återigen fria.

Vid uppstart distribueras alla fria tokens likformigt bland nätnoderna och varje nod tar åtminstone en av dess fria luckor, flyttar den (de) till det aktiva tillståndet och förklarar att den (de) är en styrlucka. Användarönskemål kan nu accepteras och tokens kan flyttas mellan noder på begäran.

En svaghet med denna plan är att reallokering av luckor bara triggas vid användarbegäran och användarbegäran fördröjs genom tokens som håller på att reallokeras. En optimering som vi har realiserat för att kompensera detta är att också utföra luckreallokering i bakgrunden. Detta resulterar i mindre behov för reallokering av tokens för små till mellanstora förfråg- ningar.

Poolen av fria tokens kan distribueras på andra sätt än lik- formigt för att öka hastigheten för lyckad reallokering och utnyttjande. Om färre noder administrerar poolen minskar kanalblockeringen som ett resultat av mindre möjlighet för att tokens skall reallokeras fel.

Den kompletta tokenpoolen är i detta fall proportionellt distribuerad (noder nära luckgeneratorn får flera tokens än noder långt bort från denna) bland alla noder. Tokenöverför- ingar kan inträffa mellan varje par noder i stället för att alltid blanda in servernoden. När den lokala noden innehåller 10 l5 E20 35 tillräckligt många tokens för att uppfylla en anländande an- vändarbegäran kan begäran accepteras utan någon tokenrealloke- ring. Vidare, så länge som de anländande användarönskemålen väl matchas med pooldistributionen så kommer ingen reallokering någonsin att vara nödvändig.

Flera frågor behöver besvaras innan man bestämmer sig för hur man skall distribuera tokenpoolen. Vi adresserar följande frågor: ' 1. När lokala resurser i noden inte är tillräckliga för att uppfylla en användarbegäran, vilken annan nod skall man be om mera tokens? 2. Om en nod begär tokens från flera noder hur många tokens skall den begära och skall noden avslå kanalen om den endast mottager en delmängd av den begärda kapaciteten? 3. Om tokens rör sig fritt bland noderna kommer tokenpoolen att fragmenteras i små stycken och göra blocktokenoptimerings- schemat oanvändbart? 3.3.1 Statusmeddelanden Vi beslöt att använda statusmeddelanden för att distribuera information om poolen för fria tokens. Statusmeddelandein- formation används för att hjälpa en nod att välja en lämplig nod när den begär mera resurser. Denna metod adresserar den första frågan här ovan. 10 l5 ÜÉÉIO ÜFB 515 901 36 Vàr plan arbetar sàsom följer. Varje nod sänder regelbundet statusinformation om hur många fria tokens som den har. De andra noderna lagrar denna information i sina statustabeller.

En nod som vill ha mera kapacitet konsulterar dess statustabell för att avgöra från vilken nod den skall begära luckor. Den sända tillstàndsinformationen ger en approximerad och daterad uppfattning om nuläget för tokeninformation så att tokenönskemål kan avslås emedan de sändes till noder som inte längre hade nâgra tokens att ge bort.

Statustabeller är “mjuk” information så tillvida att systemet kommer att fungera även om de inte är tillgängliga eller föràldrade. De bör emellertid förbättra hastigheten för lyckade reallokeringsprocedurer. 3.3.2 Att undvika onödiga avslag När man jämför basprestanda hos den centraliserade (fig. 17) och den distribuerade (fig. 20) tokenadministreringen sä ser vi att det finns en ny typ av avslag av användarbegäran som är frekventa i_ den distribuerade versionen när det i systemet fortfarande finns outnyttjade resurser.

En nod använder statustabellen för att välja nod(er) varifrån tokens begäres. När begäran når málnoden kan mängden tillgänglig kapacitet ha ändrats och en mindre mängd än den som begärdes kan skickas tillbaka till den begärande noden vilket resulterar i ett användaravslag.

Det här sättet att reagera resulterar i t.o.m. flera onödiga tokenrörelser och ökar därför också möjligheten att andra lO 15 20 515 901 37 noder får färre tokens än de som begärts. Tokens som förflyt- tas i detta fall är också reserverade (lästa) och oanvända under överföringen.

Om poolen distribueras proportionellt bland ett stort antal (100-tals) noder så kommer genomsnittspoolens storlek att vara relativt liten. När belastningen är hög sä kommer antalet fria tokens i poolerna att minska även ytterligare. Om noder även skapar och förstör kenaler vid en. mycket hög' hastighet så kommer mängden fri kapacitet i individuella noder att variera mellan Om nu den en liten mängd kapacitet inte någon alls. genomsnittskapacitet som begärs av en användare är stor i jämförelse med antalet fria tokens hos en nod så mäste flera noder tillfrågas för att uppfylla begäran. Vid denna punkt så kommer möjligheterna att en av de begärda noderna inte har någon fri kapacitet att leda till ett användaravslag.

Det finns flera sätt att adressera detta problem utan att gä tillbaka mot en centraliserad modell. För det första behöver vi inte ge bort nägra luckor alls om den fullständiga begäran inte kan uppfyllas. Detta protokoll tillämpas även om bara en enda nod tillfrågas om fria tokens men om flera noder tillfrå- gas kan det fortfarande resultera i att tokens förflyttas eller låses oanvända. För det andra om vi efter en tokenbe- gäran mottager färre tokens än det antal som vi har begärt sà kan vi helt enkelt på nytt och flera gånger försöka begära proceduren för tokenbegäran. Detta kommer att öka möjligheten att en användarbegäran accepteras och att de mottagna tokens kommer att användas. Kostnaden för den förnyade prövningen 10 15 20 5125 9 01 38 kommer att blir ökad signalering och ökad accessfördröjning och kan försämra. prestandan. på ett överbelastat nät. Även försök medför användarens förnyade längre uppkopplinge- fördröjningar för; begäran som har underställts förnyad prövning. För det tredje kan användaren ibland önska acceptera en kanal med mindre än den begärda kapaciteten i stället för att avslås. Om exempelvis en användare mottager 50% av vad som begärts så kan han vilja acceptera. I fig. 13 visas prestandan för små (16 kbyte) användarbegäran med olika minsta acceptabla kapaciteter [lOO% (40 luckor), 50% (20 luckor), och 5% (1 lucka)]. En undre genomsnittlig, lägsta acceptabla bandbredd kommer att resultera i högre utnyttjande. I fig. 14 visar vi prestanda som blir resultatet om användaren (som begär en 16 kbyte dataöverföring) gör förnyade försök upp till 8 gånger innan vi slutgiltigt blockerar begäran. Utnyttjandet ökar (och blockeringen ökar) på bekostnad av mer signalering och längre fördröjning. Förnyad prövning ett stort antal gånger motverkar produktiviteten om det sker ofta.

Helt klart ligger vinsten av en flexibel användarbegäranpolicy i lägre sannolikhet för avslag och högre total genomströmning.

Endera av de konfigurationer som visas i fig. 13 och fig. 14 kan beslutas vid tidpunkten då en begäran ankommer. En användare som har strikta krav på kapaciteten för en kanal kan begära förnyad prövning till dess att tillräcklig kapacitet är allokerad men en annan kan hellre acceptera en kanal med mindre än den begärda mängden. För de resterande av simuleringarna som här presenteras definierar vi lägsta acceptabla bandbredd att vara 50% av den begärda kapaciteten. 10 15 20 :gzs 515 901 39 3.3.3 Fragmentering I det allmänna fallet är det genomsnittliga antalet angränsande fria block i en nod litet beroende på av tokens rör sig slumpvis och av den varierande kapaciteten hos an- vändarnas begäran. Denna fragmentering gör blocktokenoptime- ringen praktiskt taget oanvändbar och accessfördröjningen är relativt lång (millisekunder) för högkapacitetskanaler. För att göra blockallokering effektiv är det nödvändigt att reducera fragmenteringen hos fria tokens i annat fall kommer fragmenteringen att i hög grad vara huvudorsaken till access- fördröjning för kanaler med hög bandbredd vid moderat till hög belastning. Lågkapacitetkanaler kommer nästan alltid att ha en mycket kort kanalupprättandefördröjning oberoende av den aktuella storleken av fragmenteringen. I fallet luckàteran- vändning är fragmenteringsproblemet t.o.m. värre emedan fragmentering kan inträffa i såväl luck- (tid) som segment- (avstànd)ledd (se fig. 12). I den centraliserade serverversionen är detta en särskild tillämpning av det allmänna dynamiska lagringsallokeringsproblemet. I den distribuerade tokenadministreringen är den mesta delen av fragmenteringen ett resultat av att man använder många fria pooler (en för varje nod). Två fria närliggande tokens kan bara gå samman om de återfinns i samma nod.

Vi har realiserat ett distribuerat schema som försöker undvika fragmentering om möjligt och ökar den genomsnittliga blockstorleken hos fria tokens i noderna. Schemat används både med och utan luckàteranvändning. 10 15 :'30 :liiàs 40 Vårt schema fungerar såsom följer: 1. Definiera en hemmanod (servernod) för varje token vid nätets uppstart och distribuera tokens på så sätt så att tokens som delar samma hemmanod alltid kommer att definiera ett kontinuerligt luckområde. Detta resulterar i ett stort genomsnittligt tokenområde i tokenkartan som visas i fig. 12. 2. När två luckkonsekutiva tokens med sammad luck- eller segmentområde finns i den fria poolen sammanför dem i en enda token (ibland behövs en rekursiv split och sammanslagningso- peration). När man gör en sammanslagning så prioritera alltid segmentsammanslagning före en lucksammanslagning.

Skälet för detta är att tokens som spänner endast över några få segment är mindre användbara för andra noder än tokens som spänner över många segment. 3. När en nod får en tokenbegäran från den lokala användaren eller en avlägsen användare så plocka upp en token från token- poolen utnyttjande den bäst passande algoritmen i luckantal- och segmentledd (se fig. 12). Värdet av en token be-räknas som arean av en token i tokenkartan och vi försöker plocka upp token med den minsta arean som uppfyller den begärda kapaciteten. 4. När en nod behöver begära tokens från andra noder så frågar den inte efter små stycken från flera noder om det är möjligt större noder. att efterfråga stycken från färre Statustabellerna tillhandahåller denna information. Överföring 10 15 20 .Läs 515 901 41 av tokens är därför mera effektiv och det finns färre etableringsmeddelanden och mindre fragmentering. 5. Fria tokens skickas tillbaka till hemmanoder om de har varit overksamma under en lång tid eller efter en läng över- föring.

Denna plan skickar tillbaka tokens till hemnoder som ett sätt att öka möjligheten att två konsekutiva tokens kan slås samman i den fria listan som minskar fragmentering. Om hemmanodens "gravitet" är alltför stark så kommer planen att resultera i mindre delning av resurser och onödig signalering. Om den är alltför svag så kommer fragmentering fortfarande att vara ett problem.

För att utvärdera defragmenteringsmekanismen så gjorde vi en annan uppsättning simuleringar. Vi konstruerade tre olika simulatorer [A,B,C]. Simulatorn A konfigurerades att inte ha någon fragmentering vid simuleringsstarttiden och att använda defragmenteringsplanen som beskrivs här ovan. B startade med maximal fragmentering av den totala resurspoolen. Alla tokens hade en enda lucka och inga tokens i hemnoderna innan defrag~ menteringsmekanismen kopplades in. Slutligen startades simula- tor C utan att använda defragmenteringsmekanismen och med den pool som har maximal fragmentering. I samtliga fall slogs luckàteranvändning på och belastningen definierades att vara 80%.

Accessfördröjning som en funktion av simulerad tid visas i fig. 15 för ett 10 km nät. Simulatorn C startade med en lång 10 15 20 515 901 42 accessfördröjning och fördröjningen ökade när signalkanalerna blev överbelastade och meddelandeköerna växte. Simulatorn B utnyttjande defragmenteringsmekanismen startar precis lika dåligt som C men redan efter 10 millisekunder ligger genomsnittlig accessfördröjning under 500 mikrosekunder.

Senare, när en sekund av simulerad tid hade gått så förbinds B-kurvan i de allra närmaste med A, dvs. den konvergerar om simulatorns prestanda startar utan någon som helst fragmentering. Konvergenshastigheten beror av mängden fri kapacitet i nätet och således även på belastningen.

Belastningen under alla dessa simuleringar var 80%.

Defragmenteringsmekanismen förbättrar klart access- fördröjningen och gör även blocktokenoptimeringen meningsfull i den distribuerade realiseringen. 3.4 DTM-prestanda Vi är huvudsakligen intresserade av två typer av prestanda- mätningar i detta dokument: utnyttjande och accessfördröjning.

Utnyttjande är den del av det nominella nätets kapacitet som verkligen använder dataöverföring och är ett värde på nätets effektivitet. Accessfördröjning' är den tid från det en an- vändarbegäran anländer till sändningen av första data för begäran, vilket vi tycker är ett viktigt mått för hur bra datorkommunikationtrafik kan understödjas.

Det finns två huvudfaktorer som påverkar utnyttjandet i DTM.

För det första är varje nod tilldelad signalkapacitet i form av styrluckor, vilket innebär att det finns färre luckor tillgängliga för dataöverföring på en buss med många noder, 10 15 ...20 .ïàs 'Accessfördröjning Vberor i 515 901 43 givna fixerad länkkapacitet. För det andra medför tokenreal- lokering overhead emedan då en lucktoken reallokeras mellan noder kan inte motsvarande lucka användas för dataöverföring. .huvudsak pà belastningen på styrluckorna och pà hur många styrmeddelanden som behöver sändas för att upprätta en kanal. Accessfördröjningen är typiskt en summering av några få fördröjningar. Fördröjning i databehandling i nodstyrenheten [5ps], fördröjning när det gäller att finna och allokera fria tokens [100ps], att vänta pa att den första tillgängliga styrluckan skall passera [50ps], och slutligen att vänta pà att den första allokerade dataluckan skall fyllas med användardata [62.5us]. Därtill försdröjs meddelanden i köer vid ingången till nodens styrenhet som väntar pà att databehandlas. I de simuleringar som presenteras i sektion 5.2 ligger den genomsnittliga fördröjningen upp mot några hundra mikrosekunder. 4 Nätsimuleringar I simuleringsmodellen startar varje överföring med att det anländer ett nytt paket av information. Nodstyrenheten försöker allokera resurser för överföringen, sänder data och frigör slutligen kanalen. Detta är en förenkling av mekanismerna i ett verkligt system där kanaluppsättning, dataöverföring och kanalnedrivning är oberoende operationer som initieras av användaren. Om exempelvis en användare, som vet att en överföring skall ske, kan "gömma" kanalupprättandefördröjningen genom att i förväg begära en 10 15 20 515 9Ü1 44 kanal så att den redan är upprättad när överföringen startar.

Mellan en uppsättning och nedrivning är kanalens kapacitet helt reserverad för användaren. Den vanligaste användningen av kanalen är för en enkel överföring, såsom en filöverföring eller en videotransmission.

Beroende på karaktäristika hos tillämpningen är det möjligt att optimera kanalens hantering. Sá exempelvis kan en kanal i användas för att överföra sekvenser av meddelanden av högre nivå, såsom ATM-celler eller IP-paket. Om kanalen är en fleradresskanal kan meddelanden till olika destinationer multiplexeras pà kanalen. Detta innebär att varje meddelande kommer att nä fram till varje mottagare på fleradresskanaler och mottagare måste kunna filtrera meddelanden. En alternativ lösning är att skapa och förstöra en kanal för varje meddelande men reservera tokens mellan meddelanden så att dessa tokens är lätt tillgängliga för nästa meddelande i sekvensen. Vi inkorporerar inte denna_typ.av användarsätt i simuleringarna emedan de är optimeringar för särskilda tillämpningar. I stället fokuserar vi på hur nätet utför operationen utan användarnivàoptimeringar.

Sändaren kan starta med att sända data så snart som resurserna allokerats även innan mottagaren mottager meddelande om kanalupprättande. Detta kallas för snabbkanalupprättande.

Mottagaren kommer eventuellt att svara med ett kontrollmedde- lande för att acceptera eller avslå kanalens upprättande.

Användarbegäran har följande parametrar: 10 15 52_o 21.25 515 901 45 0 Paketstorlek som är mängden av användardata som överföres mellan kanalupprättande och kanalfrigörande. Vi simulerar paketstorlekar från några få kbytes upptill några få Mbytes. 0 Begärd kapacitet för en kanal, som är antalet luckor som en nod försöker att allokera. För alla simuleringarna i detta dokument är den begärda kapaciteten fixerad till 40 luckor eller 20.48 Mbit/s. 1 0 Minsta acceptabla kapacitet. En nod blockerar en begäran om den inte kan allokera detta antal luckor. Denna är normalt bestämd till 40 eller 20 luckor (100% eller 50% av begärd kapacitet). 0 Källadress. 0 Destinationsadress.

Käll- och destinationsadresser genereras slumpvis (alla noder med samma möjlighet) och användarankomsttider är exponentiellt distribuerade.

Simuleringarna undersöker effekten av signalkapacitet och luckreallokeringsoverhead om utnyttjande, kanalupprättandefördröjning och blockering. Vi simulerar en topologi med följande karaktäristika. 0 Ett dubbelbussnät med 100 noder. Även om det är teoretiskt möjligt att förbinda många fler noder med en buss så tror vi att administrering av nät med fler än 100 noder på en buss kan vara orealistisk. Med. 100 noder är kapacitetsandelen signifikant nog för att utöva och testa token- administreringsprotokollet. lO 15 20 515 9 01 ï¿ïï= g; ~r.:_; 46 0 Kapaciteten hos varje buss är 6.4 Gbit/s. Vi tror att detta är realistiskt för vad som är realiserbart inom ett år eller två; 2.4 Gbit/s optiska länkar har varit tillgängliga under nâgra är och 10 Gbit/s-länkar har annonserats att de snart finns pà marknaden. 6.4 Gbit/s svarar mot 100 MHz- luckhastighet, som är den hastighet vid vilken den luckbearbetande MAC-hårdvaran skulle arbeta och denna hastighet kan uppnås med aktuell CMOS-teknologi.

Den totala signalkapaciteten är densamma för alla noder men luckorna är avskilda mellan de tvà fiberriktningarna som är proportionella i beroende av var noderna är orienterade på bussen. Ju närmare en nod ligger luckgeneratorn ju mer styrkapacitet behövs. Summan av styrkapacitet på båda bussarna kommer emellertid att vara densamma för alla noder.

I nätet med två tokenservrar har servrarna mer styrkapacitet och högre processkapacitet än de andra noderna.

Bussens längd är 10 km, som ger ett så tillräckligt stort nät att effekterna av överföringsfördröjning inte är negligérbara. Vi studerar vidare effekterna av överföringsfördröjning i simuleringarna i fig. 21 och fig. 19 som använder busslängder om 1 km, 10 km, 100 km och 1000 km.

Två olika tokenadministreringsplaner simuleras. En asymmet- risk plan där alla tokens på en fiber administreras av en enda tokenserver och en symmetrisk plan där varje nodsty- renhet administrerar ett stycke av den globala tokenpoolen. 10 15 _...._2o 515 901 47 5 Prestanda 5.1 Idealiskt protokoll När' man. analyserar' prestandan för* DTM-dubbelbussnätet måste frågan om maximal teoretisk prestanda adresseras och jämföras med den simulerade prestandan. De teoretiska maximala, prestandan används också i detta dokument för att jämföra de olika planerna och realiseringarna som vi utvärderar.

Den maximala genomströmningen i ett dubbelbussystem utan luckäteranvändning kan definieras som två gånger länkkapacite- ten förutsatt att bàda fibrerna mottar samma trafik. I ett system med luckàteranvändning beror också systemets genomströmning pà källdestinationsdistribution. För att uppnå denna genomströmning för dubbelbussen använder' vi en Monte Carlo-simulering där käll~ och destinationsadresser var jämnt distribuerade (se vänstra diagrammet i fig. 20). Jämför man detta med ett DTM~nät -(simuleringskonfigurering som senare definieras i sektion 4 utnyttjande en centraliserad tokensty- rare) där användaren begår stora överföringar (4 Mbyte vid 20 Mbit/s-kapacitet) och signalkapaciteten inte är en flaskhals (se högra diagrammet, fig. 16), är utnyttjandet nära idealfallet. Realtrafik som fungerar på detta sätt är bulkdataöverföringar och audio/videoströmmar. Skillnaderna som visas är resultatet av: en del kapacitet är i DTM använt för styrluckor som minskar det tillgängliga antalet luckor som skall användas vid. dataöverföringar. Slumpgeneratorerna för DTM-systemet genererar inte exakt samma mängd trafik i uppströms- och nedströmsriktning. Detta kan resultera i 10 15 515 901 48 blockering av en av riktningarna när kapaciteten är tillgänglig i den andra. Under upprättande av kanal kan resurser momentant làsas oanvända vilket förslösar viss kapacitet. 5.2 Centraliserad tokenadministrering I fallet centraliserad tokenadministrering behöver de tvà servernoderna mer signalkapacitet än andra noder (vi tilldelar servernoderna àtta gånger så många styrluckor som andra noder).

Resultatet av den första uppsättningen simuleringar visas i fig. 17. Användare begär 20 Mbit/s-kanaler, ankomster dis- tribueras exponentiellt (genereras av en Poisson-process) och simuleringarna utförs med olika paketstorlekar. Om kanalens hela kapacitet inte kan allokeras avslås begäran och tokens går tillbaka till tokenservern. Paketstorlekar varierar från 4 Mbyte till 4 kbyte vid vilken punkt vi börjar se degradering av genomströmningen.

Genomströmningsdegradering kan inträffa om processkapaciteten i noderna eller alltför styrkanalkapacitet är liten.

Servernoderna kan särskilt bli överbelastade. Resultatet är att köer innehållande styrmeddelanden börjar växa sig mycket stora. Styrtokens representerar outnyttjad kapacitet och därför degraderas genomströmningen.

I 4 kbyte-kanalsimuleringarna är styrkapaciteten den begränsande faktorn och om flera styrluckor (signalkapacitet) 10 15 20 515 901 49 tilläggs kan 4 kbyte och t.o.m. mindre paket understödjas mera effektivt.

Nästa uppsättning kurvor som visas i fig. 18 visar hur 'luckåteranvändningsmekanismen förbättrar systemets prestanda.

Genomströmningen ökar med nästan en faktor av två innan något signifikant antal kanalupprättanden avslås. käll- Kanalernas jämna och destinationsdistributioner begränsar mängden ökad kapacitet utvunnen genom luckåteranvändning. Det har visat sig att om källan och destinationerna genereras likformigt, såsom vi gör, kan genomströmningen dubblas på en dubbelbuss. I simuleringarna kan också ses att bortom en erbjuden last (offered load) av 2.5 vi kan i verkligheten få en genomströmning högre än 2.0. Denna genomströmningsnivå kan emellertid inte uppnås utan att några kanaler avslås. De kanaler som med största sannolikhet kommer att avslås är de som använder många luckor eller segment. Därför "filtrerar" systemet mindre användarbegäranden och kastar bort resterande.

Detta är normalt sätt ett icke acceptabelt sätt och vi undersöker därför inte detta något ytterligare.

Genomströmningsdegradering inträffar vid en erbjuden last av l med 4 kbyte överföringar. Även om vi har tillräckliga resurser i tokenservern kan vi inte upprätta och förstöra kanaler tillräckligt snabbt som styrkanalen blockeras. Av samma skäl ser vi. en genomströmningsdegradering .i 8 kbyte-simuleringar vid en ebjuden last av 1.8.

Genom simuleringarna i fig. 18 kan. man dra slutsatsen att luckàteranvändningsmekanismen nästan dubblar systemets genom- Ü 20 10 15 50 strömning med endast mindre ändringar av det centraliserade tokenprotokollet så länge som styrenhet- och serverprocesska- paciteten inte utgör en flaskhals. Från kurvorna kan man också oväntat se att accessfördröjning i verkligheten minskar när belastningen ökar från 0.1 till 0.5. Detta är ett resultat av hur luckor tilldelas en kanal och ej från en snabbare tokenbe- gäranprocedur. Den tid det tar för att begära tokens från servern ökar strikt.

Vid jämförelse mellan DTM-prestandan i fig. 18 och de teoretiska värdena i fig. 16 så ser vi att även korta skurar (med några millisekunders varaktighet) kan effektivt understödjas. 5.2.1 Prestanda hos den centraliserade tokenservern som en funktion av busslängden När en enda tokenserver används så kräver varje upprättande av kanal först att en token~begärs från servern innan noden kan upprätta kanalen. Om bussens längd ökas så kommer tokenbegäran att ta en längre tid och kan därför även begränsa genomström- ningen och öka accessfördröjningen.

I fig. 19 ökade vi bussens längd med en faktor av 100 till 1000 km (nod-till-nod-avståndet är nu 50 ps). Både accessfördröjning och genomströmning begränsas nu av rundtrippbundenheten till token servern.

Accessfördröjning i detta fall beror av avståndet till servrarna men. är' oberoende av' överföringsstorleken. Utnytt- lO l5 ÜÉQ5 515 9Û1 51 jandet beror absolut pà överföringsstorleken emedan upprättan- defasen kan amorteras över en lång dataöverföringsfas.

Kanaler som överför stora mängder information, såsom 256 kbyte med en “varaktighet av en tiondels sekund, är fortfarande effektivt understödda när busslängden är 1000 km. 5.2.2 Diskussion 1 Utnyttjande av en centraliserad tokenadministratör har många fördelar. Klienter kan vara enkla när de bara innehåller lägesinformation relaterad till deras egna öppnade kanaler. effektiv Luckåteranvändning är också enkel och emedan luckservern har samtliga fria tokens att välja från vid försök att tillfredställa en användarbegäran. Servern kan också real- isera andra policyrelaterade funktioner såsom upptagnings- kontroll och rättvisa. Fragmenteringen av den fria tokenpoolen i servern år normalt mycket modest, vilket resulterar i mycket få förbindningsupprättandemeddelanden per kanal även för an- vändarbegäran av hög kapacitet.

Det finns också nackdelar. En användare som frekvent upprättar och förstör kanaler kan introducera excessiv signalering genom att alltid skicka tillbaka tokens efter användning men sedan återigen begära tokens inonm en kort tidsperiod. Processka- paciteten hos servernoden kan bli överbelastad om det finns för många noder på bussen eller om den genomsnittliga för- packningsstorleken är mycket liten. Om medialängden är mycket stor relativt produkten av bit-period, kan bit-per-paket och mediahastighetens rundtrippstid till servern även begränsa 10 15 515 901 52 prestandan. Slutligen innehåller servernoden statusinformation som alla noder är beroende av för att skapa kanaler. Ett fel pà servernoden kan därför påverka alla noderna. 5.3 Distribuerad tokenstyrningsprestanda I denna sektion beskrivs resultat från simulering av en helt distribuerad tokenadministrering. 4 5.3.1 Distribuerad tokenadministrering När man utvärderar prestandan hos den distribuerade tokenadministreringen med luckåteranvändning och defragmentering använder vi samma trafik och parametrar som i sektion 5.2, men använde en policy varigenom begäran accepteras om 50% av den begärda kapaciteten kan allokeras.

Resultaten som presenteras i fig. 20 emanerar från simulatorn med luckåteranvändning, en helt distribuerad tokenadministrering, statusmeddelanden som beskriver hur mycket kapacitet som en nod äger och defragmenteringsplanen.

Alla noder har samma processkapacitet och processbelastningen är mycket lägre än vad servrarna i fig. 18 mottar.

Avhàngigheterna mellan noder är också mycket mindre vilket resulterar i högre grad av tillförlitlighet. Systemet ger bättre prestanda än nàgot annan system som inte tillhandahåller luckåteranvändning men inte lika bra som det tidigare beskrivna centraliserade systemet.

Vid jämförelse mellan prestandan i denna konfiguration och den centraliserade tokenadministreringen i fig. 18 ser vi att 10 15 20 515 901 53 blockering är högre och några begäran kan blockeras vid en mycket mindre belastning i den distribuerade realiseringen.

Ett resultat som vi inte förväntade var att prestandan i verkligheten -minskade- när paketstorleken ökade! Efter att återigen ha kontrollerat resultaten fann vi att en stor genomsnittlig överföringsstorlek resulterar i mindre rörlighet för tokens och att statusinformationen i verkligheten ger en t.o.m. värre syn på fria resurser i nätet än för korta överfö- ringar. I detta fall avslås en begäran, om vi inte tror att vi kommer att hitta några resurser. Denna mekanism infördes för att undvika att slösa styrkapacitet när resurserna var uttömda.

Skälet härför är att statusmeddelandena bara beskriver "globala" tokens som täcker alla segmenten på bussen. En global token kan användas av vilken nod som helst och är den enda typ av token i ett DTM-system utan luckåteranvändning.

Vid en belastning högre än 1.00 segmenteras ett stort antal tokens och återanvändningsplanen behöver dem vid nya begäran.

Därför är den statusmeddelandemekanismen som vi använder, som utvecklades för ett system utan återanvändning, begränsad i sin förmåga att hjälpa nya begäran att hitta fri kapacitet och kan i sämsta fall resultera i högre grad av blockering. 5.3.2 Prestanda för den distribuerade tokenservern som en funktion av busslängd Genomströmningen och accessfördröjningen i. den distribuerade tokenadministreringen med busslängder från 1 km till 1000 km 10 15 515 901 54 visas i fig. 21. Ett litet 16 kbyte-paket sänds mellan upprättande och nedrivning av kanalen, för stora paket (100- tals kilobytes) är genomströmningsprestandan hos systemet mycket mindre påverkat av busslängden. 1 km- och 100 km- bussen ger ungefär samma genomströmning och accessfördröjnings-resultat som 10 km-bussen emedan den bundenhet som introduceras genom att utnyttja en 125us cykel dominerar över systemets time-of-flight-bundenhet. För den 1000 km lànga bussen ser vi att accessfördröjningen befinns vara mycket kortare än i 1000 km-systemet utnyttjande en centraliserad tokenserver, särskilt vid låg belastning ligger tokens mycket nära den plats där användarbegäran anländer och fördröjningen är ungefär samma för alla system. Även vid mycket hög belastning är accessfördröjningen ungefär 1 millisekund kortare än i systemet med den centraliserade SerVêrn . 10 l5 E20 515 901 55 5.3.3 Skur- och klientservertrafiktillstånd Det centraliserade tokenadministreringssystemet kommer att ha samma prestanda, nästan oberoende av trafiken så länge som databearbetning och signalering är tillräcklig. För att utvärdera det distribuerade systemet beslöt vi att använda två andra trafikgeneratorer. Först använde vi en generator som simulerar användarbegäran som kommer i skurar. När en begäran ankommer definierade vi att en ny begäran skulle anlända med 90% säkerhet efter 200 us. För det andra och. i syfte att generera trafik som mera liknar klientserversätt ökade vi mängden av trafik som anländer till fem servernoder O, 25, 50, 75 och 99. Även sannolikheten för en serverdestination är också högre.

I fig. 22 presenterar vi genomströmning och access- fördröjningsprestanda för det distribuerade tokenserver- systemet. 5.3.4 Diskussion Det står klart att den distribuerade förverkligandet har flera fördelar' men även. nackdelar jämfört med den centraliserade tokenservermodellen. Noderna kan dela processbelastningen, det förekommer mindre behov av tokenservrar av högprestandatypen, redundansen kan vara högre och accessfördröjningen kan vara kortare för làgkapacitetbegäran. Nackdelarna är högre blocke- ring för en oflexibel användare som därför kan. behöva att begära kapacitet flera gånger för att få tillgång till också klart att nödvändiga resurser. Det står lO 15 iëß 515 901 56 statusmeddelandet och statustabellmekanismen måste ändras för att undvika onödig blockering när luckåteranvändning medges. 6 Framtida arbete och slutsatser Detta dokument har 'visat att DTM-typen av snabbt kretskop- plande protokoll fungerar bra i en dubbelbussdelad mediaom- Tvà luck- och båda givning. (token) administreringsplaner analyseras fungerar bra och kan dra fördel av luckàteranvändning. Den centraliserade planen ligger närmast det ideala protokollet och resulterar också i ett enkelt förverkligande.

Den distribuerade planen är känsligare för användaruppträdande och. man. mäste därför lita. på statusinformationen som sänds frekvent och en defragmenteringsplan för att minska antalet styrmeddelanden som behövs för kanalupprättande och luckreallokering. Den distribuerade modellen kan fortfarande förbättras i området för reallokering. När bussar är långa (hundratals till tusentals km) frånkopplar det distribuerade sättet effektivt accessfördröjningen från rundtrippstiden pà bussen.

Framtida arbete är en omkonstruktion av statusmeddelandeplanen och för att utvärdera en plan som kombinerar den distribuerade och den centraliserade tokenservern, utnyttjande en liten uppsättning av tokenservernoder.

Konklusionerna är att overhead för förbindningsupprättande kan hållas låg, vilket resulterar i ett högt utnyttjande även för smà (några kilobytes) överföringar. Accessfördröjningen 515 901 57 befinns vara några hundra mikrosekunder även vid hög belastning. Luckàteranvändningsplanen kan öka prestandan med en faktor av tvâ utan att införa någon ny extra hårdvara i noderna. 10 15 20 ~~....« ”ïààß 515 901 58 C. Tillägg Nätverket är inte begränsat till en dubbelbuss utan kan realiseras med alla strukturtyper, t.ex. en ringstruktur med ett godtyckligt antal noder. Transmissionsmediumet kan, förutom optisk fiber, vara koaxialkabel' eller annat transmissionsmedium med hög bandbredd. I beskrivningen kommer transmissionsmedium refereras till såsom fiber. optisk Bandbredden av DTM' dubbelbussen är, i den föredragna utföringsformen, uppdelad i 125 ps cykler, vilka i sin tur är tidluckor. uppdelade i 64 bitars Uppfinningen är inte begränsad till DTM nätverk med dessa värden, utan kan användas i nätverk med cykler och tidluckor av godtycklig storlek.

Prestandaökningen med tidluckeåteranvändning är klar: käll- på en dubbelbuss där och destinationsparen är likformigt fördelade har' genomströmningen 'visat sig öka xned. en faktor två. Prestandaökningen kan t.o.m. bli ännu högre i andra nätverkstyper; t.ex. i en dubbelringstruktur* med käll- och destinationsparen likformigt fördelade kan genomströmningen öka med en faktor fyra.

En konsekvens av DTM's tidluckereallokeringsmekanimn är att det tar längre tid att etablera kanaler som behöver större bandbredd. Denna “trade-off" kan vara berättigad: den typ av trafik som kräver låg mediumaccessfördröjning är normalt mindre känslig för den bandbredd som allokeras för överförandet, och därför kan sådan trafik accepteras utan större inblandning av reallokeringsprotokollet. För överföringar som kräver större bandbredd kommer 10 15 20 ..-..... Éàfàfs 515 9 01 59 accessfördröjningen att vara högre och reallokeringsprotokollet kommer nästa alltid att användas.

Emellertid, kommer bredbandsöverföringar antagligen att vara mindre känsliga för accessfördröjningar.

Simuleringarna ovan beskrivna har visat att DTM's snabba kretskopplade protokoll uppträder väl i. en dubbelbuss-delat medium-miljö. Två tidluckeadministreringsscheman är analyserade och bàda'uppträder gott och kan dra fördel av tidluckeåteranvändning. Det centraliserade schemat uppträder närmast det ideala protokollet och är samtidigt lättare att implementera. Det distribuerade systemet är mer känsligt för användaruppträndande och måste därför förlita sig till statusinformation som sänds frekvent samt till defragmenteringsmekanismen för att minska antalet styrmeddelanden som behövs för kanaletablering och tidluckereallokering. Genom att på långa bussar använda den distribuerade modellen med defragmenteringsmekanism kan bättre prestanda erhållas än för den centraliserade modellen. Ett resursadministreringssystem som kombinerar den centraliserade och. den distribuerade modellen. genom att använda en rnindre uppsättning tokenservernoder är också möjligt.

Dessutom kan anslutningsetablerings-overhead hållas mycket låg, vilket resulterar i en hög utnyttjandegrad även för små (några kbyte) överföringar. Accessfördröjning är några hundra mikrosekunder även vid höga laster. Tidluckeàteranvändnings- metoden kan öka prestanda med en faktor två (på en dubbelbuss) måste tillföras noderna. När utan att extra hårdvara 60 tidluckeáteranvändningsmetoden används är det ännu viktigare att använda defragmenteringsmetoden eftersom fragmentering kan ske både i tidlucke- och segmentledd. 10 l5 20 .Åä5 515 901 61 D. Ytterliggare detaljbeskrivningar och kommentarer till beskrivningen ovan I beskrivningen ovan beskrivs speciellt ett centraliserat system kännetecknat av att endast en hemnod existerar för alla tokens och att fria (lediga) tokens alltid återvänder direkt till hemnoden.

I det fullt distribuerade systemet är alla noder hemnoder (servernoder) och tokens är jämnt fördelade över alla hemnoder. Fria tokens återvänder inte direkt till sina hemnoder utan stannar kvar i de noder där de senast befann sig tills dess de flyttas till av en användarbegäran från en annan nod.

Med defragmenteringsmetoden kan tokens även flyttas tillbaka till sina hemnoder efter det att en signifikant tid har gått (t.ex. när de varit fria (lediga) en viss tid, s.k. “idle-tid" eller när de inte varit i sin hemnod på en viss tid, s.k. “last home-tid”). Man talar om gravitation - låg gravitation motsvarar lång signifikant tid och hög gravitation motsvarar kort signifikant tid. Det ovan centraliserade systemet har då en oändligt hög gravitation (signifikant tid = O) medan det distribuerade systemet utan defragmenteringsmekanism har gravitation = O (signifikant tid = w).

Det bör påpekas att resursadministreringsschemat är tillämpligt på alla mellanting mellan dessa specialfall.

Antalet hemnoder kan variera fràn 1 till totala antalet noder.

Gravitationen kan oberoende variera från O till oändligheten. 10 15 ï-fáø É-áß 62 Det talas även om att vid sammanslagning av intilliggande blocktokens bör sammanslagning i segmentled prioriteras före sammanslagning i tidluckeled.

Vi ger några exempel i anslutning till bifogade figurer för att förtydliga.

I fig. 23 visas ett tokendiagram med två tidluckekonsekutiva blocktokens A och B.«Här sker normalt ingen uppsplittning/ sammanslagning eftersom segmenten då skulle bli kortare.

I fig. 24 visas två segmentkonsekutiva blocktokens C och D.

Här sker normalt uppsplittning av de två blocktokens C och D enligt streckad linje. Därefter sker sammanslagning av de två bildade blocktokens C' och D' till en token C'D' med dubbelt så långt segment. Detta resulterar totalt i tre nya block tokens, C", D" och C'D'.

I fig. 25 visas tre blocktokens, E, F, G. Här sammanslås företrädesvis F och G till FG för att öka segmentstorleken.

I fig. 26 visas två blocktokens, H och I. Den efterfrågade kapaciteten motsvarar halva II och hela II och skall skickas från nod A, NA till nod B, NB. Hår väljes då H för transport, vilken splittas enligt streckad linje.

I fig. 27 visas en token, J. Den efterfrågade kapaciteten motsvarar halva J och skall skickas från nod A, NA till nod B, NB. Hår väljes då del av J för transport, vilken del lågges i överkant eller som i fig. 27 i underkant av J. Det som blir över måste då splittas (blocktoken är normalt rektangulär). 10 15 20 5 1 5 9 0 1 gi: ïp::-¿ 63 Detta görs då företrädesvis enligt streckad linje för att bevara så stora segment som möjligt.

Det behöver naturligtvis inte vara. på detta sätt. I vissa tillämpningar kan' man tänka sig att sammanslagning i tidluckeled prioriteras före sammanslagning i segmentled.

Normalt innehåller statustabellen bara information om tidluckor som är fria,över alla segment. Man skulle dock kunna tänka sig att även information om segment kan finnas i dessa statustabeller.

Det blir dock mycket mer information att sprida till övriga noder.

En annan mekanism som företrädesvis kan implementeras kommer i det följande beskrivas i anslutning till figur 28. Om nod O, (b-a) segment, men ska skicka kapaciteten (b-a) endast till nod N, NO, har tillträde till kapaciteten och över alla NN, så har den ingen nytta av segmenten NN och uppåt. Dessa kan då skickas med till NN för dennes framtida behov. På samma sätt om nod N, NN, har tillgång till kapaciteten (tidluckorna) (d-c) och ska skicka denna kapacitet till nod M, NM, så skickar den även med de fria segmenten NM och uppåt vidare till noden M, NM, för dennes framtida behov. Tokenblock (NO- NN)*(d-c) kommer att skickas ned till nod O, NO, för dennes eventuellt framtida behov. Härvid krävs extra signalering varvid detta tokenblock (NO-NN)*(d-c) kan skickas med en eventuellt lägre prioritering. ¿§?5 10 15 20 64 FIGURBESKRIVNING Fig. DTM-multiplexeringsformat. l.

Fig. 2. DTM-noder förbundna i en nätstruktur.

Fig. 3. En fleradressgrupp.

Fig. 4. Genomströmning och accessfördröjning för olika paketstorlekar.

Fig. 5. Genomströmning och fördröjning för strikt kapacitets- förfrågan med omfrágning (16 kilobyte överföringar).

Fig. 6. Genomströmning och accessfördröjning för olika an- vändarkrav (16 kilobyte överföringar).

Fig. 7. Nätverksgenomströmning och accessfördröjning som en funktion av busslängd (16 kilobyte överföringar).

Fig. 8. Genomströmning och accessfördröjning i ett 20x20- galler.

Fig. 9. Ett DTM-nätverk av dubbelbusstruktur.

Fig. 10. DTM 125 us cykel.

Fig. 11. En tokenkarta visande tidluckenummer och segment.

Fig. 12. En tidlucke-segmentkarta visande återanvändning av tidluckor.

Fig. 13. En distribuerad tokenserver.

Fig. 14. Användaromförfràgning för ökande av utnyttjandegraden (16kB).

Fig. 15. Defragmentering: accessfördröjning som funktion av simulerad tid.

Fig. 16. Teoretisk dubbelbuss och DTM genomströmning.

Fig. 17. En centraliserad tokenserver. 65 Fig. 18. En centraliserad tokenserver och tidluckeàteranvändning.

Fig. 19. En 1000 km lån buss med centraliserad tokenserver.

Fig. 20. Utnyttjande och accessfördröjning: distribuerad tokenserver.

Fig. 21. 1-1000 km lång buss med distribuerad tokenserver.

Fig. 22. Distribuerad tokenserver.

Fig. 23-28. Tidlucke-segmentkartor.

Claims (38)

10 15 20 25 30 35 515 901 éó PATENTKRAV

1. Plan för centraliserad administrering av kapa- citeten i ett kretskopplat nätverk av buss eller ring- struktur, vilket nätverk utnyttjar en bandbredd som är upp- delad i cykler, som i sin tur är uppdelade i styrtidluckor för signalering och datatidluckor för överföring av data, och där varje datatidlucka är associerad med en token, k ä n n e- t e c k n a d av - att en första nod, kallad servernod, tilldelas tokens motsvarande alla i en riktning strömmande datatidluckor i en buss eller ring, - att en andra nod begär tokens motsvarande en viss kapa- citet från servernoden, - att servernoden reserverar och överför tokens motsvarande begärda kapacitet till den andra noden i händelse av att servernoden har begärd kapacitet outnyttjad, och, - att överförda tokens återsänds till servernoden och frigörs då motsvarande datatidluckor ej har använts för data- överföring av den andra noden under en signifikant tid.

2. Plan enligt kravet 1, k ä n n e t e c k n a d a v att den implementeras i ett nätverk av DTM-typ (digitalt synkront överföringssätt).

3. Plan enligt kravet 1 eller 2, k ä n n e t e c k- n a d av att överförda tokens återsänds till servernoden och frigörs då motsvarande datatidluckor ej längre används för dataöverföring.

4. Plan enligt något av kraven 1 - 3, k ä n n e- t e c k n a d a v att servernoden väljes som den nod som har 1/3 av noderna uppströms och 2/3 av noderna nedströms.

5. Plan för distribuerad administering av kapacitet i ett kretskopplat nätverk av buss eller ringstruktur, där bandbredden är uppdelad i cykler, som i sin tur är uppdelade 10 15 20 25 30 35 515 901 b? i styrtidluckor för signalering och datatidluckor för över- föring av data, och där varje datatidlucka är associerad med en token (skrivaccess), k ä n n e t e c k n a d a v - att minst två noder, kallade servernoder, definieras bland vilka tokens motsvarande alla i en riktning strömmande data- tidluckor i en buss eller ring fördelas, - att en nod begär tokens motsvarande en viss kapacitet från minst en av servernoderna, - att denna servernod reserverar och överför tokens motsvar- ande begärd kapacitet till den begärande noden i händelse av att servernoden har begärd kapacitet outnyttjad, och - att en eller flera servernoder ej överför någon token till den begärande noden i händelse av att servernoderna tillsam- mans ej har begärd kapacitet outnyttjad.

6. Plan enligt kravet 5, k ä n n e t e c k n a d a v att den implementeras i ett nätverk av DTM-typ (digitalt synkront överföringssätt).

7. Plan enligt kravet 5 eller 6, k ä n n e t e c k- n a d a v att flera servernoder tillfrågas, reserverar och överför tokens, vilka tillsammans motsvarar den totalt begärda kapaciteten, till den begärda noden i händelse av att servernoderna tillsammans har begärd kapacitet outnyttjad.

8. Plan enligt något av kraven 5 - 7, k ä n n e- t e c k n a d a v att erhållna tokens används för kanalupp- rättande genom att skicka ett kanalupprättandemeddelande till den eller de noder som avses vara mottagare av data i händelse av att en nod har erhållit tokens motsvarande begärd kapacitet.

9. Plan enligt något av patentkraven 5 - 7, k ä n n e- t e c k n a d verar och överför tokens motsvarande all outnyttjad kapacitet a v att en eller flera servernoder reser- till den begärande noden i händelse av att servernoderna tillsammans ej har begärd kapacitet outnyttjad. 10 15 20 25 30 35 515 901 68'

10. Plan enligt kravet 9, k ä n n e t e c k n a d a v att ytterligare tokens begärs av en nod i händelse av att eventuellt erhållna tokens ej motsvarar begärd kapacitet.

11. Plan enligt kravet 9, k ä n n e t e c k n a d a v att i en nod erhållna tokens frigörs i händelse av att dessa tokens ej motsvarar begärd kapacitet.

12. Plan enligt kravet 9, k ä n n e t e c k n a d a v att erhållna tokens används för kanalupprättande genom att skicka ett kanalupprättandemeddelande till den eller de noder som avses vara mottagare av data i händelse av att en nod ej har erhållit tokens motsvarande begärd kapacitet.

13. Plan enligt något av kraven 5 - 12, k ä n n e- t e c k n a d a v att varje servernod regelmässigt sänder information angående sin fria kapacitet till övriga noder och varje nod lagrar från de andra noderna erhållen information i en statustabell.

14. Plan enligt något av kraven 5 - 13, k ä n n e- t e c k n a d servernod som för tillfället har mest outnyttjad kapacitet. a v att en nod begär tokens från den

15. Plan enligt något av kraven 5 - 13, k ä n n e- t e c k n a d nod som ligger närmast och för tillfället har begärd kapa- a v att en nod begär tokens från den server- citet outnyttjad.

16. Plan enligt kravet 14 eller 15, k ä n n e t e c k- n a d a v att den servernod från vilken kapacitet begäres finnes genom att referera till statustabellen.

17. Plan enligt något av kraven 5 - 16, k ä n n e - t e c k n a d a v att alla noder i en buss eller ring definieras såsom servernoder och tilldelas åtminstone en token. 10 15 20 25 30 35 515 901 -¿'*':':f 69

18. Plan enligt kravet 17, k ä n n e t e c k n a d a v att alla noder i en buss eller ring tilldelas lika många tokens.

19. Plan enligt något av kraven 5 - 18, k ä n n e- t e c k n a d a v att överförda tokens åersänds till respektive servernod, även kallad hemnod, och frigörs då motsvarande datatidluckor ej längre används för dataöver- föring.

20. Plan enligt något av kraven 5 - 18, k ä n n e- t e c k n a d a v att överförda tokens frigörs då mot- svarande datatidluckor ej längre används för dataöverföring.

21. Plan enligt kravet 20, k ä n n e t e c k n a d av att överförda tokens reserveras, återsänds till respek- tive servernod, även kallad hemnod, och frigörs då mot- svarande datatidluckor ej har använts för dataöverföring under en signifikant tid.

22. Plan enligt något av kraven 1 - 21, k ä n n e- t e c k n a d a v att konsekutiva tokens i en nod repre- senteras av en token, kallad blocktoken, som anges som ett nummer för den första tidluckan i en rad och det totala antalet tidluckor i raden.

23. Plan enligt något av kraven 1 - 22, k ä n n e- t e c k n a d a v att en token delas upp i minst två tokens svarande mot samma tidlucka, men mot olika segment, där segment refererar till en del av ett transmissionsmedium som sammankopplar minst två noder.

24. Plan enligt något av kraven 1 - 23, k ä n n e- t e c k n a d a v att servernoden, i händelse av att den har flera tidlucke- eller segmentkonsekutiva grupper av tokens att välja bland, reserverar och överför de tokens som härrör från den minsta grupp av tidlucke- eller segmentkonse- 10 15 20 25 30 35 515 901 70 kutiva tokens som uppfyller en kapacitetsbegäran, och där den minsta gruppen definieras som den grupp vars produkt av tid- luckor och segment med förutbestämda vikter är lägst.

25. Plan enligt något av kraven 1 - 24, k ä n n e- t e c k n a d a v att grupper av tokens, vilka är åtmins- tone delvis segmentkonsekutiva, omgrupperas för att maximera antalet konsekutiva segment per grupp av tokens på bekostnad av antalet konsekutiva tidluckor.

26. Nodstyrenhet i en nod i ett kretskopplat nätverk av buss eller ringstruktur, vilket nätverk utnyttjar en band- bredd som är uppdelad i cykler, som i sin tur är uppdelade i styrtidluckor för signalering och dataluckor för överföring av data, och där varje datatidlucka är associerad med en token, k ä n n e t e c k n a d a v - att nodstyrenheten är tilldelad tokens motsvarande ett förutbestämt antal i en riktning strömmande datatidluckor i en buss eller ring och, - att nodstyrenheten är arrangerad att reservera och överföra tokens till en andra nodstyrenhet i en andra nod i händelse av att den erhåller en begäran om tokens från den andra nodstyrenheten och att en har begärd kapacitet out- nyttjad.

27. Nodstyrenhet enligt kravet 26, k ä n n e t e c k- n a d a v att nätverket är av DTM-typ (digitalt synkront överföringssätt).

28. Nod, även kallad servernod, i ett kretskopplat nät- verk av buss eller ringstruktur, vilket nätverk utnyttjar en bandbredd som är uppdelad i cykler, som i sin tur är upp- delade i styrtidluckor för signalering och datatidluckor för överföring av data, och där varje datatidlucka är associerad med en token, k ä n n e t e c k n a d a V en nodstyrenhet, vilken är tilldelad tokens motsvarande ett förutbestämt antal i en riktning strömmande datatidluckor i en buss eller ring 10 15 20 25 30 35 515 901 H och arrangerad att reservera och överföra tokens till en andra nodstyrenhet i en andra nod i händelse av att den erhåller en begäran om tokens från den andra nodstyrenheten och att den har begärd kapacitet outnyttjad.

29. Nod enligt kravet 28, k ä n n e t e c k n a d a v att nätverket är av DTM-typ (digitalt synkront överförings- sätt).

30. Nod enligt kravet 28 eller 29, k ä n n e t e c k- n a d a v att den är tilldelad tokens motsvarande alla i en riktning strömmande datatidluckor i en buss eller ring.

31. Nod enligt kravet 30, k ä n n e t e c k n a d a v att den har 1/3 av bussens eller ringens noder uppströms och 2/3 av bussens eller ringens noder nedströms.

32. Kretskopplat nätverk av buss eller ringstruktur, vilket nätverk utnyttjar en bandbredd som är uppdelad i cykler, som i sin tur är uppdelade i styrtidluckor för signalering och datatidluckor för överföring av data, och där varje datatidlucka är associerad med en token, k ä n n e- t e c k n a t tilldelad tokens motsvarande ett förutbestämt antal i en a v en nod, även kallad servernod, vilken är riktning strömmande datatidluckor i en buss eller ring och arrangerad att reservera och överföra tokens till en andra nod i händelse av att den erhåller en begäran om tokens från den andra noden och att den har begärd kapacitet outnyttjad.

33. Kretskopplat nätverk av buss eller ringstruktur, vilket nätverk utnyttjar en bandbredd som är uppdelad i cykler, som i sin tur är uppdelade i styrtidluckor för sig- nalering och datatidluckor för överföring av data, och där varje datatidlucka är associerad med en token, k ä n n e- t e c k n a t a v att minst två noder, kallade server- noder, är definierade bland vilka tokens motsvarande alla i en riktning strömmande datatidluckor i en buss eller ring är 10 15 20 25 30 35 515 901 H) fördelade och, att servernoderna är arrangerade att reser- vera och överföra tokens till en tredje nod i händelse av att servernoderna erhåller en begäran om tokens från den tredje noden och att de har begärd kapacitet outnyttjad.

34. Kretskopplat nätverk enligt kravet 32 eller 33, k ä n n e t e c k n a t a v att det utgöres av ett nätverk av DTM-typ (digitalt synkront överföringssätt).

35. Kretskopplat nätverk enligt något av kraven 32 - 34, k ä n n e t e c k n a t a v att en nod är arran- gerad att använda erhållna tokens för kanalupprättande genom att skicka ett kanalupprättandemeddelande till den eller de noder som avses vara mottagare av data i händelse av att noden har erhållit tokens motsvarande begärd kapacitet.

36. Kretskopplat nätverk enligt något av kraven 33 - 35, k ä n n e t e c k n a t a v att en eller flera servernoder är arrangerade att reservera och överföra tokens motsvarande all outnyttjad kapacitet till den begärda noden i händelse av att servernoderna tillsammans ej har begärd kapa- citet outnyttjad.

37. Kretskopplat nätverk enligt något av kraven 33 - 35, k ä n n e t e c k n a t a v att en eller flera servernoder är arrangerade att ej överföra någon token till den begärande noden i händelse av att servernoderna till- sammans ej har begärd kapacitet outnyttjad.

38. Kretskopplat nätverk enligt något av kraven 33 - 37, k ä n n e t e c k n a t a v att en nod är arran- gerad att använda en statustabell, en tämligen regelbundet uppgraderad lista över servernoders outnyttjade kapacitet, för beslut om vilken servernod den ska begära tokens från.