UNIVERSITETET I OSLO Institutt for Informatikk

Transkript

1 UNIVERSITETET I OSLO Institutt for Informatikk Optisk abonnenttilknytning En simulering på bruk av optisk fiber over lange avstander Steinar M. Aasheim Hovedfagsoppgave Cand.Scient

2

3 Forord Dette er en hovedfagsoppgave i kommunikasjonssystemer ved Institutt for Informatikk, Universitetet i Oslo. Oppgaven er tatt ved Universitetsstudiene på Kjeller (UniK). Jeg har hatt to veiledere til oppgaven. Dette er Ragnar Andreassen (Telenor FoU) og Aasmund Sudbø (UniK). Å være hovedfagsstudent ved UniK har vært en veldig fin erfaring. Her er det et meget bra arbeidsmiljø og svært gode arbeidsforhold. Faglige utfordringer har det heller ikke vært mangel på. Jeg vil først rette en stor takk til min eksterne veileder Ragnar Andreassen. Vi har hatt jevnlige møter, og jeg har fått oppmuntring, støtte, masse nyttige innspill og god hjelp. Videre vil jeg også rette en takk til min interne veileder, Aasmund Sudbø. Takk også til medstudenter (spesielt Svend Eriksen) for hjelp og innspill i forhold til oppgaven. Til slutt vil jeg rette en stor takk og tilegne denne oppgaven til mine foreldre for konstant støtte og oppmuntring i tiden jeg har jobbet med denne oppgaven. Universitetsstudiene på Kjeller, april 2000 Steinar Mollgard Aasheim i

4 ii

5 Innhold Kapittel 1 - Innledning og oversikt Motivasjon og problemstilling Sammendrag Oppgavens struktur... 8 Kapittel 2 - Bakgrunnsstoff Passive optiske nett (PON) Aksessarkitekturer Optisk fiber Ytelse i lokalnett Mål for ytelse Analyse av forsinkelse Trafikktyper Token bus Tilgang til overføringsmediet Overføringsmedium og hastighet Administrasjon av den logiske ringen Ethernet Begrensninger Hva skjer når kabellengden økes? Token ring FDDI DQDB Aksesskontroll iii

6 2.8 Nettsimulering OpNet Kapittel 3-Overordnet diskusjon Problemstilling og metode Problemstilling En mulig nettløsning Modellen Forenklinger i modellen Egenskaper for nodene Egenskaper for sentralen Spesifikasjon av den passive effektdeleren Oppbygning av simuleringsmodellen Generering av trafikk Modellparametre og typiske resultater Konfigurasjon Resultater Diskusjon Kapittel 4 - Undersøkelser Scenario 1: Lengden på overføringen Konfigurasjon Resultater Diskusjon Scenario 2: Antall noder Konfigurasjon Resultater Diskusjon Scenario 3: Token holding time Konfigurasjon Resultater Diskusjon Alternativer og utvidelser Kapittel 5 - Oppsummering Oppsummering og konklusjon Oppsummering av scenario Oppsummering av scenario Oppsummering av scenario Konklusjon iv

7 5.3 Tilbakeblikk og kommentarer Appendiks A - Programkode...75 A.1 PKSW_FIFO A.2 PKSW_ND_PROC A.3 PKSW_HUB_PROC A.4 Skript Referanser...97 Bibliografi...99 Indeks v

8 vi

9 KAPITTEL 1 Innledning og oversikt 1.1 Motivasjon og problemstilling I et passivt optisk nett (PON) knyttes brukere og endesentral sammen ved hjelp at optiske fibre og passive optiske effektfordelere. I et slikt nett vil overføringsmediet være en felles ressurs mellom brukere tilknyttet nettet. Denne ressursen må reguleres når flere brukere har samtidige kommunikasjonsbehov. Dette er en velkjent problemstilling i datanett, og mange arbiteringsprotokoller er standardisert. I denne oppgaven ønsker vi å se på hvordan slike standard protokoller kan tilpasses PON. Studien vil bli gjennomført ved å formulere og implementere en simuleringsmodell. Dette vil kunne fortelle noe om hvordan kjente protokoller oppfører seg under endrede rammebetingelser, og hvilke modifikasjoner som kunne være ønskelige å foreta i protokollen. 1.2 Sammendrag Som nevnt har denne oppgaven bestått i å definere og implementere en simuleringsmodell for deretter å kjøre et sett med simuleringer. Målet har vært å finne ut om den nettkonfigurasjonen vi ønsket å se på var så god som vi håpet at den skulle være. For å finne ut dette har det blitt kjørt et stort antall simuleringsrunder og det er brukt flere sett parametre. Modellen er implementert i simuleringsvektøyet OpNet. Dette er et objektorientert verktøy der man kan bygge opp modeller ved hjelp av en grafisk representasjon. Egenskapene til de forskjellige objektene i modellen programmeres 7

10 8 Kapittel 1 i C. (Mer om OpNet i kapittel ) Modellen ble nøye testet før simuleringene ble kjørt. Etter at alle simuleringsrundene var ferdige ble resultatene verifisert for at vi skulle være sikre på at målingene våre ga riktig svar. Resultatene fra simuleringene har vist at modellen har en del begrensninger og at en slik nettløsning kanskje ikke er den beste løsningen. Generelt ser man at systemet ikke fungerer tilfredsstillende for lave båndbredder. Når båndbredden øker blir resultatene bedre, men det er likevel være en viss forsinkelse i systemet og denne forsinkelsen vil øke når antall noder i nettverket økes. Ende til ende forsinkelsen som er målt er for stor til at denne nettkonfigurasjonen kan sies å fungere bra. Den eneste konfigurasjonen av modellen som kan sies å fungere tilfredsstillende er når tilgjengelig båndbredde er høy, antall noderer lavt og det blir generert lite trafikk. 1.3 Oppgavens struktur I kapittel 2 er en del emner som er aktuelle for oppgaven beskrevet. Kapittelet tar blant annet opp emner som passive optiske nett (PON), Ethernet, Token bus, Token ring, FDDI og DQDB (Distributed Queue, Dual Bus). Ethernet og Token bus er de to protokollene som er brukt i arbeidet med modellen. DQDB er en standard vi gikk bort fra, blant annet på grunn av kostnader ved en virkelig implementasjon. Ideer og funksjonalitet er hentet fra Token ring og FDDI. Kapittel 3 gir en nærmere beskrivelse av problemstilling og metode. Videre kommer en detaljert beskrivelse av modellen, samt begrunnelser for hvorfor den er laget slik som den er gjort. Dette kapittelet beskriver også resultatene fra første runde med simuleringer. Her forklares også de forskjellige parametrene i modellen. Kapittel 4 beskriver de undersøkelsene som er gjort. Simuleringene er kjørt for tre forskjellige scenarier. For hvert av de tre scenariene er hvilke premisser som er lagt til grunn for undersøkelsene presentert, hvordan konfigurasjonen for scenariet er, samt resultater og diskusjon. Alternative løsninger og forbedringer og utvidelser av modellen er drøftet i kapittel 4.4. I kapitel 5 kommer en oppsummering av alle resultatene, kommentarer til oppgaven, samt konklusjon. Sist i oppgaven er det vedlagt programkode, samt noen av de skriptene som er

11 Innledning og oversikt 9 brukt for å kjøre simuleringene automatisk og for å generere parameterfiler og konvertere resultatfiler.

12 10 Kapittel 1

13 KAPITTEL 2 Bakgrunnsstoff Dette kapittelet beskriver en del teori som har vært viktig å sette seg inn i under arbeidet med oppgaven. Først kommer en oversikt over hvordan passive optiske nett (PON) fungerer. Deretter følger noen betraktninger knyttet til køsystemer, trafikkmodeller og ytelse i nett. Videre kommer en presentasjon av Token bus, Ethernet, Token ring, FDDI og DQDB. Vi har valg å se nærmere på disse protokollene fordi alle har egenskaper vi ønsker å benytte oss av i simuleringsmodellen. Kapittelet avsluttes med en presentasjon av nettsimulering og simuleringsprogrammet OpNet som simuleringsmodellen er utarbeidet i. 2.1 Passive optiske nett (PON) En type nett som har vist seg å være en hensiktsmessig løsning både for telefoni (TPON) og bredbåndstjenester (BPON) er passive optiske nett (PON). I et PON knyttes abonnentene sammen ved hjelp av effektfordelere. Det nyttes Node 1 Sentral Splitt Node 2 Tilførsel (delt eller dedikert) Distribusjon (kringkastet eller svitsjet) Figur 2.1: Generell aksessarkitektur for et passivt optisk nettverk (PON). På figuren er den passive optiske effektdeleren merket splitt. 11

14 12 Kapittel 2 passive 1:M effektfordelere for å knytte M abonnenter til en sentral. Siden informasjonen fra sentralen kringkastes til alle abonnentene, vil den optiske effekten deles på M abonnenter. En slik deling av effekten fører til begrensninger i hvor mange abonnenter som kan knyttes til en sentral. Et passivt optisk nett er skissert i figur 2.1. Når mange abonnenter skal dele mediet, er man avhengig av å kunne skille informasjonen tilhørende den enkelte abonnent fra informasjonen til andre abonnenter. Det er flere måter man kan gjøre dette på. Samtidig er det ønskelig å utnytte fiberens kapasitet på best mulig måte ved å tilknytte så mange abonnenter som mulig til nettet. Teknikkene som kan brukes for å skille informasjon fra forskjellige abonnenter fra hverandre er tidsdelt multipleksing (TDM), underbærebølgemultipleksing (SCM), optisk bølgelengdemultipleksing (WDM) og kodedelt multipleksing (CDM). Sistnevnte er foreløpig på forskningsstadiet. Neste avsnitt gir en mer utfyllende beskrivelse av de forskjellige teknikkene. I et passivt optisk nettverk finnes det ikke noen andre aktive enheter enn sender og mottaker. Dette gjør at et PON vil være lett å vedlikeholde, lette å oppgradere og de vil være driftssikre. En oppgradering kan for eksempel gjøres ved å øke signalbåndbredden for hver optiske bærebølge, eller ved å legge til flere optiske bærebølger Aksessarkitekturer Det finnes to måter å levere informasjon på i et PON. Den første måten er kringkasting, som innebærer at signalet til alle nodene er det samme som hos kilden. Den andre måten er «svitsjet» distribusjon, som gjør at signalene er unike for hver enkelt av abonnentene. Se figur 2.2. I et kringkastingsnettverk vil sentralen gi det samme signalet til alle abonnentene (figur 2.2a). Demultipleksing foregår hos abonnentene. Et kringkastingsnettverk vil være økonomisk fordi abonnentene deler mediet, nettverket er modulært, og det vil være naturlig at utstyret hos abonnenten er standardisert. Et typisk eksempel på et kringkastingsnett er kabel-tv nettet. I kabel-tv nettet er det den siste tiden også blitt brukt optisk fiber i kombinasjon med coax. Denne arkitekturen kalles ofte «hybrid fiber/coax» (HFC) og har blitt den mest dominerende netttypen for kabel-tv [Chi]. Et annet eksempel er telefoni over passive optiske nettverk (TPON). I et «svitsjet» nettverk vil signalet demultiplekses i splitten og abonnenten mottar bare de data han er interessert i. Siden det ikke skal være noen aktive komponenter i et PON må splitten i

15 Bakgrunnsstoff 13 Sentral N Splitt N Node 1 a) N Node N Node 1 Sentral N Splitt 1 b) N Node N Figur 2.2 a) Kringkastingsnettverk. Alle abonnenter mottar samme signal fra sentralen. b) Svitsjet nettverk. Signalene fram til abonnentene er unike. dette tilfellet være en form for filter, der kun en del av signalet sendes til en gitt abonnent. For å utnytte kapasiteten i fiberen bedre er det flere metoder som kan benyttes. En fordel med å benytte disse metodene er at flere abonnenter kan dele mediet. Et eksempel kan være underbærebølge multippel aksess (SCMA, som er en forkortelse for «SubCarrier Multiple Access»), som er en metode som benyttes i frekvensdomenet. Denne metoden går ut på at elektriske signaler blir modulert og multiplekset før de blir brukt til å modulere en optisk kilde. Metoden er godt egnet i systemer for kringkasting. I tidsdomenet kan tidsdelt multippel aksess (TDMA, som er en forkortelse for «Time Division Multipple Access») benyttes. Et slikt system deler opp tiden i et visst antall tidsluker. Tidslukene kan enten tildeles abonnentene eller sentralen etter behov, eller de kan få ha faste tidsluker. På denne måten kan informasjon fra flere abonnenter overføres på samme medium. En annen metode i tidsdomenet kan være kodedelt multippel aksess (CDMA, som er en forkortelse for «Code Division Multiple Access»). Metoden er i bruk i digitale optiske systemer og går ut på å generere svært kortvarige optiske pulser. På denne måten kodes hvert databit fra kilden i et pulstog med et spesielt mønster. En siste metode som kan brukes er bølgelengde multippel aksess (WDMA,

16 14 Kapittel 2 som er en forkortelse for «Wavelength Division Multiple Access»). Her får hver abonnent tildelt en bølgelengde til å sende på Optisk fiber En optisk fiber består av to deler; en glasskjerne og en glasskappe (som glasskjernen løper gjennom). Transmisjonen av signaler foregår ved hjelp av lys i en glassfiber. Lyset forplanter seg langs glasskjernen i fiberen på en av tre måter, avhengig av bredden på glasskjernen. De tre overføringsmodusene er: Multimode stepped index fiber: Alt lys som kommer inn i fiberen med en vinkel mindre enn den kritiske, blir reflektert i overflaten av glasskappen og forplanter seg langs glasskjernen ved interne refleksjoner. Tiden lyssignalet bruker gjennom fiberen vil avhenge av lysets inngangsvinkel. Utgangssignalet vil ha en bredere pulsbredde enn inngangssignalet, med en tilsvarende reduksjon i den maksimale bitraten. Multimode graded index fiber: Lyset som kommer inn blir bøyd av (reflektert) med en økende styrke ettersom signalet fjerner seg fra kjernen. Effekten av dette blir en smalere pulsbredde på det mottatte signalet, sammenlignet med stepped index fiber. Dette tillater en økning i bitraten. Singlemode fiber: Her er diameteren på glasskjernen på størrelse med en enkelt bølgelengde, slik at alt lys forplanter seg langs en enkelt vei. Det mottatte signalet er sammenlignbart i bredde med signalet som ble sendt inn. Her kan bitraten kommme opp i flere hundre megabits per sekund. Siden lysbølger har mye større båndbredde enn elektriske bølger, kan optiske fibre oppnå en transmisjonsrate på flere hundre megabits per sekund. Signalene som overføres i en fiber er mer immune mot elektromagnetisk interferens, og de er vanskelige å avlytte. 2.2 Ytelse i lokalnett Som for alle datasystem, forventes det at også et datanett skal kunne tilby høy ytelse og ofte til en lav pris. For at flere datamaskiner skal kunne dele ressurser effektivt, stilles det høye krav til nettets egenskaper. For at nettet skal bli best mulig er det av avgjørende betydning at man kjenner til og forstår de faktorene som spiller inn på nettets ytelse.

17 Bakgrunnsstoff Mål for ytelse Nettets ytelse måles ofte i to fundamentale parametre: båndbredde og forsinkelse [Dav96]. Nettets båndbredde er gitt ved antall bit som er overført over en viss periode. Et nett som har en båndbredde på 10Mbps kan altså overføre 10 millioner bit pr sekund. Hvis man ser på et bit som en puls av en viss lengde, ser man at dersom båndbredden økes vil pulsens lengde avta. For eksempel vil hvert bit på en 1 Mbps link være 1 m s brede, mens hvert bit på en 2 Mbps link vil være 0,5 m s brede (se figur 2.3). Med bredde menes hvor stor utstrekning et bit med en gitt varighet (for eksempel 1 m s) får på linken. Når båndbredden skal økes blir bitene enda kortere og dette krever at overførings og mottaksmekanismene blir enda mer avanserte. Generelt er lengden på et bit gitt ved formelen: der L er bitlengden, v er forplantningshastigheten og B er dataraten. For data som overføres på en optisk fiber med en brytningsindeks på ca 1,5 og med båndbredden 10 Mbps vil man da få følgende uttrykk: a) 1 sekund b) 1 sekund Figur 2.3: Flere bit overføres ved samme båndbredde kan sies å ha samme utstrekning på linken. a) Bits overført ved 1 Mbps (hver av dem med en varighet på 1 m s); b) Bits overført ved 2Mbps (hver av dem med en varighet på 0,5 m s). L=v/B=( m/s)/( bit/s)=20m/bit Den andre parameteren for ytelse er forsinkelse. Forsinkelsen skal fortelle hvor

18 16 Kapittel 2 lang tid det tar for et bit å gå fra en ende av nettet til den andre. Et eksempel på forsinkelse kan være at det tar 24 ms å sende et bit fra maskin A til maskin B. Ofte vil det imidlertid være mer interessant å vite hvor lang tid det tar å sende et bit fra maskin A til B og tilbake igjen. Dette kalles «round-trip-time» (RTT) og er en meget viktig parameter for eksempel for Ethernet. Forsinkelsen i nettverket består av tre deler: Forsinkelse på grunn av lyshastigheten: Denne forsinkelsen kommer inn fordi et bit aldri kan overføres fortere enn lysets hastighet. Hvis man vet avstanden mellom to punkt kan man beregne denne forsinkelsen. I en optisk fiber har lyset en hastighet på m/s. Tiden det tar å sende en dataenhet: Denne forsinkelsen er en funksjon av nettets båndbredde og størrelsen på pakken som overføres. Forsinkelse på grunn av kø: Dersom det er køsystemer i nettet, kan pakker bli liggende i kø før de blir sendt. Svitsjer i nettet inneholder ofte køer, som blir brukt før pakkene blir sendt videre. Man kan definere den totale forsinkelsen som: T D =T L +T B +T Q T L =L/v T B =N P /B Hvor L er lengden på overføringen fra A til B, v er overføringshastigheten på det aktuelle mediet, N P er antall bits i pakkene som overføres og B er båndbredden på overføringsmediet. Båndbredde og forsinkelse definerer ytelsen for en gitt link. Hvor viktig innvirkningen er, vil imidlertid avhenge av applikasjonen som kjøres. For noen Forsinkelse Båndbredde Figur 2.4: Nettverket som et rør.

19 Bakgrunnsstoff 17 applikasjoner er forsinkelsen avgjørende (for eksempel sanntidssystemer), mens for andre er det båndbredden som teller (for eksempel FTP). Både forsinkelse og båndbredde kan måles for hele nettverket, eller kun for en ønsket link. Det vil også være interessant å se på produktet av forsinkelse og båndbredde. Intuitivt kan man tenke på en link mellom to maskiner som et rør (se figur 2.4), der forsinkelsen svarer til lengden på røret og båndbredden til diameteren på røret. Produktet mellom båndbredden og forsinkelsen gir da volumet av røret - med andre ord antall bit som overføres på linken samtidig [Dav96]. Det er viktig å vite hva produktet mellom forsinkelse og båndbredde er når man skal konstruere datanett med høy ytelse. Grunnen til dette er at produktet forteller hvor mange bit senderen må sende før signalet kommer fram til mottakeren. Dersom senderen skal vite om signalet er kommet vel fram, må lengden på en pakke være minst to ganger produktet (RTT). Det er dette prinsippet kollisjonsmekanismen i Ethernet bygger på Analyse av forsinkelse Når trafikken i nettet er lav, skyldes forsinkelsen tiden det tar å videresende data i svistjene. Dersom avstanden mellom nodene er lang, vil forplantningstiden også spille inn. Hvis trafikken på nettet øker, vil størstedelen av forsinkelsen skyldes køsystemene som datapakkene må gjennom. Det vil derfor være naturilg å se nærmere på køteori i forbindelse med forsinkelsesanalysen. Køsystemer kan brukes for å modellere prosesser der en kunde ankommer, venter på tur, betjenes og sendes videre. Eksempler på køsystemer kan være venterommet på et legekontor eller kø ved kassen i butikken. Alle køsystemer kan karakteriseres ved 5 komponenter: 1 Sannsynlighetsfordelingen for ankomsttider (Ankomstprosessen); Beskriver tiden mellom hver gang en ny kunde kommer inn i køen. 2 Sannsynlighetsfordelingen for betjeningstid (Betjeningsprosessen); Hver kunde trenger en viss betjeningstid ved serveren. 3 Antall betjeningssteder (servere). 4 Køtype; Beskriver måten kundene kommer ut av køen på, for eksempel «Først inn, først ut» (FIFO). 5 Størrelsen på mellomlager i køene; Dersom køen blir for lang vil det i noen systemer føre til at nye kunder ikke kan settes inn før det er frigjort plass.

20 18 Kapittel 2 En forenkling som ofte brukes i analyse av køsystemer er at man har uendelig stort mellomlager, kun et betjeningssted og en køtype der den som kommer først blir betjent først (FIFO). En vanlig notasjon for et slikt køsystem er A/B/ m, der A står for sannsynlighetsfordelingen for ankomsttider, B står for sannsynlighetsfordelingen for betjeningstid og m for antall betjeningssteder. A og B velges fra settet: M - Eksponensiell sannsynlighetsfordeling (M står for Markov) D - Alle elementer i køen har samme verdi (D står for Deterministisk) G - Generell En modell som ofte brukes er M/M/1. Her er alle parametre kjent. En mer generell modell er G/G/m, der en eller flere av parameterne kan være ukjent. Ved simulering av køer i datanett benyttes det ofte en eksponensiell fordelingsmodell som M/M/1. Under de gitte kriteriene er sannsynligheten for at akkurat n pakker ankommer i løpet av et tidsintervall av lengden t gitt ved: der l er gjennomsnittlig ankomstrate. Tilstanden til et M/M/1 system (se figur 2.5) kan i sin helhet beskrives ved å fortelle hvor mange kunder som er i systemet, inkludert både kø og server. Resultatene man kommer fram til ved hjelp Kø Server Gjennomsnittlig ankomstrate er λ kunder/s Gjennomsnittlig betjeningsrate er µ kunder/s Figur 2.5: M/M/1 system med 4 kunder. En kunde kan betjenes, mens tre venter på tur av køteorien kan brukes direkte for å finne køforsinkelsen for pakker i et nett. Den eneste endringen som må gjøres er å endre notasjonen kunder/s til bits/s. Først setter man funksjonen for sannsynlighetsfordelingen for pakkestørrelse, målt i bit til m e -m x der gjennomsnittet er på 1/m bits/pakke. Deretter introduserer man kapasiteten til kommunikasjonslinken i som C i bits/s. Produktet av m C i er da et mål for betjeningstid målt i pakker/s. Fra [Tan81] har vi at total ventetid i køen (T), inkludert betjeningstid, kan skrives som:

21 Bakgrunnsstoff 19 Der N er gjennomsnittlig antall kunder i køen, l er ankomstraten og r er trafikkintensiteten. Ligningen bygger på det faktum at siden gjennomsnittlig antall kunder i systemet til en hvert tid er N, har vi at. Vi har også gitt at: r = l / m. Ankomstraten for linken i er l i pakker/s. Ligningen over kan nå skrives som: T i =1/(m C i -l i ) for linken i. T i inkluderer både køtid og overføringstid Trafikktyper En trafikkmodell kan brukes på to forskjellige grunnleggende måter. Enten som en del av en analytisk modell eller for å drive en diskret hendelsessimulering. (Se avsnitt 2.6 for nærmere forklaring av begrepene.) Den mest vanlige modelleringskonteksten er bruk av en køer, der trafikk blir tilbudt en kø eller et nett av flere køer og varierende ytelsesmålinger beregnes [Mel94]. Ofte deles trafikktypene opp i tre hovedgrupper [Cin75]: Enkel trafikk - består av diskret fordelte pakkeankomster. Den kan matematisk beskrives som en punktprosess, bestående av en sekvens ankomstinstanser T 1, T 2,..., T n. Initielt må T 0 = 0. Sammensatt trafikk - består av sammensatte ankomster. Mer enn en enhet kan ankomme ved tiden T n. Diskret tid trafikk - svarer til tilfeller der tiden er oppdelt. Matematisk betyr dette at de tilfeldige variablene A n bare kan ha heltallsverdier. Det finnes en rekke forskjellige trafikkmodeller som kan brukes i en simulering. Vanlige trafikkmodeller er poisson- og bernoulli-prosesser, batchprosesser og markovmodulerte rateprosesser (mmrp). De to første er beskrevet nedenfor. Poisson prosesser kan karakteriseres som en fornyelsesprosess med interankomsttider A eksponensielt fordelt med rateparameter l : (-l t) P A p t =1 e

22 20 Kapittel 2 Poissonprosesser han noen viktige egenskaper [Mel94]: 1 En poissonprosess resulterer i en ny poissonprosess, der raten i den nye prosessen er summen av komponentenes rate. 2 Poissonprosessen er minneløs, noe som gjør den ideell til kømodeller. 3 Poissonprosesser kan også brukes i modeller der det er flere uavhengige trafikkstrømmer. Bernoulliprosesser er analogt med Poissonprosesser, men tiden er diskret fordelt. Her er sannsynligheten for en ankomst i en tidsluke p uavhengig av alle andre ankomster. Tiden mellom ankomstene er geometrisk fordelt med parameter p: P A=j=p(1-p) j der j er et positivt heltall. 2.3 Token bus Token bus kombinerer busstopologi med tilgangskontroll basert på bruk av token. Denne standarden (IEEE 802.4) benyttes først og fremst i industrielle nett, hvor det kreves en garantert levering innen en viss tid. Token bus er et kringkastingssystem. Dette innebærer at alle data sendes til alle nodene (se figur 2.6). MAC-laget gir sekvensiell tilgang til den delte bussen ved å gi kontrollen over mediet fra stasjon til stasjon. Token bus har flere funksjoner for å styre nodens tilgang til det fysiske mediet: Et token kontrollerer retten til tilgang til det fysiske mediet. Stasjonen som har tokenet har midlertidig kontroll over mediet. Tokenet sendes mellom stasjonene på mediet. Tokenet følger en logisk ring rundt mellom nodene, selv om topologien i nettet er en bus. Stabil tilstand i den logiske ringen er når data eller token sendes. Stasjonene har selv innebygde mekanismer for å vedlikeholde den logiske ringen. Disse innebygde mekanismene omfatter initialisering av ringen, sette opp ringen på nytt og legge til nye stasjoner i ringen, samt generelle vedlikeholdsrutiner for ringen. Token bus er ikke effektiv når antall stasjoner i ringen er høyt. Grunnen til

23 Bakgrunnsstoff 21 A C F Medium D E B H Figur 2.6: Logisk ring på fysisk bus. dette er at når det er mange noder i nettet vil tiden tokenet bruker rundt den logiske ringen (TRT, Token Rotation Time) øke og følgelig må en node vente lenger før den får tokenet tilbake og kan fortsette å sende data. Dette betyr at man bør begrense antallet stasjoner man kobler til nettet. Metoden er helt rettferdig, da alle stasjoner i ringen får sende like lenge. Ulempen med dette er at tid går tapt dersom en node ikke har data å sende Tilgang til overføringsmediet I et (Ethernet) basert nett, er at det ikke noen garantert maksimal ventetid før en stasjon slipper til overføringsmediet. I noen tilfeller, for eksempel i systemer som krever meget kort responstid, kan dette være meget viktig. En stasjon kan kollidere gang på gang, og derfor i teorien aldri få sendt noe. Dette problemet er løst i nett basert på såkalt «token passing». I slike nett reguleres adgangen til overføringsmediet ved hjelp av et token. Dette token sirkulerer mellom stasjonene, og den som har token får lov til å sende data. Enhver stasjon har en lengste tid den kan beholde tokenet, før den må sende det videre. Token bus er en forholdsvis kompleks protokoll og har en egen prioritetsmekanisme. Data som skal overføres deles inn i fire prioritetsklasser. Innenfor hver stasjon kan man tenke seg dette organisert som fire separate køer. Når stasjonen mottar tokenet, starter den med å sende ut rammer fra den køen som har høyest prioritet. Dette holder den på med inntil maksimaltiden for å beholde token overskrides. Dersom køen blir tom og stasjonen fortsatt har tid igjen, vil den fortsette med køen med nest høyeste prioritet og så videre. Først går token til prioritet 6, så til 4, så til 2 og til slutt til 0. En timer vil avbryte stasjonen etter en stund. Prioritet 6 kan benyttes til overføring av lyd Overføringsmedium og hastighet IEEE standarden definerer fire forskjellige typer overføring:

24 22 Kapittel 2 I enkelkanal fasekoherent FSK (phase-shift keying) benytter man frekvensmodulasjon med skifte mellom to frekvenser. For eksempel kan en høy frekvens bety 0, mens en lav frekvens kan bety 1. En variant av Manchesterkoding benyttes for å kode hvert enkelt bit. Overføringshastigheter er: 5 Mb/s (benytter frekvensene 5 MHz og 10 MHz) 10 Mb/s (benytter frekvensene 10 MHz og 20 MHz) Overføringsmediet er 75W koaksialkabel. I bredbånd benytter man en kombinasjon av amplitudemodulasjon og fasemodulasjon (AM/PSK). Overføringshastigheter er: 1 Mb/s, 5 Mb/s og 10 Mb/s. I fiberoptikk benytter man Manchesterkoding. Overføringshastighter er: 5 Mb/s, 10 Mb/s og 20 Mb/s. I enkelt kanal fasekontinuerlig FSK (phase-shift keying) benytter man en spesiell type frekvensmodulasjon. Manchesterkoding benyttes for å kode hvert enkelt bit før modulering. Overføringshastigheten er 1 Mb/s. Bærefrekvensen ligger rundt 5 MHz, og varierer fra 3.75 MHz til 6.25 MHz. Overføringsmediet er 75W koaksialkabel Administrasjon av den logiske ringen Det er nodene selv som har ansvaret for å administrare ringen. Mekanismen som gjør det mulig for nye stasjoner å bli med i ringen er basert på bruk av et såkalt responsvindu (et tidsintervall). To kontrollrammer, SOLICIT- SUCCESSOR-1 og SOLICIT-SUCCESSOR-2, benyttes for å åpne responsvinduet. Hver stasjon i den logiske ringen sender slike rammer med jevne mellomrom. SOLICIT-SUCCESSOR-1 sendes når etterfølgende stasjon i den logiske ringen har en lavere adresse enn stasjonen som sender rammen. Den stasjon som har det laveste nummer sender en SOLICIT-SUCCESSOR-2. Denne rammen etterfølges av to responsvinduer. I første responsvindu kan stasjoner med lavere adresse svare, mens andre responsvindu er for stasjoner med høyere adresse enn etterfølgeren. En stasjon som ønsker å komme inn i ringen, sender en SET-SUCCESSOR ramme i løpet av responsvinduet. Dersom flere melder seg vil det oppstå en kollisjon. Da vil den stasjon som sendte SOLICIT-SUCCESSOR rammen sende en RESOLVE-CONTENT- ION ramme. Stasjonene som ønsket å komme inn i ringen vil nå vente en tilfeldig tid før de svarer en gang til. Dette ligner på håndteringen av kollisjo-

25 Bakgrunnsstoff 23 ner i baserte nett. Dersom en stasjon ønsker å forlate den logiske ringen, sender den en SET- SUCCESSOR ramme til forløperen, det vil si til den stasjon den sist mottok en ramme fra. Meldingen inneholder adressen til etterfølgeren i datafeltet. Forløperen vil oppdatere sin adresse til neste stasjon, slik at stasjonen som ønsker å forlate nettet blir utelukket fra den logiske ringen. Når en stasjon blir slått på, venter den først for å se om det er noe trafikk i ringen. Hvis den ikke hører noe, så sender den en CLAIM-TOKEN ramme. Hvis ingen andre da ber om token, lager stasjonen sin egen ring med bare seg Figur 2.7: Stasjon 13 sender en SOLICIT-SUCCESSOR-1 melding Figur 2.8: Stasjon 16 svarer med en SET-SUCCESOR melding.

26 24 Kapittel 2 selv i. Fra tid til annen vil stasjonen nå sende SOLICIT-SUCCESSOR, noe som gir andre stasjoner mulighet til å komme inn i den logiske ringen. En stasjon som sender token videre til neste stasjon har et visst ansvar for oppfølging. Den må lytte om neste stasjon sender tokenet videre. Dersom den neste stasjonen ikke sender tokenet videre innen en viss tid, vil stasjonen som lytter prøve å sende tokenet på nytt. Hvis den neste stasjonenen heller ikke nå sender tokenet videre, antas det at den har forlatt ringen. Stasjonen som lytter sender da en WHO-FOLLOWS ramme. Den som etterfulgte den stasjon som forlot ringen, svarer med en SET-SUCCESSOR ramme. Hvis det ikke kommer noen SET-SUCCESSOR ramme, sender den WHO-FOLLOWS en gang til. Dersom det fortsatt ikke kommer noe svar, regner stasjonen med at den er alene på nettet og begynner å sende SOLICIT-SUCCESSOR-2 med jevne mellomrom. Dersom en stasjon ikke registrerer trafikk på nettet innenfor en viss tidsperiode, antar den at token er forsvunnet. Den sender da ut en CLAIM TOKEN ramme. Dette er en invitasjon til andre stasjoner om å sende tokenet ut på nettet. Dersom flere stasjoner prøver, oppstår det en kollisjon som blir håndtert på samme måte som når nye stasjoner vil inn i nettet. Dersom en stasjon som har fått token detekterer at en annen stasjon sender, vil den anta at den andre stasjonen har tokenet. I dette tilfelle forkaster stasjonen sitt eget token, og går over i mottagermodus. Dersom det skulle vise seg at det ikke er noen token som sirkulerer, vil dette bli ivaretatt som beskrevet over. 2.4 Ethernet Ethernet er det mest brukte lokalnett-teknologien de siste 20 årene [Dav96]. Den ble utviklet på midten av 70-tallet og er et eksempel på CSMA/CD (Carrier Sense, Multiple Access with Collision Detect). Ethernet ble utviklet fra ALOHA pakkeradio protokoll fra Universitetet på Hawaii. ALOHA sender en pakke ut i eteren og håper at det ikke blir noen kollisjon. Ethernet støtter i dag flere forskjellige hastigheter, 10 Mbs, 100 Mbs og 1 Gbs og er utviklet for mange forskjellige nettkonfigurasjoner og overføringsmedier. Med CSMA/CD prøver man å gi alle maskinene rettferdig tilgang til Ethernetkabelen Begrensninger Ethernet har en rekke begrensninger man må ta hensyn til. For at alle maskiner tilknyttet nettet skal vite når de kan sende sine pakker har man begrenset leng-

27 Bakgrunnsstoff 25 den på et segment til 500 meter. En minste tillatte pakke vil da fylle opp hele segmentet slik at maskiner som lytter vil oppdage at kabelen er opptatt. Man kan koble sammen flere slike segmenter med forsterkere. Ethernet har en begrensning på 1024 maskiner, men det anbefales ikke å koble sammen så mange. Denne teknologien kalles 10Base5. Andre teknologier er 10Base2 (tynt Ethernet) og 10BaseT (Twisted Pair). Disse teknologiene har igjen andre begrensninger. 10BaseT er kanskje den mest brukte, med en begrensning på 100 meter pr. segment. Her brukes også en stjernekonfigurasjon av nettet med en hub eller en svitsj i sentrum. Ethernet virker som en bus - bare en kan sende av gangen. På en intern databus er det logikk som sørger for at den som ønsker det får eksklusiv tilgang til bussen. I Ethernet er det ingen kontakt mellom maskinene annet enn Ethernetkabelen og en slik kontroll-logikk blir derfor umulig. En maskin må derfor: Lytte på nettet Hvis kabelen er ledig - sende ut pakken. Hvis mediet ikke er ledig fortsetter maskinen og lytte. Fortsette å lytte på nettet. Hvis maskinen hører det den sendte ut er alt ok. Hvis den hører noe annet, har det oppstått en kollisjon og maskinen må prøve å sende igjen senere. Dersom en kollisjon oppstår sender maskinen pakken på nytt etter en viss tid. Hvor lang tid den venter avhenger av hvor mange ganger pakken har kollidert. Etter første kollisjon venter den en tilfeldig tid mellom 0 og 51,2 m s. Hvis pakken kolliderer enda en gang venter maskinen en tilfeldig tid mellom 0 og 102,4 m s, og slik fortsetter det helt til pakken blir sendt. Maskinen gir vanligvis opp etter 16 forsøk. Dersom det er svært mange maskiner på et segment kan derfor dette skape problemer. Ethernet er 1-persistent, noe som betyr at når en pakke skal sendes, så sendes den med en gang kabelen er ledig. Andre netteknologier kan være p-persistent, noe som betyr at maskinen sender pakken med p prosents sannsynlighet når kabelen er ledig Hva skjer når kabellengden økes? Som antydet tidlgere vil det antakelig være kollisjonsdeteksjonen i standard Ethernet som vil by på problemer når vi øker kabellengden. Minimumspakkestørrelsen i Ethernet er definert slik at en pakke skal fylle opp hele Ethernetsegmentet. Som en følge av dette kan andre maskiner på nettet lytte for å finne ut om kabelen er ledig.

28 26 Kapittel 2 Hvis kabellengden økes (men pakkestørrelsen beholdes) vil ikke lenger en pakke klare å fylle opp hele segmentet og to maskiner i hver sin ende av segmentet kan begge tro at kabelen er ledig og begynne å sende. Hvis kabellengden blir stor (for eksempel 10 kilometer) vil en maskin kunne sende ut mange pakker uten å merke at de ikke kommer fram. 2.5 Token ring Token ring (IEEE 802.5) ble utviklet av IBM og er en pålitelig nettstandard som baserer seg på egenskaper fra flere andre standarder. Protokollen begytter token passing og nettet er koblet i stjernekonfigurasjon med en hub i sentrum. På denne måten kan man bygge opp en logisk ring. En fordel med Token ring er at den takler høy nettbelastning forholdsvis bra. Også denne standarden er utviklet med støtte for flere overføringshastigheter og flere overføringsmedier. Overføringshastighetene er 4 eller 16 Mbps. Både kobberkabel og fiber kan benyttes. En maskin kan bare sende data når den har tokenet. Når data skal sendes må derfor maskinen vente til tokenet kommer, fjerne dette fra ringen, sende data og sette tokenet ut på ringen igjen. Når tokenet er sendt videre går maskinen tilbake til lytteposisjon og venter på neste gang tokenet kommer. Token ring har mange likheter med Token bus. Den største forskjellen mellom de to standardene er den fysiske nettopologien. Begge bruker en logisk ring for å sende tokenet undt, men Token ring har en stjernekonfigurasjon isteden for en bus. Token ring støtter flere forskjellige prioritetsklasser. Prioriteten settes i pakkenes hode. Totalt 8 forskjellige klasser er tilgjengelig der klassen med høyest prioritet er reservert for vedlikehold av ringen. De fleste applikasjoner bruker den laveste prioritetsklassen. En av maskinene i ringen vil få et overordnet ansvar. Denne maskinen skal sørge for at token opprettes og skal sørge for at nye noder får komme med i ringen. Hvert syvende sekund sendes et nytt token fra denne overordnede noden. Dette pågår helt til alle nodene har identifisert seg og lært adressen til noden før og etter seg selv i ringen. Feilsituasjoner og annet vedlikehold foregår på samme måte som i Token bus. 2.6 FDDI FDDI (Fiber Distributed Data Interface) er en token passing basert nettstandard.

29 Bakgrunnsstoff Destinasjon 4 2 Kilde Token Data 4 2 Data Figur 2.9: Et FDDI-nettverk Som navnet skulle tilsi benyttes fiber i oppkoblingen. Spesielt for FDDI er at nettet tillater at flere noder sender samtidig. Siden nettet er bygd opp av fiber, kan man benytte 100Mbps for overføring. Selv om FDDI benytter en token passing metode for å sende data, er denne standarden på mange måter ulik Token ring. Som nevnt tillates det at mange rammer overføres samtidig. Grunnen til dette er at en node kan sende flere rammer tett etter hverandre uten å vente på at den første har gått rundt hele ringen. Når en node er ferdig å sende sendes tokenet videre til neste node. Denne noden kan umiddelbart begynne å sende data uten å vente på at rammene som forrige node sendte skal komme fram. Denne prosessen fortsetter og hele tiden vil det være rammer som overføres på ringen. På denne måten økes gjennomstrømningen i nettet betraktelig. FDDI ringen bygges opp med en fiber i hver retning. Dette gjør nettet enda mer pålitelig da feilsituasjoner lettere kan unngås. Dersom en av kablene går istykker kan den andre brukes. Dette gjøres ved at det automatisk opprettes en forbindelse mellom de to ringene før og etter bruddet. En slik sammenkobling tvinger alle pakkene til å gå dobbelst så langt siden de må gå både ring 1 og ring 2 for å nå destinasjonen. For å øke gjennomstrømningen ytterligere kan

30 28 Kapittel 2 man benytte begge ringene samtidig og sende data hver sin veg. En node kan være koblet til enten en av ringene eller til begge. FDDI har to forskjellige overføringsmodus, synkron og asynkron overføring. Asynkron trafikk sendes kun dersom nettet har ledig kapasitet. Synkron trafikk er trafikk der systemet kan garantere at rammene kommer fram innen en viss tid. For at dette skal fungere må parametre som synkron båndbredde, TTRT og mellomlagerets størrelse velges nøye. 2.7 DQDB DQDB (IEEE 802.6) er en forkortelse for Distributed Queue Dual Bus og er en nettopologi som ble utviklet for å kunne sende data over større avstander enn det et vanlig LAN kan dekke. Protokollen kan gi en båndbredde på inntil 155 Mbps. Siden DQDB er ment som en metode for å knytte flere lokalnett sammen, går protokollen under betegnelsen MAN (Metropolitian area network). Se figur Aksesskontroll Metoden som brukes til aksesskontroll er basert på en distribuert køalgoritme LAN LAN LAN LAN DQDB MAN LAN LAN LAN B-ISDN / ATM WAN Figur 2.10: Oppbygning av en DQDB-ring. Dersom B-ISDN enheten byttes ut med et vanlig LAN, vil man få et DQDB LAN isteden for et DQDB MAN. Oppbygningen ellers og protokollen er den samme i begge tilfeller.

31 Bakgrunnsstoff 29 (queued-packet, distributed-switch - QPSX). DQDB er en multippel kringkastingsbus, og har flere likhetstrekk med CSMA/CD. Aksessmetoden QPSX brukes for å overvinne svakhetene som man finner i Ethernet. For å kunne kringkaste data er bussen implementert med to ringer, men til forskjell fra et ringnettverk er ikke bussene koblet sammen i endene. Hver node er koblet til begge bussene. Hver bus er implementert som en punkt til punkt forbindelse, noe som gjør at for eksempel optisk fiber kan brukes til å bygge opp ringen. De to bussene sender data i hver sin retning. DQDB benytter tellere for å styre tilgangen til mediet. Metoden gir en utnyttelse på opp mot 90% av bussens totale kapasitet. I hver ende av bussene sitter det en rammegenerator som genererer kontrollrammene som går på bussen. Hver av nodene har en kø for hver av bussene og det er nodene selv som monitorerer og lagrer bussenes tilstand. Tilgang til bussen styres av nodene med tellere. DQDB kan overføre både synkron og asynkron trafikk. En prioriteringsmekanisme sørger for at synkron trafikk overføres med en høyere prioritet. Det er inntil fire prioritetsnivå som benyttes. Selv om protokollen gir en høy utnyttelse av overføringsmediet, er den ikke helt rettferdig ovenfor nodene som skal sende. Nodene som er nærmest bussenes ende får sende oftere enn noder som sitter midt på bussen [Nah96]. 2.8 Nettsimulering Nettsimulering ved hjelp av datamaskin er et nyttig verktøy når man ønsker å prøve ut og teste ytelse i eksisterende og nye systemer. Spesielt når man ønsker å se nærmere på komplekse nettarkitekturer og topologier er et simuleringsverktøy et nyttig hjelpemiddel. Ved hjelp av et simuleringsverktøy kan nettdesignere finne ut hvor godt et system vil fungere uten å investere mange penger i den nye teknologien. Nettdesignere kan teste sine nye oppkoblinger, få ytelsesmålinger og finne ut om det nye systemet vil fungere og hvor godt det vil fungere. Store summer kan spares både i investeringskostnader og i unødvendig eksperimentering i utviklingsfasen. Simulering gir en grunnleggende basis for å ta beslutninger. En avgjørelse kan gjøres på grunnlag av simuleringsresultatene. Flere faktorer spiller inn på sannsynligheten for å ta en riktig beslutning. Det er viktig at problemet er veldefinert og at det lar seg håndtere. En klar forståelse av problemet er essensielt før simulerings-modellen kan lages. Modellen må også beskrive problemet på riktig måte. En

32 30 Kapittel 2 programvaremodell vil ofte være syntaktisk riktig (for eksempel at den kompileres uten feilmeldinger), men likevel ikke simulere problemet på riktig måte. Alle resultater fra en unøyaktig modell vil føre til at beslutninger tas på feil grunnlag. Det er også viktig at modellen er riktig designet for å beskrive problemet på riktig måte. En simuleringsmodell produserer data. Alle disse dataene må manipuleres og tolkes av designeren. Riktigheten av tolkningen er avhengig av hvor brukbare dataene er og brukerens forståelse av statistiske metoder. Definere problemet To metoder er vanlig å bruke ved simulering og analyse av datanett; Matematisk analytisk og Diskret hendelses simulering (DES). Den første metoden er en matematisk teknikk som karakteriserer nettet ved Implementere modellen hjelp av et sett ligninger. Ligningene kan løses direkte eller via algoritmer. Modellen man bygger opp består kun av ligninger som Kjøre simuleringen beskriver hele nettet matematisk. Den andre metoden går ut på å assosiere hendelser i modellen til tid. Man kan ved hjelp av denne metoden bygge opp avanserte modeller som er svært lik et system i virkelighe- Analysere resultatene ten. Et eksempel på dette kan være forsinkelse fra ende til ende i et nett. Dersom det Ta avgjørelsene er ønskelig kan man vektlegge visse deler av systemet og kjøre simuleringer på disse, mens Figur 2.11: Gangen i en simulering. man kan abstrahere bort andre deler. En viktig egenskap ved DES-modeller er at tiden måles med klokker i simuleringen. Tidsenhetene kan endres avhengig av hendelsene som eksekveres. Alle tilstandene i DES-modellen lagres i et sett med tilstandsvariable. Hendelsene som eksekveres gjør at variablene endres. En hendelsesliste holder orden på hvilke hendelser som skal kjøres. Hendelsene i hendelseslisten kan tilordnes prioritet. Sett utenfra kan en DES-modell ses på som om man eksekverer samme sekvens om og om igjen. For hver interaksjon kjøres hendelsen som ligger først i hendelseslisten. Se flytdiagram for en DESmodell på figur Simuleringsverktøyet OpNet benytter denne metoden. Ulempen med å bruke en analytisk metode er at man må gjøre mange forenklinger i modellen og at man ikke kan simulere de dynamiske egenskapene til nettverket. Diskret hendelses simulering har fordeler som at det er Validering av modellen

33 Bakgrunnsstoff 31 Bruk hendelseslisten til å finne neste hendelse som skal prosesseres Sett simuleringsklokka til tiden for neste hendelse Oppdater tilstandsvariable ved hjelp av hendelsesrutiner i simuleringsprogrammet Oppdater hendelseslisten ved hjelp av hendelsesrutiner i simuleringsprogrammet Figur 2.12: Flytdiagram for en DES-modell [Mel94]. Figuren viser hendelsesforløpet til simuleringen. enklere å bygge opp modellene, og man kan bygge opp detaljerte modeller. Denne simuleringsmetoden krever imidlertid mye lengre prosseseringstid og ofte flere kjøringer av simuleringen OpNet OpNet (OPtimised Network Engineering Tool) er et program beregnet på si- Figur 2.13: Skjermbilde av OpNet Node-editor.

34 32 Kapittel 2 mulering av protokoller og datanett av alle typer. Programpakken inneholder en rekke verktøy som gjør det mulig å spesifisere nettmodeller meget nøyaktig, identifisere de elementene av modellen man synes er mest interessante, kjøre simuleringen og analysere de genererte dataene. OpNet benytter grafisk spesifikasjon av modellene, noe som gjør at brukeren mye lettere kan se helheten i systemet og få oversikt over nettet som det skal simuleres på. Programmet er hendelsesbasert, noe som gjør at man enkelt kan tilordne prioritet til de forskjellige delene av simuleringen. OpNet er også objektorientert. Hvert objekt har sitt sett av attributter. Det at man kan definere og tilordne verdier til disse attributtene selv, gjør at man kan lage fleksible modeller. Objektenes egenskaper kan endres ved hjelp av programmeringsspråket C. Modellene bygges opp hierarkisk. Det finnes tre separate domener for å beskrive nettet. Hvert nivå av hierarkiet beskriver forskjellige aspekter av den komplette modellen. Modeller laget på et nivå i modellen, brukes av modeller på høyere nivå i hierarkiet. Dette gjør at man kan lage generelle modeller som kan brukes i flere forskjellige simuleringer. Programpakken inneholder et bibliotek med ferdige nettkomponenter. Når man bygger opp modellen kan man benytte disse modellene som de er, eller modifisere dem. Modeller kan selvfølgelig også bygges helt fra grunnen av. En OpNet modell kan kompileres til et kjørbart program. Dette gir mulighet for å kjøre simuleringen uavhengig av OpNet. Det finnes også et innebygget debugging-verktøy. I OpNet er det integrert et analyseverktøy, noe som gjør at det blir enklere å finne fram i dataene som blir produsert i simuleringen. Som nevnt består OpNet av tre separate domener. Dette er: Nett-editorene hvor man kan definere eller endre topologien til nettet. Editorene har en grafisk representasjon av topologien. Man kan se om linkene mellom nodene er konsistente og man kan dele nettet inn i flere undernett. Simuleringsverktøyer som kan brukes til å definere og kjøre simuleringsmodeller laget med editorene i OpNet. Ved hjelp av netteditorene definerer man hvilke parametre som er viktig å få med i simuleringen. Det er også støtte for å lage animasjoner av resultatene. Analyseverktøy som kan brukes til å vise og sammenligne statistiske resultater. Det er tre måter dataene kan vises på: Grafisk, numerisk og fil for eksport. I den grafiske representasjonen kan man igjen velge mellom visningsalternativer som blant annet lineær framstilling og søyle.

35 Bakgrunnsstoff 33 Ved å bruke et simuleringsprogram som OpNet blir det lettere å evaluere konkurrerende design for nye systemer og arkitekturer. Man kan lett studere ytelse i eksisterende systemer under varierende last eller man kan utvikle og teste nye protokoller. I tillegg er programmet forholdsvis lett å sette seg inn i, man kan lett endre design av systemet og man kan teste nye løsninger uten at det koster noe annet enn arbeidstid og programlisenser.

36 34 Kapittel 2

37 KAPITTEL 3 Overordnet diskusjon I dette kapittelet blir det gitt en presentasjon av problemstilling og metode. Videre beskrives en mulig nettløsning, nemlig den løsningen som er implementert i modellen. Det gis også en detaljert beskrivelse av modellen, og hvordan denne er bygget opp. Til slutt i kapittelet kommer en presentasjon av noen typiske resultater fra simuleringen. 3.1 Problemstilling og metode Som nevnt innledningsvis må man i et passivt optisk nett måtte dele overføringsmediet mellom abonnentene som er tilknyttet nettet. For å få regulert og fordelt ressursene mellom abonnentene, må man finne en egnet arbitreringsprotokoll. Hvilken protokoll man velger, avhenger av hvilke egenskaper nettet skal ha. I denne oppgaven er simuleringsverktøyet OpNet benyttet for å implementere en modell som kunne beskrive nettet (se avsnitt 2.6.1). Målet har vært, ved hjelp av simuleringsresultatene, å finne ut hvor godt nettet vi ønsket å lage ville fungere under gitte forutsetninger og krav Problemstilling I dagens telenett er abonnentene knyttet til en telefonsentral med en elektrisk ledning. Mellom telefonsentralene er det imidlertid ofte brukt optiske fibre. Dersom man i framtiden også kan få optisk fiber fra sentralen til abonnenten, åpner dette for mange muligheter. Telefonsentralen kan da brukes til å formidle andre typer trafikk enn teletrafikk, for eksempel tilgang til Internett, kabel TV og video. Dersom man kan ha en optisk fiber helt fram til hver 35

38 36 Kapittel 3 abonnent, vil man sannsynligvis spare inn mye på driftsutgifter i nettet. Spesielt dersom nettet ikke er avhengig av elektrisk kraftmating. Det nærmeste man i dag kommer til en slik abonnementstilknytning er passive optiske nett (PON). I et passivt optisk nett er flere abonnenter knyttet til sentralen via en optisk fiber. Den optiske kabelen splittes ved hjelp av en passiv optisk effektdeler. For å få ned kostnadene ytterligere (også på abonnentsiden) ønsket vi å se nærmere på om det var mulig å benytte eksisterende protokoller og eksisterende billig hardware for å implementere et slikt nett. Protokoller som ble vurdert var Ethernet (IEEE 802.3), Token bus (IEEE 802.4), Token ring (IEEE 802.5), FDDI og DQDB (IEEE 802.6). Grunnen til at vi valgte å se nærmere på nettopp disse protokollene var at de alle hadde egenskaper vi ønsket å benytte oss av i modellen. Når det gjelder maskinvare ønsket vi å undersøke om det var mulig å benytte vanlige Ethernetkort. Dette er kort som finnes til alle maskintyper og operativsystem, og som er forholdsvis billige i innkjøp En mulig nettløsning Etter å ha jobbet med protokollene (nevnt over), bestemte vi oss for at vi ønsket å se nærmere på en kombinasjon av Ethernet og Token bus protokollene. Det var flere grunner til dette valget: 1 Det er svært få implementasjoner av DQDB, og følgelig vil maskinvare som støtter denne protokollen være dyr og vanskeligere å få tak i enn maskinvare til andre protokoller. 2 Målinger viser at DQDB ikke er helt rettferdig. De nodene som er i hver ende av de to bussene vil bli prioritert [Dav96]. Vi ønsket et nett der alle nodene har lik tilgang til overføringsmediet, med unntak av sentralen. 3 Nettkort som støtter ethernetprotokollen er lette å få tak i og de er billige i innkjøp. Det finnes også drivere for de fleste operativsystemer, og kort for de fleste maskintyper. 4 Token bus er et kollisjonsfritt nett, noe som var en viktig egenskap vi ønsket at nettverket skulle ha. Grunnen til at vi ønsket denne egenskapen var at man da lettere kan sende data over lange avstander. 5 Hovedgrunnen for at Token ring eller FDDI ikke ble valgt er nettkonfigurasjonen til de to standardene. FDDI er koblet i ring, og er derfor ikke aktuell for vårt bruk. Token ring er koblet i en fysisk

39 Overordnet diskusjon 37 stjernekonfigurasjon og kunne vært brukt. Vi valgte imidlertid Token bus, men har benyttet egenskaper fra både FDDI og Token ring i vårt nett. En del ideer til implemetasjonen er hentet fra Token ring og FDDI. Ethernet har som kjent begrensninger på hvor langt et segment kan være (se avsnitt 2.4). Vi ønsket likevel å benytte Ethernetkort, og trengte derfor en metode å styre nodens tilgang til overføringsmediet. Et nettkort for Ethernet vil sende ut data på nettverket mye oftere enn brukeren sender data. Ethernet protokollen gjør dette blant annet for å svare på forespørsler fra nettverket (ARP). Vi måtte derfor finne en metode for å kunne styre en nodes tilgang til overføringsmediet. Dette må gjøres dersom nettet skal bli kollisjonsfritt. Vi kan ikke tillate at noen pakker sendes fra noder som ikke har tokenet. For å få mer kontroll over når noden sender data, ønsket vi å implementere en form for Token bus protokoll over ethernet i protokollhiearkiet. På denne måten vil en node kun få sende data når den har tokenet. Samtidig får man også benyttet billig maskinvare i form at et Ethernetkort. Siden Ethernetprotokollen er implementert i ASIC på nettkortet betyr det at man i virkeligheten må gjøre en del tilpasninger i protokollen. I min simuleringsmodell har jeg sett bort fra en del av de fysiske begrensmingene, og har gjort noen forenklinger. Beskrivelse av disse forenklingene er gitt i avsnitt 3.2. Protokollstakken som er benyttet i modellen er vist i figur Modellen Applikasjon TCP/IP Token bus Ethernet Overføringsmedium (PON) Figur 3.1: De forskjellige lagene i protokollstakken. Siden et av målene våre var at oppkoblingen skulle benyttes til optisk abonnementtilknytning, ønsket vi å se hvordan nettet fungerte når data ble sendt over lange avstander. Vi ønsket å sende data over flere kilometer, det vil si flere ganger over den maksimale lengden på et vanlig ethernetsegment. En typisk oppkobling vil være som skissert på figur 3.2. Her er den passive optiske splitten plassert nærmest abonnentene, da dette vil redusere lengden på den optiske kabelen. I tillegg til å sende data over lange avstander, ønsker vi å se på et scenario der

40 38 Kapittel 3 Node 1 2 km Sentral 10 km Splitt 2 km Node 2 2 km Node 3 Splitt Figur 3.2: Skisse av oppkoblingen av nettverket. Splitten sender alt til alle. en abonnent er knyttet til Internett via det optiske nettverket. Målinger har vist at for en abonnent som surfer på Internett hjemmefra vil mesteparten av trafikken gå utenfra og inn. Hver gang en bruker henter opp en side sendes en forespørsel, mens denne forespørselen fører til at flere filer sendes til mottakeren. Forespørslene er dessuten mye mindre enn de dataene som sendes i retur. Dette vil for modellens del si at det er trafikk fra sentralen til nodene som er mest hyppig. I modellen er det nodene som genererer trafikk, mens sentralen vil svare på alle forespørsler som kommer fra de tre nodene. Når sentralen mottar en pakke, vil den generere nye pakker og sende dem til den noden som sendte forespørselen. Pakkene som sentralen skal sende legges i sentralens utkø og sendes når sentralen er i aktiv tilstand. Dette vil føre til at sentralen trenger mer tid til å sende sine pakker. I modellen har sentralen tokenet dobbelt så lenge som en node. Grunnen til dette er at sentralen alltid vil få lengre utkø enn nodene, da det genereres flere pakker i retur for hver forespørsel. 3.2 Forenklinger i modellen Som nevnt tidligere er det lagt inn en del forenklinger i modellen. Dette er gjort for å gjøre simuleringsmodellen enklere å implemente, samt at det heller ikke var ønskelig å ta med alle parametre i modellen. Under er de antakelsene vi har gjort listet opp og forklart. Nettet er kollisjonsfritt - Når denne antakelsen er riktig kan man i modellen

41 Overordnet diskusjon 39 kun konsentrere seg om den delen som styrer tokenet. Antakelsen forutsetter at noden ikke sender ut data til andre tidspunkt enn når den har tokenet. Nettkortet kan heller ikke sende ARP-meldinger eller andre former for kontrollpakker så lenge noden ikke har tokenet. I modellen kan dette gjøres ved kun å implementere styring av token i noden. Dersom nodene (og sentralen) bare sender data når den er i den aktive tilstanden og har tokenet, vil aldri to noder sende data samtidig og følgelig vil det heller ikke oppstå kollisjoner. På denne måten kan man også sende data over lenge avstander. Man trenger heller ikke å tenke på hvor lang en pakke må være, slik som i Ethernet. En node kan sende ut pakker fortløpende så lenge den har tokenet, fordi den vet at ingen andre noder sender samtidig. Begrensningen på lengde i Ethernet kommer av nettopp det faktum at en pakke må fylle hele mediet. Oversending av tokenet - For å overføre mest mulig data på den tiden en node har tokenet, vil det være ønskelig å sende tokenet videre sammen med data. Dette kan gjøres ved at man definerer et felt i hver pakke som forteller om pakken inneholder tokenet eller ikke. Alle pakker som mottas i en node må derfor sjekkes. Det å sende tokenet med siste datapakke kalles «piggy backing». Mekanismen foregår på den måten at når noden som sender data ikke lenger kan sende (timeren går ut), tas en siste pakke fra utkøen, tokenverdien settes, og pakken overføres. Noden som har sendt tokenet fra seg slutter å sende data og går ut av den aktive tilstanden. Det at alle pakker må sjekkes, vil ikke føre til at nodene blir tregere eller at pakkene kommer senere fram. Grunnen til dette er at noden ser om tokenverdien er satt samtidig som den finner ut om pakken har kommet fram til riktig mottaker. Hver pakke aksesseres altså kun en gang i hver node, noe som må gjøres uansett om pakken skal til denne noden eller ikke. En slik metode vil kun fungere i et kringkastingsnett, der alle hører alt. Det er altså ikke (nødvendigvis) mottaker av siste pakke som får tokenet neste gang. Benytte splitt som ikke svekker signalet - I en passiv optisk splitt deles innsignalet i like deler mellom utgangene. Dette betyr at i en splitt med fire innganger og fire utganger vil signalstyrken reduseres til 1/4 av det opprinnelige etter splittingen. I modellen kan man se bort fra denne reduksjonen i signalet, da signaltap ikke vil innvirke i betydelig grad på så korte avstander som benyttes i modellen. Splitten i modellen vi derfor sende det samme signalet som kom inn ut på alle utganger. Den vi også sende tilbake til noden som sendte pakken. En slik implementasjon, der alle hører alt, vil

42 40 Kapittel 3 være lik som en oppkobling der Ethernet-kort er benyttet. Stjernenett og logisk ring - Modellen bygges opp slik som oppkoblingen av nettet skal være, det vil si med en logisk ring og maskinene koblet i stjernekonfigurasjon med en splitt. Grunnen til at dette valget er tatt er at man ønsker å simulere med bruk av lange kabellengder, og med en slik konfigurasjon kan man bruke de samme avstandene som brukes i den fysiske oppkoblingen. Et annet viktig moment er at nodene skal kunne sende direkte mellom hverandre, uten at all trafikk går via sentralen. Avstanden vil derfor bli mye lenger hvis man bruker en fysisk ring isteden for en logisk. Se figur 3.2. En slik oppkobling er dessuten den mest realistiske i forhold til tanken om at folk skal ha fiber inn i stua. Nettet blir mer oversiktelig og lettere og vedlikeholde og utvide med en slik konfigurasjon. Oppsetting og vedlikehold av ringen - I simuleringen vil den logiske ringen hele tiden være oppe. Hva som skjer når en node settes inn eller tas ut av ringen og hvor lang tid ringen bruker på å initialisere seg igjen er ikke tatt med i modellen. Vi ønsker kun å se på effektiviteten til oppkoblingen når alt fungerer som det skal. Siden nettet er kollisjonsfritt, kan man gå ut fra at en feilsituasjon sjelden inntreffer. Det er heller ikke nødvendig med feilsjekking. Grunnen til at man kan gjøre en så stor endring er antakelsen om at modellen skal være kollisjonsfri. Nodene vil derfor alltid få tokenet i rett tid og kollisjoner vil ikke forekomme. Dersom en timeout likevel skulle inntreffe, startes timeren i noden på nytt. Når simuleringen starter opp, vil en av nodene initielt ha tokenet og simuleringen vil starte. Grunnen til at vi har valgt å gjøre det på denne måten er at vi kun ønsker å se på hvordan nettverket fungerer når alle nodene er koblet opp. I modellen er det ikke implementert støtte for feilhåndtering. Grunnen til dette er at den logiske ringen er oppe under hele simuleringen. Siden vi heller ikke ønsker å se på tilfeller der noder går inn og ut av ringen, vil man her ikke trenge slik funksjonalitet i modellen. I en virkelig oppkobling vil man trenge funksjonalitet for å sette noder inn i ringen og ta dem ut, samt å kunne håndtere feilsituasjoner. Ventetid på tokenet - I Token bus protokollen skal noden vente på tokenet i en maksimumstid, kalt TTRT (target token rotation time). Dersom noden ikke har fått tokenet innen denne tiden er det noe feil i systemet. Generelt

43 Overordnet diskusjon 41 vil tiden det tar før en node får tokenet tilbake være gitt ved [Dav96]: THT + TRT = Totaltid Der THT (token holding time) er tiden noden får lov til å beholde tokenet og TRT (token rotation time) er tiden tokenet bruker rundt ringen. Man ser at: TRT Aktive noder THT + Tid i ringen Dersom en node ikke har data å sende skal den sende tokenet videre, før timeren går ut. Dette vil (sammen med «piggy backing») øke gjennomstrømningen i nettet, siden man på denne måten sikrer at data sendes hele tiden. Ruting i ringen - Hver node inneholder en fast rutingtabell som forteller hvilken node som skal ha tokenet neste gang. Tabellen kan kodes direkte i modellen, da det ikke skal være noen form for vedlikehold av ringen. Noder skal ikke settes inn og heller ikke tas ut. I denne modellen sender sentralen tokenet videre til node 1, node 1 til node 2, node 2 til node 3 og node 3 til sentralen. I en virkelig oppkobling må rutingsfunksjonaliteten implementeres i protokollen. På denne måten kan noder settes inn og tas ut av ringen, mens runtinginformasjonen er oppdatert hele tiden. Dette kan for eksempel gjøres som beskrevet for Token bus Egenskaper for nodene Vi har valgt å kun simulere på nettverket mens alle nodene er oppe. Dette innebærer at alle nodene vil være med i ringen hele tiden. Når simuleringen starter vil en av nodene initialiseres til å ha tokenet, og det vil da være denne noden som begynner å sende. I et vanlig Token bus nett gjøres dette ved at nodene med jevne mellomrom spør om nye noder skal inn i ringen. I et Token bus nett må nodene ha en timer som starter når tokenet er sendt fra noden. Dersom timeren går ut før noden igjen får tokenet er ikke noden med i ringen lenger. Noden må da svare på forespørsel, og si ifra at den vil inn i ringen igjen. Når en bruker logger seg ut på vanlig måte skal noden gi beskjed om at den

44 42 Kapittel 3 ikke lenger vil være med i ringen. Listen med hvem som skal ha tokenet blir oppdatert (se avsnitt 2.3). Dersom en node skrues av uten at bruker logger seg ut (for eksempel ved strømbrudd) er det den neste noden i ringen som timer ut fordi den ikke får tokenet. Tokenet blir borte og nytt token må opprettes. Slike mekanismer er ikke nødvendig i modellen, da alle nodene er med fra starten og ingen av dem vil falle ut under simuleringen. Den eneste funksjonaliteten som trengs her er styring av tokenet og sending / mottak av data Egenskaper for sentralen I et Token bus nett er det et kollektivt ansvar å holde den logiske ringen ved like. Dette gjøres ved at alle noder til enhver tid vet hvem som er sin forgjenger og sin etterkommer. Nodene må med jevne mellomrom spørre om nye noder vil være med i ringen. I et datanett med fast oppsatt ring, slik som i denne simuleringen, kan man se bort fra en slik mekanisme. Token bus protokollen inneholder også rutiner for å behandle kollisjoner som kan oppstå ved innsettingen av nye noder. Dette er også en mekanisme vi kan se bort fra i simuleringen, siden ringen er fast oppsatt. Sentralen er i utgangspunktet veldig lik nodene. Forskjellen ligger i at sentralen ikke genererer pakker selv, men genererer pakker ut fra forespørsler som kommer inn Spesifikasjon av den passive effektdeleren Fordeleren må sende alt som kommer inn ut på alle utkanaler. Det er på denne måten den optiske splitten fungerer i virkeligheten. En forutseting for at systemet skal virke er at alle hører alt, slik som i Ethernet. Splitten skal ikke inneholde noe logikk eller elektronikk. Grunnen til dette er at den skal kunne plasseres på steder der det ikke er strøm. Den skal bare sende alle signaler den får inn ut igjen. I en passiv optisk effektdeler deles innsignalet likt mellom alle utgangene. Dersom en effektdeler har for eksempel fire utganger vil signalet deles opp og utsignalene vil være svakere enn innsignalet. I modellen har vi valgt å se bort fra denne egenskapen, og sender like sterkt signal ut som vi får inn. 3.3 Oppbygning av simuleringsmodellen Når man skal bygge opp en modell av et datanett og kjøre simuleringer på denne modellen, er det ikke alltid alle parametre det er like interessant å se på. Det vil da være naturlig å gjøre en del forenklinger i modellen, noe som kan

45 Overordnet diskusjon 43 Start Idle Inndata Token Utdata Inndata Nei Tom kø? Ja Idle Sett timer Token Aktiv Idle Utdata Timeout Utdata Token Nei Tom kø? Ja Idle Aktiv Figur 3.3: Tilstandsdiagram for aksessprotokollen i nodene.

46 44 Kapittel 3 føre til at modellen kan bli lettere å implementere. Det er imidlertid viktig at man ikke legger inn så mange forenklinger at simuleringen gir feil eller misvisende resultat. For å sikre seg mot dette er det viktig at modellen er nøye gjennomarbeidet og at resultatene er verifisert. Denne modellen består av tre forskjellige komponenttyper. Dette er nodene, som representerer brukerenes arbeidsstasjoner, sentralen, som representerer en gateway til Internett og en passiv optisk effektdeler. Nodene og sentralen er bygget opp på samme måte, kun med små forskjeller. Den største forskjellen mellom nodene og sentralen er generering av trafikk. Generatoren i hver node kommuniserer med sin generator i sentralen, og på denne måten vil sentralen svare på forespørsler som en node sender. En annen forskjell er tiden en node kan beholde tokenet. Siden sentralen skal sende mer data enn en node må den også kunne beholde tokenet lenger. Simuleringsprogrammet brukes for å finne ut om det er en av nodene eller sentralen som er aktiv. Den optiske splitten er det ikke laget noe tilstandsdiagram for, da denne kun sender all trafikk som kommer inn ut på alle utganger. Ser man nærmere på en node er det tre hendelser som kan inntreffe når noden ikke er aktiv (når den er i «Idle»). Det er kun de to siste som gjelder for sentralen, men selve oppbygningen er likevel den samme. De tre hendelsene er (se figur 3.3): Data kan komme fra trafikkgeneratoren (Utdata). Noden kan få tokenet (Token). Data kommer inn til noden fra nettverket (Inndata). Dersom det kommer data fra trafikkgeneratoren skal denne legges bakerst i utkøen, uavhengig om noden har tokenet eller ikke. På denne måten vil alle data bli sendt med lik prioritet fra noden. Når en node skal sende tokenet, vil dette sendes umiddelbart selv om køen er lang. Det at noden kan få tokenet og bli aktiv er et spesialtilfelle av den siste hendelsen. Når det kommer data inn fra nettet, sjekkes det først om pakken har kommet fram til riktig mottaker. Dersom pakken er i riktig node sjekkes det om pakken inneholder tokenet. Hvis pakken ikke inneholder et token blir ende til ende forsinkelsen målt og pakken kastet. Dersom pakken inneholder tokenet, blir ende til ende forsinkelsen målt, før noden går inn i en aktiv tilstand. Først startes en timer, som bestemmer hvor lenge noden kan ha tokenet

47 Overordnet diskusjon 45 (token holding time, THT). Etter at denne er startet begynner noden å sende data. Pakken som er først i utkøen sendes. Dersom køen er tom, lages det en ny pakke og tokenet sendes videre. Deretter fortsetter noden å sende data helt til timeren går ut eller køen blir tom. Når en av disse hendelsene inntreffer skal tokenet sendes videre umiddelbart. Dersom tokenet sendes videre på grunn av at timeren har gått ut, benyttes en vanlig pakke for å sende tokenet. Noden tar da første pakke i utkøen og plasserer tokenet i denne. Dette kalles for «piggy-backing». Ved å sende tokenet videre på denne måten kan man øke gjennomstrømningen i nettet, spesielt ved korte THT-tider. Dersom tokenet sendes videre fordi køen er tom, lages det en ny tom pakke som kun inneholder tokenet og mottakeradressen. I sentralen skjer det hele på en litt annen måte. Det er her kun de to siste hendelsene som kan inntreffe. Når sentralen mottar en pakke ser den først om pakken er kommet til riktig sted. Dersom pakken virkelig var adressert til sentralen sjekkes det om den inneholder tokenet. Hvis sentralen har fått tokenet, startes sendingen umiddelbart. Pakken som kom inn kastes ikke, men brukes for å starte generering av nye pakker som legges bakerst i utkøen. Disse pakkene er alle adressert til avsender av pakken som kommer inn. Dersom pakken som kom inn ikke inneholder tokenet genereres nye pakker som legges i utkøen. Figur 3.3 viser tilstandsdiagrammet for modellen skrevet i SDL [Roc85]. På a) T2 t T1 b) t T3 T4 Figur 3.4: a) Viser pakkene som kommer inn til noden. b) Viser pakkene som går ut fra noden.

48 46 Kapittel 3 Les Svar Lest ferdig timer Start Send foresp. Vent på svar Svar Sett timer lest ferdig Figur 3.5: Viser tilstandsdiagrammet for nodenes trafikkgeneratorer. tilstandsdiagrammet er alle forenklingene tatt med Generering av trafikk Trafikk til nettet genereres både i nodene og i sentralen. Nodene representerer en bruker i nettet, mens sentralen representerer en gateway til Internett. Det vil derfor være nodene som er aktive og vil starte kommunikasjoen. Trafikkgenereringen vil bestå av to prosesser som kommuniserer. Det er en prosess i hver node som kommuniserer med hver sin prosess i sentralen. Prosessen i noden vil være den aktive, mens den korresponderende prosessen i sentralen venter på pakker fra noden. Figur 3.4 viser hvordan de to prosessene jobber mot hverandre. Den første pakken som sendes er altså en forespørsel fra en node. T3 vil da beskrive tiden denne pakken bruker til den kommer fram til sentralen, inkludert køtid i noden. Når pakken har kommet fram til sentralen

49 Overordnet diskusjon 47 Start Vent Forespørsel Sett timer 1 Sett timer 2 Svar A Aktiv Timer 1 Timer 2 Forespørsel Send svar Ferdig Svar Svar ferdig A Figur 3.6: Viser tilstandsdiagram for sentralens trafikkgenerator. starter generering av svarpakker som skal sendes til noden. T1 betegner tiden sentralen skal generere pakker, mens T2 betegner tiden mellom hver pakke. T4 beskriver tiden noden bruker på å få data tilbake og behandle disse, før en ny forespørsel sendes ut. T1 og T2 er eksponensielt fordelt, mens T3 avhenger av trafikken på nettet og hvor lenge pakkene blir liggende i kø. Figur 3.5 viser trafikkgeneratoren som er benyttet i nodene. Nodene starter med å sende en forespørsel og går deretter over i en ventetilstand. Når svar kommer tilbake settes det en timer og man går inn i en ny tilstand «Les». Her

50 48 Kapittel 3 er det to muligheter; Flere svar kommer inn fra nettet eller at noden blir ferdig med å lese. I det første tilfellet vil noden gå inn i tilstand «Les» en gang til og fortsette der den ble avbrutt. Dersom signalet «Lest ferdig» slår til vil noden sende en forespørsel til sentralen og deretter gå inn i en ventetilstand. Denne ventetilstanden betegnes av T3 i figur 3.4. Pakken som genereres til sentralen vil legges bakerst i nodens utkø, og sendes så fort noden kommer inn i aktiv tilstand. Når pakken er sendt vil det komme svar tilbake fra sentralen i form av en burst med pakker. Når den første ankommer settes en timer, T4, og noden går tilbake til tilstanden «Les» for å behandle innkomne data. Tilstandsdiagram for sentralens trafikkgenerator er vist i figur 3.6. Initielt er sentralens generator i en ventetilstand. Her vil den være helt til den mottar en forespørsel fra noden, altså etter at T3 er utløpt. Sentralen setter to timere, T1 og T2. Deretter sendes den første pakken i retur. Nå er det tre tilfeller om kan inntreffe. Enten kan en av timerene gå av, eller så kan det komme en ny forespørsel. Dersom T1 går av, indikerer dette at databursten er ferdig og at sentralen må avslutte genereringen. Generatoren går deretter tilbake til ventetilstanden. Dersom T2 går av, indikerer dette at en ny svarpakke skal genereres og generatoren går tilbake til den aktive tilstanden. Dersom det kommer en ny forespørsel fra noden må timerene stoppes og genereringen avsluttes. Generatoren går så tilbake og setter timerene T1 og T2 en gang til. Alle pakker som genereres legges bakerst i sentralens utkø og sendes neste gang sentralen er i aktiv tilstand og kan sende data. 3.4 Modellparametre og typiske resultater Etter at modellen var ferdig bygget opp ble det kjørt et sett med simuleringer der alle parametre var satt til en standard verdi. Parametrene som kan endres i modellen er som følger; avstanden mellom nodene, tiden en node får lov til å sende (THT), tilgjengelig båndbredde og ruting i rigen. For å øke antall noder i modellen kreves det at modellen utvides noe. Grunnen til dette er at OpNet representerer modellen grafisk og genererer kode ut fra den grafiske framstillingen. Siden hver node er et objekt i denne grafiske framstillingen, lar det seg ikke gjøre å ha antall noder som en parameter Konfigurasjon I utgangspuktet er den totale lengden rundt hele den logiske ringen på 32 kilometer. Dette innebærer en avstand på 10 kilometer fra sentral til splitt og

51 Overordnet diskusjon 49 en avstand på 2 kilometer fra splitten til en node. (Se figur 3.2) Modellen er bygget opp med en sentral og kun tre noder. Tiden en node kan få lov til å sende data er satt til 0,0075 sekunder for en node og 0,015 sekund for sentralen. Grunnen til dette er at det er sentralen som har størst trafikk og den trenger derfor en form for prioritet for å kunne gjøre det den skal. Modellen benytter token passing der tabellen over hvor tokenet skal sendes er fastsatt på forhånd. Alle de optiske linkene i datanettet og nettkortene har en overføringskapasitet på 10 Mbps. Simuleringen ble kjørt for flere forskjellige båndbredder for å se hvordan nettet endret karakteristikk Resultater Simuleringen ble kjørt over en periode på 1800 sekunder i simuleringstid. Videre ble det simulert for 8 forskjellige båndbredder, 3 forskjellige trafikk belastninger og 8 forskjellige frøverdier. Tilsammen 196 runder for hvert simuleringsscenario. Med trafikkbelastning menes tiden mellom hver gang en node genererer en ny pakke («Lest ferdig» timer i figur 3.5). Dersom denne tiden er kort, vil det genereres mere trafikk enn om tiden er lang. For hver av simuleringsrundene vil resultatene presenteres som tre plott. I plottene representerer grafen merket «Lav trafikk» at tiden mellom hver pakke er lang (Ti- Figur 3.7: Midlere ende til ende forsinkelse (sek) plottet som funksjon av kapasitet pr node (Mbps) for standardsimuleringen. Parametre for simuleringen er: overføringslengde: 10 kilometer fra splitt til sentral og 2 kilometer fra node til sentral, antall noder: 4, tht-tid: 0,0075 sekunder for nodene og 0,015 sekunder for sentralen.

52 50 Kapittel 3 mer 2 i figur 3.6). «Høy trafikk» representerer plottet der denne timeren er kort. Pakkestørrelsen i alle simuleringene er satt til 1500 byte. Siden modellen bruker «piggy-backing» vil også de aller fleste tokenpakkene som sendes også være på 1500 byte. Vi har valgt å benytte en konstant pakkestørrelse da dette er realistisk i forhold til den trafikkmodellen vi ønsker å se på. Pakker som kun inneholder tokenet er ikke tatt med i plottene. Det første plottet (figur 3.7) viser midlere ende til ende forsinkelse for alle datapakker målt i sekunder plottet som funksjon av tilgjengelig kapasitet pr node. Verdiene for de tre trafikkbelastningene er plottet i samme diagram for lettere å kunne sammenligne resultatene. Vi ser at forsinkelsen øker når båndbredden minsker. Dersom tiden mellom hver gang en node lager en pakke er kort vil også ende til ende forsinkelsen gå oppover. I det andre plottet (figur 3.8) er antall pakker på linken pr sekund plottet som funksjon av kapasitet pr node (Mbps). Disse resultatene er tatt med siden modellen genererer trafikk på en slik måte at nodene og sentralen kommuniserer. Sentralen svarer på forespørsler (pakker) som en node sender og dersom en pakke bruker lang tid på å komme fram vil færre pakker bli generert. Av plottet ser man at det blir sendt flere pakker når tiden mellom hver gang en node lager en pakke er lang.

53 Overordnet diskusjon 51 I det tredje plottet (figur 3.9) er den prosentvise utnyttelsen av linken plottet som funksjon av kapasitet pr node. Her ser man at linken blir best utnyttet når tiden mellom hver pakke som genereres er kort og tilgjengelig båndbredde er lav. Dersom tilgjengelig båndbredde er høy, blir forskjellen i linkutnyttelsen lavere mellom høy og lav trafikkbelastning. I figurene 3.10 til 3.13 er pdf-funksjonen for fire forskjellige båndbredder presentert. Av plottene ser man at når båndbredden er lav (figur 3.10) vil ende til ende forsinkelsen øke. Når båndbredden øker synker ende til ende forsinkelsen og sannsynligheten for en lav verdi er høyere (pdf-funksjonen blir smalere). Alle pdf-plottene er for simuleringsrunden med høyest trafikk Diskusjon Resultatene fra første simuleringsrunde der standardparametrene er brukt er presentert i figur 3.7, 3.8 og 3.9. For lettere å kunne sammenligne resultatene fra de forskjellige scenariene vi ønsket å se på, vil resultatene fra disse bli presentert på samme måte (se kapittel 4). Ser man først på resultatene i figur 3.7 ser man at ende til ende forsinkelsen øker når tilgjengelig båndbredde for hver node synker. Dette er ikke så veldig overraskende, da pakkene må ligge lenger i kø når nodene ikke får sendt like

54 52 Kapittel 3 Figur 3.10: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i standardsimuleringen. Tilgjengelig båndbredde er 0,025Mbps pr node, ellers er parametrene som i figur 3.7. Forsinkelsen på x-aksen er målt i sekunder. Figur 3.11: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i standardsimuleringen. Tilgjengelig båndbredde er 0,075Mbps pr node, ellers er parametrene som i figur 3.7. Forsinkelsen på x-aksen er målt i sekunder. mye data på den tiden den har tokenet. Man ser også at det kun er liten forskjell på de tre trafikkbelastningene når tilgjengelig båndbredde er høy. Det ser også ut til at forsinkelsen flater ut når båndbredden blir høy. For den høyeste båndbredden som er tatt med i simuleringen varierer verdiene fra

55 Overordnet diskusjon 53 Figur 3.12: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i standardsimuleringen. Tilgjengelig båndbredde er 0,250Mbps pr node, ellers er parametrene som i figur 3.7. Forsinkelsen på x-aksen er målt i sekunder. Figur 3.13: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i standardsimuleringen. Tilgjengelig båndbredde er 2,50Mbps pr node, ellers er parametrene som i figur 3.7. Forsinkelsen på x-aksen er målt i sekunder. 0,021 til 0,023 sekunder. Siden forsinkelsen i overføringsmediet kun står for 0,06ms (forsinkelse i 12 kilometer fiber) ser vi at det er forsinkelse i endesystemene som spiller inn. Grunnen til at forsinkelsen ikke blir lavere er at nodene ikke kan sende data når de ikke har tokenet. Pakker som skal ut legges

56 54 Kapittel 3 i en utkø og sendes så snart noden får tokenet. Dersom en node ikke har data å sende vil tokenet sendes videre til neste node umiddelbart. Av resultatene her ser man at denne teknikken gir systemet en forbedring. Dersom hver node hadde holdt tokenet helt til timeren gikk ut ville forsinkelsen blitt på minimum 0,03 sekunder for denne simuleringsrunden. Når antallet noder økes ville da forsinkelsen blitt enda større. Får å fjerne noe av forsinkelsen i systemet kan man tenke seg å bruke en kortere tht-verdi (tiden en node kan ha tokenet) i noder og i sentral for på denne måten å minske tiden mellom hver gang en node kan sende. Målinger har imidlertid vist at store deler av de dataene som sendes blir sendt i pakker når tokenet overføres. I et senere scenario vil vi se hva som skjer når tht-tiden minskes. Hvordan dette vil påvirke systemet og de andre komponentene i det, er diskutert i kapittel 4.3. I figur 3.8 ser man at grafene stiger når tilgjengelig båndbredde øker. Når tilgjengelig båndbredde er lav stiger grafene sakte, mens de stiger fortere når tilgjengelig båndbredde blir høy. Ved første øyekast skulle man tro at systemet ikke klarer å generere mer trafikk ved disse båndbreddeverdiene, men fra figur 3.9 ser man at nettet ikke er i metning. Forklaringen kan ligge i måten modellen genererer trafikk på. Når trafikken genereres på en slik måte vil mengde generert trafikk avhenge av kølengder og forsinkelse i nettet. Figur 3.9 viser den prosentvise utnyttelsen av linken. Vi ser at når man har høy båndbredde tilgjengelig er utnyttelsen av linken lav. Dette kan tyde på at nodene har for lite data å sende i forhold til den høye båndbredden. På den annen side har nodene kun en begrenset tid i sende data på, slik at man her vil nå et maksimum av hva en node kan klare å sende. Dersom nodene hadde generert mer trafikk hadde man muligens oppnådd høyere verdier her, men det kunne også ført til at nodene bare fikk lengre køer noe som igjen hadde ført til at målingene for ende til ende forsinkelsen hadde økt. Dette henger imidlertid nøye sammen med tht-tiden og antall noder i systemet. Simuleringer for begge disse scenariene er beskrevet i kapittel 4. Når det gjelder pdf-plottene i figur 3.10 til 3.13 ser vi at fordelingene blir smalere når båndbredden øker.

57 KAPITTEL 4 Undersøkelser For å kunne bedømme hvor godt nettoppkoblingen fungerte ønsket vi å kjøre nye runder med simuleringer, der en eller flere av parametrene var endret. I noen av tilfellene (for eksempel der antall noder er økt) måtte endringer gjøres i nettkonfigurasjonen i modellen, mens i andre tilfeller var det nok å endre parametre til modellen. 4.1 Scenario 1: Lengden på overføringen Det første vi ønsket å undersøke var hvordan nettet fungerte når avstanden mellom noder og sentralen ble økt ytterigere. Dersom nettoppkoblingen vår skal kunne fungere som et nett der abonenter knytter seg til, vil det i mange tilfeller være behov for lengre avstander enn de som er brukt i standardmodellen. Vi ønsket derfor å se på hva dette gjorde med nettets karakteristikk Konfigurasjon I denne simuleringsrunden ble avstanden mellom sentral og splitt økt til 30 kilometer. Avstanden mellom noder og sentral var fortsatt på 2 kilometer. Grunnen til at kun avstanden mellom sentral og splitt er øket, er at dette krever minst bruk av kabel, og vil sannsynligvis være den løsningen det er best å satse på. Alle andre parametre i modellen ble satt slik de var i standardmodellen. Dette innebærer at lengden rundt den logiske ringen blir på 72 kilometer, mot 32 kilometer tidligere. Også i denne simuleringsrunden ble det kjørt simuleringer for 8 forskjellige båndbredder, 3 forskjellige trafikkbelastninger og 8 forskjellige frøverdier, slik som i standardmodellen. Dette ble gjort for at sammenligningsgrunnlaget skulle bli best mulig. 55

58 56 Kapittel 4 Det kunne også vært interessant å øke avstanden mellom splitten og en eller flere av nodene. Sannsynligvis ville ikke dette ha gitt noen annen innvirkning på systemet, så lenge alle linkene mellom splitt og noder er tilnærmet like lange. Det er imidlertid viktig å huske at det å øke avstanden på flere av linkene mellom splitt og noder fort fører til at den totale lengden på den logiske ringen øker. I et nett der abonnentene er koblet til, vil sannsynligvis avstanden mellom splitt og node variere, men det er her viktig at man begrenser kabellengdene slik at noen abonnenter ikke får et dårligere nett på grunn av en annen node Resultater Som nevnt ble også denne simuleringsrunden kjørt med de samme parameterne som for standardsimuleringen. Også skalaene på alle plott er like, slik at man lettere skal kunne sammenligne resultatene med standardmodellen. Siden thttiden i modellen ble holdt på samme verdi, skulle man anta at den ekstra tiden tokenet bruker rundt ringen vil være avgjørende for resultatene. Ser man kun på den tiden en pakke er på den optiske kablen, vil denne tiden økes med 0,2ms da den logiske ringen er blitt 40 kilometer lenger. Man kan tenke seg at det vil genereres litt mindre trafikk, siden en pakke som en node sender vil bruke litt lenger tid fram til sentralen. Ser man på plottene av resultatene ser man at disse antakelsene stemmer rimelig bra. For ende til ende forsinkelsen ser man at alle verdier har økt ca 25 ms i forhold til standardsimuleringen. Dette er forsåvidt som forventet, men økningen er høyere enn hva økningen i linklengden skulle tilsi. Dette kan skyldes at også andre deler av modellen spiller inn på forsinkelsen. Resultatene viser blant annet at samtlige utkøer for nodene og sentralen er blitt lenger. Trafikken som genereres blir også noe lavere enn for standardsimuleringen. Dette kommer som en direkte følge av den økte forsinkelsen og måten modellen genererer trafikk på. Når sentralen genererer trafikk hver gang en pakke kommer inn, vil det genereres mindre trafikk når forsinkelsen øker. Utnyttelsen av linken blir lavere da disse resultatene direkte avhenger av trafikken som genereres. Sammenligner man plottene fra dette scenariet med standardsimuleringen ser man at endringen i generert trafikk og utnyttelse av linken er tilnærmet uendret, mens forsinkelsen har økt. Grunnen til dette kan være at kølengdene nå blir lengre som en følge av at tokenet bruker lengre tid rundt den logiske ringen. Når kølengdene øker i alle nodene og i sentralen vil også ende til ende forsinkelsen øke.

59 Undersøkelser Diskusjon Resultatene vi får for simuleringen i scenario 1 er som nevnt som forventet. Ser

60 58 Kapittel 4 man nøyere på hvordan forsinkelsen har endret seg i forhold til standardsimuleringen, ser man at endringene her kanskje er noe større enn ventet. Økningen i forsinkelsen samsvarer ikke direkte med hvor mye mer tid pakkene bruker rundt i nettet. Dette kan skyldes at den økte avstanden i nettet også påvirker andre deler av modellen, som for eksempel genereringen av trafikk. Går man inn i modellen og ser på kølengder under simuleringen finner man at disse har økt noe i forhold til standardsimuleringen. Pakkene blir altså liggende lenger i kø når avstanden mellom sentral og splitt økes. Grunnen til dette kan være at tokenet bruker lenger tid rundt ringen. Vi ser at det derfor blir viktig å holde trt-tiden (Token Rotation Time, tiden tokenet bruker rundt ringen) så lav som mulig. En løsning kan være å senke tht-tiden når linklengdene økes. Dette er imidlertid ikke testet. I dette scenarioet vil en pakke bruke noe lenger tid fra noden og fram til sentralen, slik at det vil ta lenger tid før sentralen kan svare. Med den trafikkmodellen vi har benyttet, betyr dette at mindre trafikk blir generert. Også i dette scenarioet ser vi at forskjellen i forsinkelse varierer mest når tilgjengelig båndbredde er lav. Grunnen til dette må være at når båndbredden er lav vil en økning i trafikken bli mer kritisk. Som nevnt innledningsvis bør avstanden mellom splitt og noder være så lik som mulig. Dersom en av disse linkene er merkbart større, kan de andre nodene få

61 Undersøkelser 59 dårligere utnyttelse av nettet siden avstanden i den logiske ringen øker. Splitten bør derfor plasseres på en slik måte at lengden på den logiske ringen blir kortest mulig. 4.2 Scenario 2: Antall noder I andre scenario ønsket vi å se på hvordan nettet tåler en økning i aktive brukere. En oppkobling som bare kan ta tre samtidige brukere vil ikke være særlig aktuell å bruke, og det vil derfor være interessant å se på hvordan modellen klarer å håndtere flere noder Konfigurasjon I denne simuleringsrunden ble avstanden mellom sentral og splitt igjen satt til 10 kilometer, slik som i standardmodellen. Antall noder ble økt fra 3 til 9, mens andre parametre i modellen ble satt til samme verdi som i standardmodellen. Alle de 9 nodene benytter samme måte å generere trafikk på som tidligere, der en prosess i hver node har en korresponderende prosess i sentralen. Avstand fra Node 2 Node 1 Node 3 Node 4 Sentral 10 km Splitt Node 5 Node 6 Node 9 Node 8 Node 7 Figur 4.4: Oppkobling av nettverket i scenario 2. Alle linker mellom splitt og noder er på 2 kilometer. splitten til hver av nodene ble satt til 2 kilometer, slik at total lengde rundt den logiske ringen ble 56 kilometer (se figur 4.4). For å øke antall noder i ringen måtte modellen programmeres om noe, men alle egenskapene er ivaretatt. Når lengden av den logiske ringen økes vil forsinkelsen i nettet gå opp (se kapittel 4.1). Det vil ta lenger tid mellom hver gang en node får tokenet, slik at

62 60 Kapittel 4 forsinkelsen sannsynligvis vil gå opp ytterligere, selv om det blir generert mindre trafikk. Grunnen til dette er ikke bare den økte lengden i ringen, men også det faktum at hver node holder tokenet en viss tid. Når det tar lang tid mellom hver gang en node får tokenet vil kølengdene øke, noe som igjen bidrar til økt ende til ende forsinkelse og mindre trafikk. Det kunne vært interessant å minske linkavstandene slik at total lengde rundt ringen ble 32 kilometer (som i standardmodellen). Da ville man lettere kunne skilt ut hva som skjer med nettet når flere noder settes inn. I den konfigurasjonen som er brukt vet man ikke hvilke endringer som skyldes økt nodeantall og hvilke som skyldes økt linklengde. Det ble imidlertid ikke tid til å kjøre en simuleringsrunde med dette oppsettet. Vi vurderte også å øke tht-tiden og kanskje spesielt sentralens tht-tid, men fant ut at vi ville få et bedre sammenligningsgrunnlag dersom vi brukte samme verdi som i standardmodellen. Forsøk med tht-tiden er beskrevet i kapittel Resultater Også denne simuleringsrunden ble kjørt over en periode på 1800 sekunder i simuleringstid og med de samme parameterne som ble brukt i standardsimuleringen. Plottene viser store forskjeller i resultatene sammenlignet med standardmodellen. For mange båndbreddeverdier er resultatene håpeløse og for dette scenariet ser man virkelig at modellen har begrensninger. I alle plottene har x-aksen samme verdier som i standardmodellen. Den totale båndbredden vil da bli noe større, men siden mengden av trafikk som genereres er tilfeldig valgt vil ikke dette spille inn på resultatene. Det vil på denne måten bli lettere å sammenligne resultatene. For ende til ende forsinkelsen (figur 4.5) ser vi at når tilgjengelig båndbredde blir lav, øker forsinkelsen dramatisk. For den laveste båndbredden er forsinkelsen oppe i hele 316 sekunder, noe som selvfølgelig er alt for mye. Når båndbredden øker synker forsinkelsen ned mot et mer akseptabelt nivå. Når ende til ende forsinkelsen er høy vil det automatisk genereres mindre trafikk. Dette har igjen sammenheng med den trafikkmodellen som er brukt. Også for de høye båndbreddene blir det generert mindre trafikk enn tidligere. Går man inn og ser på kølengdene i modellen, ser man at de er svært høye sammenlignet med standardmodellen. Det kunne vært interessant å kjøre flere simuleringsrunder med samme node-

63 Undersøkelser 61 antall for å se om man kunne bedre nettets karakteristikk ved å endre en eller flere av parametrene. Siden det genereres mindre trafikk blir også linkutnyttelsen lavere (figur 4.7).

64 62 Kapittel 4 I figur 4.8 til 4.11 er sannsynlighetsfordelingen for fire forskjellige båndbredder presentert. Av disse plottene ser man at når tilgjengelig båndbredde er lav, blir ende til ende forsinkelsen høy. Når båndbredden øker synker ende til ende forsinkelsen og sannsynligheten for en lav verdi er høyere. Alle plottene er for simuleringsrunden med høyest trafikk. Sammenligner man plottene av Figur 4.8: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i scenario 2. Tilgjengelig båndbredde er 0,025Mbps pr node, ellers er parametrene som i figur 4.5. Forsinkelsen på x-aksen er målt i sekunder.

65 Undersøkelser 63 Figur 4.9: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i scenario 2. Tilgjengelig båndbredde er 0,075Mbps pr node, ellers er parametrene som i figur 4.5. Forsinkelsen på x-aksen er målt i sekunder. sannsynlighetsfordelingene med plottet for ende til ende forsinkelsen (figur 4.5) ser man at resultatene stemmer rimelig bra. Figur 4.10: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i scenario 2. Tilgjengelig båndbredde er 0,250Mbps pr node, ellers er parametrene som i figur 4.5. Forsinkelsen på x-aksen er målt i sekunder.

66 64 Kapittel 4 Figur 4.11: Sannsynlighetsfordeling for forsinkelsen fra ende til ende i scenario 2. Tilgjengelig båndbredde er 2,50Mbps pr node, ellers er parametrene som i figur 4.5. Forsinkelsen på x-aksen er målt i sekunder Diskusjon Resultatene for forsinkelse, trafikkgenerering og utnyttelse av linken er presentert i figur 4.5 til 4.7. Verdiene på X- og Y-aksen er satt til samme verdi som for standardsimuleringen slik at man på enklest mulig måte kan sammenligne resultatene med standardsimuleringen. I figur 4.5 ser man at når tilgjengelig båndbredde er lav, blir ende til ende forsinkelsen i nettet alt for høy. Det kan være flere grunner til at nettet oppfører seg på denne måten. En mulig løsning kunne være at nettet gikk i metning på grunn av for store datamengder. Ser man derimot på de andre resultatene fra denne simuleringsrunden ser man at dette på langt nær er tilfelle. Går man derimot inn og ser nøyere på resultatene som OpNet har generert, vil man finne at nodenes kølengder er lange og spesielt gjelder dette for sentralen. Dette kan tyde på at det rett og slett tar for lang tid mellom hver gang noden får tokenet. Det faktum at sentralen har svært lang utkø, kan tyde på at denne delen av nettet burde vært prioritert enda høyere. Forsinkelsen som sentralen er ansvarlig for vil forplante seg til resten av nettet. Dersom man hadde økt sentralens tht-tid ville man fått ned kølengden her, men det er ikke sikkert at nettets ytelse hadde blitt bedre. Grunnen til dette er at det da ville tatt lenger tid mellom hver gang en node fikk tokenet. For høyere båndbredder ser det ut til at nettet fungerer bedre, selv om forsinkelsen også her er vesentlig høyere enn for standardmodellen. Kanskje er den i høyeste laget for det som er holdbart.