Local area netwerken: een onderzoek naar de toepasbaarheid van netwerken en netwerkprotocollen in een real-time omgeving d.m.v. simulatie

Een onderzoek naar de toepasbaarheid van netwerken en netwerkprotocollen in een real-time omgeving, d.m.v. simulatie. T. van Vredendaal september 1988.

TECRNISCBE UNIVERSITEIT EINDBOVEN Faculteit der Werktuigbouvkunde Vakgroep WPA

Onderzoek-opdracht

·

_·

T. van Vredendaal Afstudeerhoogleraar: Prof.dr.ir. J.E. Rooda Begeleider Onderwerp Toelichtin51

·

·

:

Ing. B.W.A.H. van Rooy

Local Area Netwerken (LANs)

10 juDi 1988

~Bij de realisatie van flexibele produktiesystesen en de steeds verdergaande integratie hiervan, velke uiteindelijk soet leiden

tot Computer Integrated Manufacturing (CIK), speelt

datacommuni-cati~ een zeer belangrijke rol. Een van de uitvoeringsvoraen oa datacommunicatie te realiseren is het Local Area Netverk (LAN).

Qpdracht

Onderzoek de werking van een co.aunicatienetwerk onder diverse belastingsomstandigheden. Hodelleer het netverk volgens de proces-interactie henadering. Ga uit van de volgende werkings-principes:

- CSKA/CD (Carrier Sense Multiple Iccess with Collision Detection), kortveg Ethernet genoead, zoals oaschreven in IEEE 802.3.

- Token-Passing Bus, zoals oaschreven in IEEE 802.C, wel-le o.a. vordt gehruitt bij het Hanufacturing Autoaation Protocol (HAP) van General Kotors.

Ve_Tsl_ag, etc.

Bet memorandum "Afstuderen in de Produktietechnologie en -Auttllllatisering" is bij de secretaresse vertrijgbaar.

Prof.dr.ir. J.E. Rooda

_<fI!2:::~a=~/

behorende bij het D2-examen van de faculteit der

Werktuigbouwkunde van de Technische Universiteit Eindhoven.

Graag wil ik hierbij Henk van Rooij bedanken die mij behulpzaam is geweest bij het uitvoeren van het onderzoek.

LOCAL AREA NETWERKEN

INHOUDSOPGAVE

1. SAMENVATTING

.

.

.

.

. . .

. .

.

. . .

.

. . .

.

.

. . .

.

.

. .

. . .

.

2 2. LOCAL AREA NETWERKEN •••••••••••••••••..•.••.••..•..••• 4 3. HET ONTWERPEN VAN SIMULATIE MODELLEN ••..•••••••••••••. 6 4. HET VALl DEREN VAN DE MODELLEN •••••••••••••.••••••••..• 10 5. DE UITVOER VAN DE SIMULATIE ••••••••••••••••••••.••••.• 18 6. CONCLUSIES ••••...••.•••••.•••.•.••.•.••.•••••••••. 21 7. EVALUATIE EN SUGGESTIES ••••••••••••••••.•••••••••••••• 22 LITERATUUR

. . .

. . . .

.

.

.

. .

. .

. . .

. .

. . .

.

.

. . .

.

.

. .

.

.

.

. .

. . .

.

BIJLAGE A Indeling Netwerken

BIJLAGE B Het OSI-Reference Model BIJLAGE C Het CSMA/CD netwerkmodel

BIJLAGE D Bet Token-Passing Bus netwerkmodel BIJLAGE E Fouten in netwerk

1. SAMENVATTING

Bij de toenemende integratie van flexibele produktie systemen speelt datacommunicatie een steeds grotere rol.

Een methode van datacommunicatie is een Local Area Netwerk

(kortweg LAN). Een indeling van netwerken, naar fysische omvang, is te vinden in bijlage A

Een LAN wordt gekarakteriseerd door het gebruikte toegangs-protocol tot het netwerk.

Dit onderzoek heeft zich gericht op twee toegangsprotocols die beide gebruik maken van een zogenaamde busstructuur. Hierbij

"hoort" iedere aangesloten node alles wat er verzonden wordt. Onderzocht zijn het "Carrier Sense Multiple Access with Collision Detection" protocol (kortweg CSMA/CD) en het Token-Passing Bus protocol.

De doel van het onderzoek is te bepalen of de onderzochte

netwerkprotocols geschikt zijn voor het gebruik in een realtime omgeving •

De geschiktheid van een netwerk om te worden gebruikt in een

realtime omgeving hangt af van twee factoren. Ten eerste moet het gebruikte protocol garanderen dat een verzonden bericht altijd aankomt en ten tweede moet dit gebeuren binnen een bekende maximale tijd.

Voor het onderzoek is er van beide protocols een model gemaakt volgens de proces-interactie benadering, deze modellen zijn te vinden in de bijlagen C en D voor resp. het CSMA/CD - en het Token-Passing Bus protocol.

Vervolgens zijn er in S84 twee simulatiemodellen gemaakt om de realtime prestaties te bepalen. De in de simulatie gebruikte

tijden zijn zo veel mogelijk afkomstig uit de IEEE normen voor de twee geteste protocols. Dit heeft als gevolg dat aIleen de twee onderste lagen van het protocol (de fysieke- en de datal ink laag) invloed hebben op de prestaties van het netwerk. De hogere lagen zijn voor beide modellen, wat tijdsverloop betreft, identiek gehouden.

uit de simulatie volgen de volgende conclusies:

Door de constuctie van het CSMA/CD protocol, waarin het opnieuw verzenden van een frame na een zogenaamde botsing slechts een

beperkt aantal maal wordt herhaald waardoor de melding "frame niet verzonden" kan voorkomen, is dit protocol niet geschikt voor het gebruik in een realtime omgeving.

Bij een simulatie met slechts vijf nodes, waarbij iedere node een aantal berichten probeert te verzenden, komt de melding "frame niet verzonden" al v~~r.

Het Token-Passing Bus protocol geeft de beide garanties en is daarmee weI geschikt voor het gebruik in een realtime omgeving.

LOCAL AREA NETWERKEN

Als extra voordeel voor het gebruik binnen een realtime omgeving heeft het Token-passing Bus protocol de mogelijkheid tot het gebruik van prioriteiten waarmee men in staat is de maximale responstijd van het netwerk te varieren. Bij een simulatie met vijf nodes, waarvan er een met een hogere prioriteit, komt de

reactietijd van het prioriteitsbericht overeen met het verzenden van dat bericht over een leeg netwerk.

2. LOCAL AREA NETWERKEN

Een Local Area Netwerk (LAN) is een van de methoden voor datacommunicatie tussen twee{ of meer) computers.

Een LAN wordt opgebouwd uit drie componenten : 1 de fysieke kabel

2 de netwerk interfacekaart en kabelconnector 3 de netwerk-programmatuur

De fysieke kabel wordt zodanig gelegd dat aIle nodes via een aansluitkabel (van maximaal 50 mtr) en een connector op het net kunnen worden aangesloten.

De interfacekaart en de connector bevatten de hardware van het netwerk en leveren elementaire communicatie-faciliteiten.

Het netwerk-programma vormt een interface tussen de gebruiker en de hardware. Het programma gebruikt de geboden (elementaire) faciliteiten om de host een aantal communicatie mogelijkheden te bieden zoals o.a. terminal gebruik op remote computer,

filetransfer, gebruik van andere apperatuur binnen het netwerk (laserprinter, plotter) etc.

Het Open System Interconnection - Reference Model (OSI-RM) geeft een indeling van het netwerk in zeven onafhankelijke lagen

(layers) waarbij elke laag gebruik maakt van de faciliteiten van de onderliggende laag om de bovenliggende laag (uitgebreidere) communicatie faciliteiten te bieden. Hierdoor ontstaat een strikte scheiding tussen de lagen.

Door deze scheiding is het mogelijk om lagen van het programma uit te wisselen zonder de rest van het programma aan te passen. Een voorbeeld hiervan is het vervangen van de datal ink- en physical Layer om op een ander toegangsprotocol over te gaan.

De lagenopbouw van het OSI model is te zien in figuur 2.1.

De communicatie verloopt langs de getrokken lijnen, maar door de lagenstructuur, die laag i volledig afschermt van alles wat in de lagen eronder gebeurt, lijkt het of de overeenkomstige lagen via de onderbroken lijnen communiceren.

De opsomming van functies van de lagen en de data_units die door de lagen uitgewisseldworden is te vinden in bijlage B.

Elke laag voegt aan de aangeboden data_unit een eigen header toe met informatie voor de ontvangende laag, deze headers worden bij ontvangst door overeenkomstige lagen weer verwijderd (zie figuur 1 in bijlage B).

LOCAL AREA NETWERKEN

data unit LAYER

message

Hostl

---

Host2

Application messagel Application

Layer _~--- Layer 7

Presentation message2 Presentation

Layer

---

Layer 6

I

Session message3 Session

Layer

_r---

Layer 5

Transport message4 Transport

Layer

_r---

Layer 4

Network packet Network

Layer _~--- Layer 3

Datalink frame DataLink

Layer

r---

Layer 2

Physical bit Physical

Layer Layer 1

3. HET ONTWERPEN VAN SIMULATIE MODELLEN

Het ontwerpen van de netwerksimulatiemodellen gaf de nodige problemen omdat standaardisatie en normering, met name in de hogere lagen (3 tot en met 7), nog ver is te zoeken.

Een duidelijk voorbeeld hiervan is de uitspraak van Tanenbaum dat "Als je niet tevreden bent over het model (protocol) van dit jaar,

dan wacht je gewoon op het model van het volgende jaar."

De huidige stand van zaken is dat 4 normen zijn geaccepteerd voor de onderste twee lagen van het OSI-RM (de data link layer en de physical layer). Dit zijn het Logical Link Control protocol (IEEE 802.2) voor de data link layer en het CSMA/CD - (IEEE 802.3), het Token-Passing Bus - (IEEE 802.4) en het Token-Ring - protocol

(IEEE 802.5) voor de physical layer.

De ontwikkelde simulatie modellen verschillen dan ook voornamelijk op het niveau van de onderste twee lagen (datalink- en physical-layer), de hogere lagen zijn zoveel mogelijk identiek gehouden om de protocol prestaties onderling vergelijkbaar te houden.

De protocol len zijn ontwikkeld met behulp van de

proces-interactie benadering. De PRIND's en DIDOC's zijn te vinden in de bijlagen C en D (voor resp CSMA/CD en Token-Passing Bus

protocol).

Het belangrijkste verschil tussen de twee protocols is te vinden in de Medium Access Control sublaag, een deel van de datalink laag. Hierin ligt vast hoe de toegang tot het netwerk geregeld wordt.

V~~r een CSMA/CD netwerk be rust het MAC op twee principes :

1 Elke aangesloten node kan op ieder moment proberen toegang tot het net te verkrijgen (Multiple Access).

2 Het continu controleren van de netwerkkabel voor de detectie van de aanwezigheid van een signaal (Carrier Sense) en het signaleren van een botsingen van twee signalen (Collision Detection).

Wanneer een botsing wordt gedetecteerd door de zendende node het zenden afgebroken en wordt op een later tijdstip opnieuw

geprobeerd het frame te verzenden. Dit gebeurt slechts een beperkt aantal maal, afhankelijk van de constante AttemptLimit. Als deze grens wordt bereikt voIgt de mededeling "frame niet verzonden door Ecessive Collision Errors (ECE)". Hierdoor is het niet mogelijk een maximum aan te geven voor de wachttijd voor een aangeboden frame omdat deze in geval van een ECE oneindig is.

Het CSMA/CD toegangsprotocol is uitgewerkt in een stroomdiagram. Dit stroomdiagram is te zien in figuur 3.1.

tUk~

rl'a~~Che{:k­

SequE'nc~

LOCAL AREA NETWERKEN

I

I

','-'r' ---;~}o;---_; liflid(hachci"f}

!

.:;:. , I

I

_II

r-

---,1

y~s

"

I

"'''iiO'

II( off

I

_I

t f , start fr.aOSMi ttirog no

Figuur 3.1 CSMA Medium Acces Protocol

send sfIHO](E>

V~~r een Token-Passing Bus berust de MAC op de roulatie van een token. AIleen die node die op dat moment in het bezit is van het token mag berichten verzenden. Het token rouleert via een logische ring (deze hoeft niet gelijk te zijn aan de fysische opstelling van de aangesloten nodes).

De lengte en aantal berichten dat per keer verzonden kan worden is afhankelijk van de tokenTimer, deze geeft de maximale tijd dat een token door een node vastgehouden mag worden, en is een functie van de prioriteit van het te verzenden frame. Als de tokenTimer afloopt tijdens het verzenden van een frame mag dit frame eerst volledig worden verzonden voor het token wordt doorqegeven. Als de node geen frame's (meer) heeft om te verzenden wordt het token direct doorgegeven.

Hiermee kan een maximale token rotatie tijd, dit is de maximale wachttijd voor een aangeboden frame, bepaald worden.

max Tr(Pri)

=

Tpd + n

*

(tokenTime(Pri) + packetTime);

waarin :

max Tr(Pri): maximale tijd tussen twee tokens, als functie van de prioriteit van het te verzenden frame.

Tpd : de voortplantingstijd van het token langs de logische ring.

n : aantal aangesloten nodes

tokenTime de tijd dat een node maximaal mag zenden

packetTime de tijd nodig om een laatste packet volledig te verzenden.

Hierdoor is het Token-Passing Bus in staat te garanderen dat een frame binnen een bepaalde, te berekenen, tijd verzonden wordt. Het Token-Passing Bus toegangsprotocol is uitqewerkt in een stroomdiagram. Dit stroomdiagram is te zien in fiquur 3.2.

,'-~---(

hJ<-~

sT(,XI>n

'\.~

-LOCAL AREA NETWERKEN

C::~t

t!l:&t~~Th,,€'!'

Figuur 3.2 Token-Passing Bus Medium Acces Protocol

l

I

!

4. HET VALIDEREN VAN DE MODELLEN

Dit hoofdstuk bestaat uit drie paragrafen. In paragraaf 4.1 worden de algemene aannames behandeld die voor zowel het CSMA/CD - als het Token-Passing Bus-protocol gelden. Deze aannames resulteren in een aantal constanten die in de netwerk-simulatie worden gebruikt. Op de specifieke aannames voor resp. het CSMA/CD- en het Token-Passing Bus-protocol wordt ingegaan in de paragrafen 4.2 en 4.3.

4.1. Algemene Aannames

In deze paragraaf worden die aannames behandeld die voor beide gesimuleerde netwerken gelden. Ze worden hieronder puntsgewijs weergegeven.

1 Op elke aansluiting (= node) van het netwerk wordt slechts een gebruiker/host aangesloten (dwz aIle berichten gaan over het netwerk). Het aantal gebruikers (= aansluitingen) wordt

gegeven door de con stante aantalNodes.

2 Het maximaal aantal aansluitingen op het netwerk , vastgelegd in de constante aantalAansl, is 100. Dit is het gevolg van een minimale afstand tussen twee aansluitingen van 5 meter en een maximale lengte van een (CSMA/CD netwerk-) segment van 500 meter.

3 De plaatsing van de gebruiker op het netwerk wordt vastgelegd door de constante aantalNodes. De constante geeft het aantal gebruikers op het netwerk en de plaatsting van de gebruikers wordt berekend met de volgende formule :

nodeplaats 1 := 1 ;

en voor de resterende nodes geldt

aantalAansl

nodeplaats i := trunc { (i-1)

* --- }

aantalNodes - 1

4 De voortplantingssnelheid van het signaal door de kabel wordt vastgelegd in de constante propagationDelay (PO). De PO is de tijd die het signaal nodig heeft om zich 5 meter, de afstand tussen twee aansluitingen, voort te planten.

De voortplantings snelheid van een signaal varieert tussen de 0.60 en 0.75

*

c (c = lichtsnelheid), afhankelijk van het gebruikte transportmedium.

Voor de simulatie is uitgegaan van 0.66 c, en dit geeft een PO van 0.025 [~s].

5 De transmissie snelheid is afhankelijk van het gebruikte

toegangs protocol. De protocols in combinatie met twisted pair-en coax-kabels schrijvpair-en snelhedpair-en tusspair-en de 1 pair-en de 10 Mbps voor terwijl in combinatie met glasvezel kabels een snelheid van 100 Mbps wordt voorgeschreven.

LOCAL AREA NETWERKEN

De gebruikte protocol definities ([IEEE 802.3] en [IEEE 802.4]) schrijven de volgende transmissie snelheden voor :

CSMA/CD

Token-Passing Bus : 1, 4 en 10 Mbit/s : 1 tot 10 Mbit/s

V~~r deze simulatie is gekozen voor een 10 Mbps netwerk. De bitTime, de tijd om een bit op de kabel te plaatsen, is omgekeerd evenredig met de transmissiesnelheid.

6 De header van een packet wordt gedefinieerd in [IEEE 802.2] en schrijft een packet header size van 4 octets voor.

Deze aannames leiden tot de volgende constant en :

aantalAansl = 100

propagationDelay = 0.025 [J.'s] bitTime = 0.1 [J.'s] packetHeaderSize = 4 octets

Daarnaast is om de duur van de simulatie beperkt te houden uitgegaan van 5 aansluitingen op het netwerk, dit geeft de constante

I

aantalNodes = 5

Door de kleine tijdsintervallen is voor de simulatie gekozen voor een tijdseenheid van 1 [J.'s].

Er is nog een constant die voor de volledigheid al weI aanwezig is maar nog niet echt gebruikt wordt, dat is de timeOutDelay. De

timeOutDelay geeft de tijd die de zender op een bevestiging van ontvangst wacht voordat het frame opnieuw wordt verzonden.

Daar in deze versie van het simulatie programma nog geen fouten voorkomen, komen de berichten altijd aan en wordt de timeOutDelay nooit gehaald.

Dit resulteert in de constante

timeoutDelay

=

0.1 E6 [J.'s] (= 0.1 [s])

In de volgende paragrafen worden de protocol-specifieke constanten en aannames behandeld.

4.2. Aannames voor het CSMA/CD netwerk.

In deze paragraaf worden de constanten voor het CSMA/CD netwerk vastgelegd. Hiervoor is uitgegaan van de norm IEEE 802.3

hoofdstuk 3 : MAC Frame structure. Voor de implementatie afhankelijke constanten is uitgegaan van de specificatie van

[Digital ,Intel ,Xerox] paragraaf 6.5.2.1. Global Declarations.

Algemene structuur frame voor CSMA/CD protocol.

I PREAMBLE I r l

-S-F-D~I--D-A~I--SA--~I-L---r-D-A-T-A-_-UN--I-~~====P=A=D====FC=S==

met

PREAMBLE = synchronisatie patroon (7 octets) SFD = start delimiter (1 octet)

DA = destination address (6 octets) SA = source address (6 octets)

L = length (2 octets)

DATA UNIT = information (0 of meer octets) PAD = extra bits (0 of meer octets) FCS = frame check sequence (4 octets)

Frame componenten

.

.

PREAMBLE De preamble gaat aan elk frame vooraf. De preamble

heeft een vaste lengte van 7 octets. De premble behoort eigenlijk niet tot het frame en wordt niet meegenomen in de bepaling van de afmetingen van hat frame.

SFD De start-delimiter geeft het begin van een frame aan en bestaat uit een zodanig bitpatroon dat de SFD altijd te onderscheiden is van data octets.

OAf SA Dit zijn de twee adresvelden van het frame die aangeven wie de zender van het frame is (SA) en wie de ontvanger

(DA). Door het gebruik van een speciale code in het DA kan ook aangegeven worden dat een frame voor meer dan een station, of zelfs aIle stations bestemd is.

L Dit veld geeft de lengte van de data_unit aan, hierdoor is de lengte van het frame bepaald en de plaatsing van de FCS ligt vast.

DATA UNIT De data_unit bevat de gegevens die verzonden worden. Het aantal octets kan varieren tussen 0 en het maximum aantal (afhankelijk van de constante usedFramerSize).

LOCAL AREA NETWERKEN

Het CSMA/CD protocol heeft een minimale aantal octets in een frame nodig om correct te kunnen functioneren. Als het aantal octets in de DATA UNIT niet voldoende is wordt er een aantal loze bits toegevoegd (de

letterlijke vertaling van PAD is opvulsel). Als de DATA_UNIT wel groot genoeg is vervalt de PAD.

De frame check sequence is een 32-bits cyclische redundancy check code, deze geeft een meer dan 99.99999995 % kans dat een fout in het frame gedetecteerd wordt.

Dit geeft de volgende set constanten die gebruikt worden in het simulatieprogramma voor een 10 Mbps CSMA/CD netwerk :

preamblesize =

frameHeaderSize

=

8

18

Dit z1Jn zeven octets voor de preamble en een SFD. De SFD wordt niet meegeteld in de bepaling van de data-inhoud van het te versturen frame.

Dit is voor de DA, SA ,L en FCS. usedFrameSize

=

1518 Dit is het maximum voor een CSMA

netwerk. jamSize slotTime = = 3.2 [I's] 5.0 [I's]

ps De jamSize is 32 maal de bitTime en daardoor afhankelijk van de transmissie snelheid.

De slotTime is gelijk aan 2 maal de round trip propagation delay (dat is de tijd die het signaal nodig heeft om zich van het ene uiterste naar het andere uiterste van het netwerk voort te planten

Daarnaast zijn de volgende constanten direct uit de specificatie [Digital, Intel, Xerox] overgenomen:

minFrameSize

₌

64 octets maxFrameSize

₌

1518 octets inter FrameS pacing = 9.6 [JJsJ backOffLimit

₌

10

LOCAL AREA NETWERKEN

4.3. Aannames voor het Token-Passing Bus netwerk.

In deze paragraaf worden de constanten voor het Token-Passing Bus netwerk vastgelegd. Daarvoor wordt uitgegaan van IEEE norm 802.4 hoofdstuk 4, Frame Formats.

Algemene structuur van een frame voor het token-Passing Bus protocol. r---.----r--~----~---//~----~--~ DATA UNIT ••

-

//~----~~ FCS ED

I

PREAMBLE met

PREAMBLE = synchronisatie patroon (1 of meer octets) SD = start delimiter (1 octet)

FC = frame control (1 octet) DA = destination address (6 octets) SA

₌

source address (6 octets)

DATA_UNIT

₌

information (0 of meer octets) FCS = frame check sequence (4 octets)

ED

₌

end delimiter (1 octet)

Het maximaal aantal octets tussen de SD en de ED (zonder deze mee te tellen) is 8191.

Frame componenten :

PREAMBLE De preamble gaat aan elk frame vooraf. De minimale afmetingen van de preamble is een functie van de data-rate en het modulatie schema. De standaard vereist dat de minimale duur van de preamble 2 [~s] is en dat de preamble bestaat uit een geheel aantal octets.

Dit geeft de volgende tabel :

data rate min. preamble used preamble [Mbps] size [bits] size [octets]

1 2 1

5 10 2

10 20 3

De start delimiter geeft het begin van een frame aan en bestaat uit een zodanig bitpatroon dat de SD altijd te onderscheiden is van data octets.

frame. Het qeeft aan of het een token- of een data frame is, en welke prioriteit het frame heeft.

DAr SA Dit z1Jn de twee adresvelden van het frame die aanqeven wie de zender van het frame is (SA) en wie de ontvanqer

(DA). Door het gebruik van een speciale code in het DA kan ook aanqeqeven worden dat een frame voor meer dan een station, of zelfs aIle stations bestemd is.

DATA UNIT De data_unit bevat de qegevens die verzonden worden. De minimale afmetinq van deze unit is 0 (in qeval van een token of ander manaqement frame), en maximaal 8191 -17 (frameHeaderSize) = 8174 octets.

FCS De frame check sequence is een 32-bits cyclische redundancy check code, deze geeft een meer dan

99.99999995 % kans dat een fout in het frame gedetecteerd wordt.

EQ De end-delimiter geeft het eind van een frame aan en bestaat uit een zodaniq bitpatroon dat de ED altijd te onderscheiden is van data octets. De ED qeeft tevens de plaats van de FCS aan.

Dit qeeft de volgende set constanten die qebruikt worden in het simulatieproqramma voor een Token-Passing Bus 10 Mbps netwerk.

bitTime

₌

0.1 [#s] preamblesize

₌

5 tokenSize

₌

17 frameHeaderSize

=

17 minFrameSize = 21 usedFrameSize

=

1518 maxFrameSize = 8191

Dit zijn drie octets voor de

preamble zelf en twee voor de SD en ED. Deze worden hierbij geteld omdat de delimiters niet meetellen in de bepalinq van de data-inhoud van het te versturen frame.

Een token heeft geen databits. Dit is voor de FC, DA, SA en FCS. frameHeaderSize + packetHeadersize. Dit is kleiner om de vergelijkinq met het CSMA-netwerk moqelijk te maken.

LOCAL AREA NETWERKEN

Daarnaast is er nog de instelling van de TokenTimer. Deze wordt ingesteld door de constanten TokenTime1 tot en met TokenTime4, deze geven de tijd dat een node het token mag houden.

De gekozen TokenTime is afhankelijk van de prioritiet van het te verzenden frame. In de simulatie is gekozen voor de volgende oplossing.

Bij de prioriteiten 1 en 2 (laagste prioriteiten) mag iedere node vier frames (van usedFrameSize) verzenden.

Bij de prioriteiten 3 en 4 drie frames, bij 5 en 6 twee frames en bij de hoogste prioriteiten ,7 en 8 , mag iedere node slechts een volledig frame verzenden. Daarnaast wordt er per verzonden frame een extra 50 [~s] bij opgeteld om een nieuwe frame op ta halen vanuit de transportlaag.

De tijd om een frame te verzenden wordtberekend in hoofdstuk 5 pagina 19.

Dit geeft de volgende constanten

.

.

TokenTime1

₌

5148.4 [~s] voor prioriteit 7 en 8

TokenTime2

₌

3861.3 [~s] voor prioriteit 5 en 6 TokenTime3

₌

2574.2 [~s] voor prioriteit 3 en 4 TokenTime4

₌

1287.1 [~s] voor prioriteit 1 en 2

5. DE UITVOER VAN DE SIMULATIE

Een van de methoden om de prestatie van een netwerk te beoordelen is het vergelijken van de responstijden. De responstijd wordt gedefinieerd als de "tijd tussen het verzenden van een packet en het ontvangen van de bijbehorende acknowledgement".

Deze responstijd is opgebouwd uit de volgende componenten : t1 t2 t3

·

·

·

·

·

·

tijd om packet van Host naar interface te sturen wachttijd packet in de interface buffer

zendtijd van het packet naar de ontvangende node t4 voortplantingstijd en wachttijd packet in de

ontvangende interface buffer

t5 tijd om packet van interface naar Host te sturen t6 tijd om response (= ack) te genereren

t7 tijd om ack van host naar interface te sturen tS wachttijd ack in de ontvangende interface buffer t9 zendtijd van het ack naar de zendende node

t10: voortplantingstijd en wachttijd ack in de interface buffer

t11: tijd om ack van interface naar host te sturen ps ack staat voor acknowledgement packet.

Enige opmerkingen bij deze tijden zoals deze in de simulaties gebruikt worden :

t1 hiervoor wordt (in de netwerklaag

=

sNtl) een wachttijd van 10 [~s] aangehouden. Deze tijd staat voor alle vertragingen in de lagen boven de Data Link Layer.

t2 deze hangt af van het gebruikte toegangs protocol, en is onbekend.

t3 voor een packet met een maximale lengte van 151S octets is dit :

(151S + preambleSize)

*

S

*

bitTime

V~~r de 10 Mbps CSMA/CD netwerk is dit : 1220.S [~s] V~~r de 10 Mbps Token-Bus netwerk is dit : 121S.4 [~s]

LOCAL AREA NETWERKEN

t4 bij t3 moet nog de voortplantingstijd van het laatste bit opgeteld worden, deze is gemiddeld 50

*

PropagationDelay. Dit is 1.25 [~s].

t5 hiervoor wordt (in de netwerklaag = rNtl) een wachttijd van 5 [~s] aangehouden.

t6 is in de simulatie nul. t7 zelfde als tl.

t8 zelfde als t2.

t9 voor een acknowledgement met een lengte van resp. 64 en 21 octets voor het CSMA en het Token-Bus protocol is dit

V~~r een 10 Mbps CSMA/CD netwerk is dit : 56.8 [~s] V~~r een 10 Mbps Token-Bus netwerk is dit : 20.8 [~s]

t10 zelfde als t4, 1.25 [~s]. t11 zelfde als t5, 5 [~s].

Met deze gegevens kan een minimale (= optimale ) doorlooptijd van een packet berekend worden, hiervoor wordt voor de variabele

wachttijden t2 en t8 nul aangehouden.

De belangrijkste uitvoer van de simulatie zijn twee tijden, de Td en de Ta. De Td is de tijd die een datapacket nodig heeft om van de zendende- naar de ontvangende transportlaag te komen. Dit geeft de volgende formule :

Td = t1 + t2 + t3 + t4 + t5. De minimale Td is daarmee :

Tdmin (CSMA/CD) = 1237.1 [~s].

Tdmin (Token-Bus)

=

1234.7 [~s].

De Ta is de tijd die een acknowledgement nodig heeft om van de ontvangende- naar de zendende transportlaag te komen. Dit geeft de volgende formule : Ta := t6 + t7 + t8 + t9 + t10 + t11 + t12. De minimale Ta is daarmee : Tamin (CSMA/CD)

=

Tamin (Token-Bus)

=

73.1 [~s]. 37.1 [~s].

De uitvoer van de simulatie bestaat uit een aantal gegevens per packet, deze bevatten de volgende gegevens.

1 het packetnummer.

2 de starttijd van het verzenden van het packet (om de volgorde van verzenden te kunnen controleren).

3 de Td, deze is genormeerd op een packetlengte van 1518 octets.

4 de Ta.

En daarnaast een tabel die de gevonden tijden in een aantal klassen indeelt.

De volgende klassen zijn aanwezig

Klasse tijd in [~s] 1 0 + 1000 2 1000 ,... 2000 3 2000

,...

3000 4 3000 ,... 4000 5 4000 ,... 5000 6 5000 + 6000 7 6000 + 7000 8 7000 + 8000 9 8000 + 9000 10 9000 + 10000 11 >10000

12 < 0, dit is het resultaat van het niet verzenden van een packet waardoor een negatieve tijd berekend wordt.

LOCAL AREA NETWERKEN

6. CONCLUSIES

Doel van dit onderzoek was het contoleren van de bruikbaarheid van het CSMA/CD - en het Token-Passing Bus protocol binnen een

realtime omgeving.

Voor dit doel zijn twee simulatiemodellen gebouwd om de presaties van de beide protocols te bekijken.

Doordat gegevens over de tijden die de verschillende processen van de hogere lagen (netwerk,transport, etc) kosten, niet te vinden

zijn is in de simulatiemodellen voor de hogere lagen uitgegaan van twee (voor be ide modellen identieke) constante tijden.

De tijden voor de toegang van het netwerk, zoals beschreven in IEEE 802.3 en IEEE 802.4, zijn opgenomen in de datal ink layer en de physical layer.

Op basis van de theoretische opbouw van de toegangsprotocols kunnen de volgende conclusies getrokken worden :

Het CSMA/CD toegangsprotocol kan niet garanderen dat een frame binnen een bekende eindige tijd wordt verzonden. Hierdoor is dit protocol niet geschikt voor het gebruik binnen een

realtime omgeving. Uit de simulatie voIgt wel dat de prestaties van het CSMA/CD protocol bij een lage bezettingsgraad iets

beter zijn dan het Token-Passing Bus protocol

Het Token-Passing Bus protocol geeft de garantie van een te berekenen eindige verzendtijd van een packet weI en is hierdoor geschikt voor het gebruik in een realtime omgeving.

Uit het simulatiemodel voor het CSMA/CD netwerk bleek dat bij druk berichtenverkeer van (slechts) 5 aangesloten nodes meer dan een keer de melding "frame niet verzonden door ECE" werd gegeven. Het Token-passing Bus protocol heeft een extra optie waardoor de bruikbaarheid binnen een realtime omgeving toeneemt.

Het is mogelijk een bericht een prioriteit mee te geven, waardoor de verzendtijd van een frame beinvloed kan worden. De frames

worden in prioriteits-volgorde afgehandeld, een frame met een lagere prioriteit moet wachten tot alle frames met een hogere prioriteit verstuurd zijn. Doordat de tijd dat een node mag zenden ook een functie is van de prioriteit, neemt de maximale wachttijd (voor een frame verzonden wordt) af bij toenemende prioriteit.

De modellen geven een eerste indruk van de prestaties van de beide protocols op datal ink- en physical layer niveau, met de beperking dat de uitkomsten van de beide simulatieprogramma's allen gebruikt mag worden om de protocols onderling te vergelijken. De uitkomsten mogen, door de ingevoerde constante tijden voor de hogere lagen en het ontbreken van fouten, nog niet vergeleken worden met

7. EVALUATIE EN SUGGESTIES

7.1 EVALUATIE

Het moeilijkste in het analyseren van processen met behulp van 084 is het opsplitsen in deelprocessen en op tijd te stoppen omdat verder verdelen de opbouw van het model onduidelijk maakt.

Bij het omzetten van de modellen van 084 naar S84 trad dit probleem nogmaals op omdat bepaalde processen in D84, door

beperkingen in Modulair Pascal, in S84 gesplitst moesten worden in twee processen.

De gebouwde simulaties z~Jn nog beperkt van opzet omdat aIleen de onderste twee lagen van het OSI-RM (datal ink en physical)

duidelijk gespecificeerd zijn. Er wordt in de modellen van

uitgegaan dat het netwerk foutloos functiopneert, deze aanname is zeken niet correct omdat de gemiddelde kans op een fout in een verzinden bit ligt rond de 10E-6.

7.2 SUGGESTIES

Hieronder volgen een aantal suggesties voor uitbreidingen /

wijzigingen van de modellen om de simulatiemodellen te verbeteren wat betreft nauwkeurigheid (dichter bij de realiteit liggende uitkomsten), realiteit (het inbrengen van foutbronnen) en bruikbaarheid in demonstraties (verbeteren output).

De volgende wijzigingen en/of uitbreidingen op het simulatie programma zijn mogelijk:

onderzoek naar normen voor de hogere lagen (MAP, TCP/IP,LU 6.2) de uitvoer van de simulatie kan uitgebreid worden met :

1 een berekende gemiddelde packet-responstijd en

standaardafwijking als functie van de gebruikte prioriteit om een duidelijker resultaat van de simulatie te tonen. 2 de responstijd van de gebruikte messages toevoegen, omdat

hieruit duidelijker de voordelen van het gebruik van prioriteiten blijkt.

het invoeren van fouten in de ontvangende datalinklaag. V~~r

enige korte aantekeningen over fouten zie bijlage E en voor meer details zie oa [HAMMOND].

Het verwijderen van de messagetypen 1,2,3,6,7,8 omdat deze geen invloed hebben op de gegevens zoals deze volgen uit de

LOCAL AREA NETWERKEN

messagetypen 4 en 5 (en 9 en 10), maar door hun timing in een veel langere simulatierun vragen.

Bet wijzigen van de messagetypen 5 en 10 zo dat de korte "storende" messages worden vervangen door lange "storende" messages zoals node 1 ze verzend. Bierdoor kan de invloed van een prioriteits message op de andere messages beter bestudeerd worden.

LITERATUUR

[1] Digital, Intel, Xerox,

"The Ethernet, Data Link en Physical Layer Specifications", Koning en Hartman, Abcoude (1980).

[2] IEEE,

"Logical Link Control", Std 802.2-1985,

The Institute of Electrical and Electronics Engeneers Inc., New York (1985).

[3] IEEE,

"Carrier Sense Multiple Access with Collision Detection", Std 802.3-1985,

The Institute of Electrical and Electronics Engeneers Inc., New York (1985).

[4] IEEE,

"Token-Passing Bus Access Method", Std 802.4-1985,

The Institute of Electrical and Electronics Engeneers Inc., New York (1985).

[5] Hammond J.L, O'Reilly P.J.P.,

"Performance analysis of Local Computer Networks", Addison-Wesley,Reading (MA) (1986).

[6] Schoemaker S. (ed),

"Computer Networks and Simulation I,ll en III", North-Holland, Amsterdam (1982).

[7] Tanenbaum A.S.,

"Computer Networks",

Prentice-Hall, Londen (1981).

[8] Rooda J.E, Joosten S.M.M, Rossingh T.J, Smedinga R., "Simulation in S84",

WPA rapportnr. 0242, TO Eindhoven (1984). [9] WeImer H.J.,

"Ontwerp van een computernetwerk werkend onder een MOPOS of ROSKIT Modulair Pascal beheerssysteem",

Afstudeerverslag Technische Hogeschool Twente (afd. E), Enschede (1985).

BIJLAGE A

BIJLAGE A Indeling Netwerken.

Er is door Tanenbaum een classificatie gemaakt van netwerktypen naar afstand tussen twee processoren. Deze classificatie is te zien in onderstaande tabel.

Interprocessor Processor located example Distance on same

0.1 m cicuitboard Data flow machine

1 m system MultiProcessor

10 m Room

100 m Building Local Area

Networks

1000 m University

10 km City

Long haul networks

100 km Coutry

1000 km continent Interconnection

Long haul networks

10000 km Planet

Tabel 1 Indeling van netwerken naar fysische afstand tussen de processoren.

Het verschil tussen local area netwerken en long haul netwerken zit zit hem in de te overbruggen afstand. Dit brengt een tweede verschil met zich mee.

V~~r een LAN wordt (meestal) een aparte kabel aangelegd die speciaal bedoeld is voor computer-communicatie (wat betreft snelheid, afscherming en bandbreedte).

In een long-haul netwerk is dat, door de te overbruggen afstand, meestal niet mogelijk en moet men van openbare kabelnetwerken

(zoals het telefoonnet) gebruik maken.

Deze netwerken zijn (op dit moment tenminste) niet erg geschikt voor datacommunicatie omdat ze bedoeld zijn voor het overbrengen van hoorbare signalen (spraak). Dit betekent dat voor

datacommunicatie de signalen aangepast moeten worden wat betreft de gebruikte bandbreedte en communicatiesnelheid.

Daarnaast moet ook rekening gehouden worden met een grotere kans op fouten. De kwalteitseisen die aan een telefoonnet gesteld

worden zijn duidelijk lager (tot een factor 100) dan de eisen die aan een computer netwerk gesteld worden.

BIJIAGE B Het OSI-Reference Model

Het OSI-Reference-Model geeft een formele definitie van de lagen (Layers) van een netwerk en de daarbij behorende

interface-data_units (de eenheden van informatie die tussen twee overeenkomstige lagen uitgewisseld worden):

Layer LayerNaam data unit

L7 Application Layer Messagel L6 Presentation Layer Message2

L5 Session Layer Message3

L4 Transport Layer Message4

L3 Network Layer Packet(s)

L2 Data Link Layer Frame(s)

Ll Physical Layer Bits

De data unit's

De message data units Z1]n genummerd omdat deze niet identiek zijn. Elke laag-voegt aan de binnenkomende data_unit een eigen header toe.

De afmeting van de data unit kan ook afnemen omdat de session-layer is in staat de afmetingen van de message te reduceren door het toepassen van datacompressie.

Vanaf laag 3 wordt het bericht, met een nog onbekende lengte, opgedeeld ~n een of meer pakketjes met een, door de implementatie vastgestelde, maximale lengte.

De plaatsing van de verschillende lagen is als voIgt:

De lagen 7 tot en met 4 behoren tot het (uitgebreide) operating systeem van de Hostcomputer.

Laag 3 is meestal een IO-driver op de Host en anders een progrmma dat draait op de hardware van de interfacekaart.

De lagen 2 en 1 zijn uitgevoerd in de hardware van de netwerk interface kaart.

BIJLAGE B

De Layer's van het CSI-Reference Model. L7 De Application Layer

data unit

In : message (* het te verzenden bericht *)

Uit : Messagel Functies :

toevoegen application-header

deze laag is een onderdeel van het programma dat gebruik maakt van de geboden communicatie-faciliteiten van het netwerk en vormt de interface tussen de gebruiker en het netwerk

L6 De Presentation Layer data unit In : Messagel Uit : Message2 Functies : toevoegen presentation-header

bieden van een bibiotheek van standaardroutines voor veel gevraagde functies, zoals

- data compressie

- coderen en decoderen van message's

- opbouwen en vrijgeven van een verbinding L5 De Session Layer data unit In : Message2 uit : Message3 Functies : toevoegen session-header

autoriseren van de gevraagde verbinding adresseren van berichten

het bieden van primitieve communicatie mogelijkheden die gebruik maken van de transport-laag

identificatie van de eindgebruiker(s)

zenden en ontvangen van gebruikersdata met een, in principe, onbeperkte lengte

L4 De Transport Layer data unit

In : Message3 uit : Packets Functies :

het toevoegen van transport-header

levert een service, die in staat is transparant gegevens van de ene gebruiker naar de andere te transporteren

de gegevens hebben een onbekende, maar beperkte lengte, waarvoor een maximale (en minimale) waarde tijdens de opbouwfase worden vastgelegd

segmenteren van een bericht in packets met een (vaste)

maximale lengte en het verzenden van deze packets met behulp van de netwerk service

bij ontvangst worden de packets in de juiste volgorde geplaatst en aan de sessie-laag doorgegeven

foutcorrectie, met behulp van foutdetectie van data link laag het versturen van een positieve bevestiging (acknowledgement

=

ack) voor een foutvrij ontvangst van het packet en een

negatieve bevestiging (nack) voor een fout ontvangen packet.

L3 De Network Layer data unit

In : Packets uit : Frames Functies :

toevoegen van frame-header

conversie van de packets naar frames

filtreren van binnenkomende frames op DestignationAddress om ze al dan niet aan de transportlaag door te geven

routing, de route waarlangs de verbinding wordt opgebouwd wordt verborgen gehouden voor de Transportlaag

identificatie van netwerkgebruikers, gebaseerd op netwerkadressen

evt. multiplexen van netwerkverbindingen

L2 De Data Link Layer data_unit

In : Frames Uit : Bits Functies :

toevoegen van frame check sequence

het ontbinden van frames in bits en deze aanbieden aan de physical layer voor verzending

het fout-gecontoleerd versturen van frames, fouten detecteren door

BIJLAGE B

b lengte >= minimale frame lengte c FrameCheckSequence controleren

de datalink-laag levert een service waarmee (vastgelegde) informatiepakketjes (frames) op een betrouwbare wijze kunnen worden uigewisseld, onafhankelijk van het gebruikte medium in de Physicallayer

Ll De Physical Layer data unit

In- : Bits

Uit : Electrische signalen Functies :

het omzetten van bits in electrische signalen en deze op de kabel plaatsen en het ontvangen van signalen en deze weer omzetten in bits

de fysieke laag geeft de gebruiker de mogelijkheid eenheden van informatie (bits) uit te wisselen via een transmissie medium.

Hostl ==> Application Presentation Session Transport Netwerk OataLink [Message [AJ [Message [P] [AJ [Message [S][P)[A] [Message [T][S][P][A][Message

[N)[T][S][P][A)[deel van Message [OL][N][T][S][P][A][deel van Message

Aantal units ] 1 ] 1 ] 1 ] 1 ] 1 ] n ] COL] n Physical [Bits] {64 •• 1512}

*

n Physical [Bits] {64 •• 1512}

*

_n

OataLink [OL][N][T][S][P][A][deel van Message ] COL] n Netwerk [N][T][S)[P][A][deel van Message ] n

Transport [T][S][P][A][Message ] n

Session [S][P][A][Message ] 1

Presentation [P] [AJ [Message ] 1

Application [AJ [Message ] 1

Host2 <== [Message ] 1

Oe vOlgende afkortingen zijn gebruikt : [A] Application header

_*

[P] Presentation header

_*

[S] Session header

_*

[T] Transport header [N] Network header

COL] OataLink header en trailer

Oe met

*

gemerkte headers kunnen leeg zijn. Figuur 1 structuur van data units

BIJLAGE C

BIJLAGE C Het CSMA/CD netwerkmodel

Deze bijlage bevat het 0-86 model van een netwerk met een Carrier Sense Multiple Access with Collision Detection (CSMA/CD) protocol. De essentie van dit model is te vinden in het proces sDLL op

pagina 21 van deze bijlage, waarin de toegang tot het net uitgewerkt is.

D86-ANALYSE

De volgende PRIND's en DIOOC's zijn aanwezig voor het Carrier Sense Multiple Acces with Collision Detection (CSMA/CD) netwerk

Prind Titel 1.1 c NetwerkSysteem 2.1 c Netwerk(-node) 3.1 c Wereld 3.2 c TransportLayer 3.3 c NetworkLayer 3.4 c DataLinkLayer

3.5 c PhysicalLayer & netwerkkabel

De structuur van het gebruikte model is te zien in figuur 1 van deze bijlage.

Figuur 1

car-r-! e:r'~er:ser i J collisionDetectfiJ

.-...

---Het CSMA/CD netwerknode model

PRIND 'NetwerkSysteem' DIDOC 'Netwerksysteem' *** OBJECTS *** BIJLAGE C {PRIND 1. lc} Wereld

t

.~ . D:sMessage _!

/

'~ /

---'

I

~

Netwerk integer

.

,

mess : RECORD messageNumber destinationAddress sourceAddress dataSize 1. • aantalNodes ; : 1 •. aantalNodes ; END; *** INTERACTIONS ***

sMessage @ DIS : mess;

*** PROCESSES ***

PROCESS Netwerk

=

EXPANDED;

PROCESS Wereld = EXPANDED;

: integer

{PRIND 2.1c} {PRIND 3.1c}

.

PRIMD I Netwerk • i I I D:sPacket i {PRIND 2.1c} D:sMessage

~

TransportLayer [1. .n) D:sPA .. \ \ i D:rPacket

\

/ /

I

D:sFrame D:sBit

\

NetwerkLayer [1 •• n] D:sFA

\

DataLinkLayer [1. .n] f ! C:CarrierSense [1. .n]

I

• PhiNet ~

\

/

-

\ _, ;, I D:rFrame I r C:CollisionDetect f [1. .n]

f

! J ( PhysicalLayer & NetwerkKabel )

BIJLAGE C DlDOC 'Netwerk'

***

OBJECTS

***

mess packet pa frame fa bit bool

=

OBJECT messageNumber integer

,

·

destinationAddress : 1 •• aantalNodes

·

I sourceAddress 1. . aantalNodes

·

I datasize : integer

·

I END;

=

OBJECT destinationAddress

·

_·

1 .. aantalNodes sourceAddress

·

_• 1 •• aantalNodes messageNumber

·

_·

integer packetNumber

·

_·

integer

packet Type

·

_·

(data,ack,nack) packetStatus : (NN,OKE,ECE,FCE,AE) packetSize

·

_·

integer lastPacket boolean END; == OBJECT packetNumber integer

·

,

packetStatus (OKE,ECE) END; == OBJECT destinationAddress : 1 •• aantalNodes sourceAddress

·

_·

1 •. aantalNodes frameType (data,ack,nack) packetContents : packet frameCheckSequense (NN,OKE,ECE,FCE,AE) END:

=

OBJECT frameStatus

·

_• (OKE,ECE)

.

,

END;

=

OBJECT nodeld : 1 •• aantalNodes t bitvalue : 0 •• 1 END:

·

·

= ARRAY [l •. aantalNodes] of boolean:

ad status

.

.

NN

₌

nog niet bekend

OKE

₌

message zonder problemen verzonden

·

I •

,

·

, ;

·

,

·

,

·

,

·

I

·

, • I :

·

,

·

,

ECE FCE

=

=

Excessive Collision Error, een packet is niet verzonden wegens een te groot aantal collisions FrameCheck Error

ad bitValue :

o

=

geen signaal aanwezig/stop zenden 1

=

weI signaal aanwezig/start zenden

*** INTERACTIONS ***

sMessage

₌

DIS, mess; sPacket, rPacket = DIS, packet:

sPA = DIS, pa

sFrame, rFrame

₌

DIS, frame;

sFA

₌

DIS, fa

sBit

₌

DIS, bit;

carrierSense

₌

CONT, bool: collisionDetect = CONT, bool;

*** PROCESSES ***

PROCESS TransportLayer PROCESS NetwerkLayer PROCESS DataLinkLayer PROCESS Physical Layer

= EXPANDED; = EXPANDED;

=

EXPANDED;

=

EXPANDED: {PRIND 3.2c} {PRIND 3.3c} {PRIND 3.4c} {PRIND 3.5c}

PRIND 'Wereld' I I I BIJLAGE C {PRIND 3.1c} Wereld D:messageType t I

~

messGen [1 •. n] .~

,

D:sMessage

ps : n = aantal op het net aangesloten nodes

DlDOC 'Wereld'

***

OBJECTS

***

messTyp = OBJECT aantalMessages minSize maxSize minTime maxTime END;

·

·

·

·

·

·

·

·

·

·

integer

·

,

integer

·

,

integer

·

,

real

·

,

real ;

(* Size geeft grenzen van datasize in message *)

(* Time geeft grenzen van tijdsinterval tussen twee messages *) mess = OBJECT messageNumber

·

_·

integer

.

,

destinationAddress •

_·

1 •• aantalNodes : sourceAddress

·

_·

1 •• aantalNodes

.

,

dataSize : integer : END;

*** INTERACTIONS messageType sMessage *** PROCESSES *** PROCESS Wereld BEGINPROC WRITE (output, *** = DIS, messTyp; = DIS, mess;

Geef het gewenste messagetype, de volgende typen zijn beschikbaar:

Gemiddelde Gemiddelde aantal

Datasize tijdsinterval messages/

Type [bytes] [s] node

1 5 1,0 10

2 160 0,05 5

3 15.000 120,0 3

Daarnaast nog twee bijzondere verdelingen

4 Filetransfer op een verder leeg netwerk. Een bericht van 30.000 bytes wordt tussen de twee verst verwijderde nodes verstuurd

5 Zelfde bericht als 4 maar daarbij worden door aIle andere nodes (behalve de zender) korte "storende" berichten verstuurd.

INPUT C1 _{geef het gewente messagtype : I) TO messTyp;} (* Start MessGeneratoren op met de juiste

CASE messTyp OF gegevens *).

1 : BEGIN 2 3 FOR i := 1 TO aantalNodes DO activate(messGen(messageType»; END (* 1 *); BEGIN FOR i := 1 TO aantalNodes DO activateCmessGen(messageType»; END (* 2 *); BEGIN FOR i := 1 TO aantalNodes DO activate(messGen(messageType» ; END (* 3 *); 4 : BEGIN

GIVE sMessage( destination Address : source Address dataSize END C* 4

*):

aantalNodes ; 1 ; 30000 ):

BIJLAGE C

5 : BEGIN

GIVE sMessage( destination Address source Address datasize FOR i := 2 to aantalNodes DO activate(messGen(messageType»: END (* 5 *) END (* case *): ENDPROC :

.

.

aantalNodes : 1 ; 30000 );

(**************************************************************)

PROCESS messGen( nodeId

·

_·

nodeRange

·

,

var aantalMessages

·

_·

integer

·

,

var minSize

·

_·

integer

·

,

var maxSize integer

·

, var minTime

·

·

real ; var maxTime

·

_• real ) :

VAR fl integer

·

,

_(*

message Number

f2

.

.

nodeRange :

(*

destination Address f3 nodeRange

·

,

(*

sourceAddress = nodeId f4 dataSizeRange

·

I

(*

datasize message

dt real

·

,

(*

tijd tussen twee messages sMessage mess

,

·

i integer

·

,

BEGINPROC FOR i := 1 TO aantalMessages DO BEGIN fl := i f3 := nodeId; f2 := Sample(l •• aantalNodes):

WHILE f2

=

f3 DO f2 := Sample(l •• aantalNodes): f4 := Sample(minSize •• maxSize): dt := Sample(minTime .• maxTime): wait(dt): GIVE sMessage(fl,f2,f3,f4): END (* For *): ENDPROC (* messGen *):

*)

*)

*)

*)

*)

PRIMD 'TransportLayer[l •• AantalNodes], {PRIND3.2c} D:sMessage sTto[i] , i

.,

'~

sTrl[i]

I

\ . / ~/.

\

D:sToPacket

/

/ ./.

"

/

/

a:sPA D:sPacket(data) D: sPacket (Ack)

DlDOC "Transport Layer"

***

OBJECTS

***

mess

₌

OBJECT messageNumber

·

_·

integer destinationAddress

·

_• 1 •. aantalNodes sourceAddress

·

_·

1 •• aantalNodes dataSize integer END; Packet

₌

OBJECT

"

D:rAck

·

,

·

,

·

,

·

,

rTrl(i]

,

\ \ \ D:rPacket

BIJLAGE C destinationAddress

·

·

1 •• aantalNodes ; sourceAddress

·

_·

1 •• aantalNodes

·

,

messageNumber

·

_·

integer ; packetNumber integer

·

, packetType (data,ack,nack) ; packetStatus (NN,OKE,ECE,FCE,AE)

·

,

packetSize integer ; lastPacket boolean

·

,

END; pa

=

OBJECT packetNumber packetStatus END; : integer

.

,

: (OKE, ECE) ;

bool = ARRAY [l •• aantalNodes] of boolean;

***

INTERACTIONS

***

sMessage = DIS, mess

.

,

sPacket(data) = DIS, packet ;

rPacket

=

DIS, packet ; (* versturen datapacket *) sPacket(ack)

₌

DIS, packet ; _{(* een acknowledgement aan de}

zender van het datapacket rAck

₌

DIS, packet

.

, (* het doorsturen van een

ontvangen acknowledgement het timout process *) tPacket

₌

DIS, packet

.

,

sToPacket

₌

DIS, packet ; toReady

₌

CONT

,

bool

.

I

***

PROCESSES

_***

PROCESS sTrl;

VAR sMessage

·

• mess ; transmQueue

·

_·

queue

,

•

not Done

·

_·

boolean

,

·

noError

·

·

boolean ;

*) aan

sPacket packet

,

·

(* het te verzenden packet *) tPacket packet

,

·

(* het timeout packet *) sToPacket

·

_• packet

,

·

toReady

·

_·

boolean

,

·

sPA

·

_·

pa

,

·

BEGINPROC iniQueue(transmQueue}: LOOP TAKE sMessage;

(* assemble the packets en plaats in queue *) assemblePackets (sMessage,transmQueue); (* start transmissie *) sPacket := fromQueue(transmQueue); tPacket := copyPacket(sPacket); GIVE sPacket; GIVE tPacket;

(* verzend volgende packets van message *)

notDone := true; noError := true;

WHILE (notDone) and (noError) DO BEGIN

TAKE sPA;

IF sPA.packetstatus

=

OKE

THEN (* status = OKE *)

If transmQueueNotEmpty

THEN (* verzend volgende packet *)

BEGIN sPacket := fromQueue(transmQueue); tPacket := copyPacket(sPacket); GIVE sPacket; GIVE tPacket; END

ELSE (* laatste packet verzonedn *)

BEGIN

(* einde van eerste transmissie *)

notDone := false; END

ELSE (* status = ECE *)

BEGIN

empty(transmQueue);

(* aanmaken error packet voor sTto *)

GIVE tPacket(status

=

ECE); noError := false;

END;

END (* While notDone and noError *);

(* het verwerken van timeout packets (* timeoutReady geeft

WHILE (not toReady) AND (noError) DO BEGIN IF sToPacketAvail THEN BEGIN TAKE sToPacket; sPacket

:=

sToPacket; tPacket := copyPacket(sPacket); GIVE sPacket; GIVE tPacket: TAKE sPA;

IF sPA. status = ECE

tot sTto het teken *) *)

BIJIAGE C

THEN BEGIN

empty(transmQueue) :

GIVE tPacket(status = ECE); noError := false;

END (* if packetstatus

=

ECE *);

END:

END (* While not toReady and noError *);

ENDLOOPi ENDPROC;

(**************************************************************)

PROCESS sTto

.

,

TYPE idRec

=

OBJECT

idNr

·

_·

integer

·

,

(*

identificatie nummer

*)

messNr integer

·

,

(*

messagenummer packet

_*)

packNr

·

_• integer

·

,

(*

packetnummer packet

_*)

timeout

·

_·

real

·

,

(*

TimeOut packet

_*)

END:

VAR tPacket

·

_·

packet

·

,

sToPacket

·

_·

packet

·

,

toReady boolean

·

,

rAck packet

·

,

id integer

·

,

_(*

id teller voor het opzoeken

*)

sId integer

·

,

(*

id teller voor het verwijderen WR ARRAY [1. .200] of idRec

.

.

(*

WachtRij voor timeout

*)

: prio

·

,

timeOutQ notDone noError : boolean : : boolean : BEGINPROC iniQueue(timeOutQ): WHILE not doomsDay DO BEGIN

initVar(id,WR) : TAKE tPacket;

toReady[nodeId]

:=

false:

addId(tPacket,id,WR,timeOutQ); not Done := true:

noError := true;

WHILE (notDone) AND (noError) DO BEGIN IF tPacketAvail THEN BEGIN TAKE tPacket; IF tPacket.Status = ECE

*)

THEN BEGIN

(* alles leeqmaken en ECE melden *)

WHILE sToPacketAvail DO delPacket(sToPacket); WHILE timeoutQnotEmpty DO BEGIN tPacket := fromPrio{timeoutQ): delPacket(tPacket): END; initvar(id,WR);

write('Message: l,messNumber,' niet verzonden door Excessive Collision Error');

noError := false; END

ELSE BEGIN

(* packet toevoegen aan timeoutQ *)

addId(tPacket,id,WR,timeoutQ); END: (* end IF *) END (* If Avail(tPacket) *): IF rAckMesgAvail THEN BEGIN TAKE rAck: sId := searchId(rAck,WR); IF sId = 0 THEN dump(rAck): IF rAck. Type = Ack

THEN

BEGIN (* Ack *)

(* verwijder packet uit wacht array *) removeId(sId,WR):

(* verwijder packet uit timeoutQueue *)

tPacket := fromQueue(timeoutQ,sId): delPacket(tPacket):

END ,ELSE

BEGIN (* Nack *)

(* verwijder packet uit wacht array *) removeId(sId,WR):

(* haal het packet uit de timeOutQ *) sToPacket := fromThisPrio(timeoutQ,sId);

(* en verstuur het opnieuw *) GIVE sToPacket: END (* If rAck.Type *): END (* If Avail(rAck) *): timeoutCheck(sId): IF sId >0 THEN BEGIN

(* verwijder packet uit wacht array *)

removeId(sId,WR) ;

(* haal het packet uit de timeOutQ *)

BIJLAGE C

(*

en verstuur het opnieuw

*)

GIVE sToPacket; END;

IF timeOutQisEmpty THEN

BEGIN

writeC'Message: ',messNumber,' is verzonden')i notDone := false:

END (* If timeoutQ *):

END (* While notDone & noError *):

ENDLOOP

ENDPROC (* Proc sTto *);

(**************************************************************)

PROCESS rTrl;

VAR rPacket : packet; rMessage : mess; sPacketCAck} : packet; rAck : packet: BEGINPROC LOOP TAKE rPacket; WITH rPacket 00 BEGIN

(* controleer status en type en handel daarnaar *) IF packetStatus

=

OKE

THEN

BEGIN (* OKE *)

IF packetType

=

Data

THEN (* OKE en Data *)

BEGIN

GIVE sPacket(Ack); END

ELSE

BEGIN (* OKE en Ack of Nack *)

GIVE rAck(rPacket,PacketType); END END ELSE BEGIN IF packetType

=

Data THEN BEGIN GIVE sPacket(Nack); END END (* if packetstatus

*):

(* FCE, AE *)

ENDLOOP; ENDPROC;

BIJLAGE C

PRIMD 'NetworkLayer [1 •• AantalNodes]' {PRIND 3.3c}

D:sPacket D:sPA

l

I

J

sNtl[i]

'--- ,-'" r '

(

, D:sFrame D:sFA DIDOC "NetworkLayer"

***

OBJECTS

***

packet = OBJECT destinationAddress sourceAddress messageNumber packetNumber packetType packetStatus packetSize lastPacket END; pa D:rPacket

r

I rNtl[i] D:rFrame 1. • aantalNodes

,

• 1 •. aantalNodes

·

I • integer

·

·

I

·

integer •

·

(Data,Ack,Nack)

·

,

,

·

(NN,OKE,ECE,FCE,AE)

·

·

,

·

_·

integer

·

,

: boolean ;

=

OBJECT packetNumber packetStatus END; : integer ; : (OKE, ECE) : frame = OBJECT destinationAddress sourceAddress frameType packetContents frameCheckSequense END; fa

=

OBJECT frameStatus END; 1 •• aantalNodes 1 •• aantalNodes (Data,Ack,Nack) : packet

·

,

·

,

·

,

·

,

: (NN,OKE,ECE,FCE,AE) ; : (OKE, ECE) ;

***

INTERACTIONS

_***

sPacket, rPacket

₌

DIS, packet

·

,

sPA

₌

DIS. pa

·

,

sFrame, rFrame

₌

DIS, frame

·

,

sFA

₌

DIS, fa

·

,

***

PROCESSES

_***

PROCESS sNTL;

var sPacket

·

·

packet ; sPacketNumber

·

_·

integer

·

,

sFrame

·

_·

frame

·

,

sFA

·

_·

fa

·

,

sPA pa ; frameStatus (OKE,ECE)

·

,

BEGINPROC LOOP TAKE sPacket; sPacketNumber := sPacket.packetNumber; (* aanmaken van een frame *)

PacketToFrameConv(sPacket,sFrame); GIVE sFrame; IF sPacket.packetType = Data THEN BEGIN TAKE sFA: GIVE sPA(sPacketNumber,sFA.frameStatus); END: ENDLOOP ENDPROC (* sNtl *);

(***************************************************************)

PROCESS rNTL; VAR rFrame rPacket BEGINPROC LOOP BEGIN frame ; packet ;

BIJLAGE C

TAKE rFrame1

(* converteer frame naar packet *)

FrameToPacketConv (rFrame, rPacket) ; GIVE rPacket;

END LOOP ENDPROC;

PRIND 'DataLinkLayer' {PRIND 3.4c}

D:sFrame D:sFA D:rFrame

l

/

/

•

.I

J

{ SDll[i])\ D:xFrame , \ - - _ . _ . -

---

.-

.--

-~

/~\

rDll[j] D:sBit C:carriersense C:collisionDetect DIDOC If DataLinkLayer"

***

OBJECTS

***

frame = OBJECT destinationAddress

·

_·

1 .. aantalNodes

·

,

sourceAddress 1 •• aantalNodes

·

,

frameType

·

_·

(data,ack,nack)

·

,

packetContents

_·

·

packet

·

,

frameCheckSequense

·

_·

(NN, OKE, ECE, FCE,AE)

·

, END; fa = OBJECT , frameStatus

·

_• (OKE,ECE) END; bit = OBJECT bodeId bitvalue END; : 1 •• aantalNodes ; 0 •• 1

.

.

bool = ARRAY [1 •• aantalNodes] of boolean:

***

INTERACTIONS

***

sFrame, xFrame sFA sBit carrierSense collisionDetect

rFrame DIS, frame DIS, fa DIS, bit : CONT, bool : CONT, bool

BIJLAGE C

***

PROCESSES

_***

PROCESS sDLL:

var deferring

·

_·

boolean

·

,

transmitting

·

_·

boolean ; not Done : boolean

·

,

noError

·

_·

boolean

·

,

attempts

·

·

integer

·

I frameSize integer

·

I startTime real

·

,

sFrame frame

·

,

xFrame

·

_·

frame

·

,

sFA

·

_·

fa

,

• sBit bit

·

,

BEGINPROC LOOP TAKE sFrame:

(* start waarden van de variabelen *)

deferring := false: transmitting := false; notDone := true: noError := true: attempts := 1:

WHILE (notDone) AND (noError) DO BEGIN IF transmitting THEN BEGIN IF collisionDetect THEN

BEGIN (* transmitting & collisionDetect *)

hold(jamTime): GIVE sBit(O):

transmitting := false:

wait(backOffTime(attempts»; inc(attempts):

IF attempts > attemptLimit THEN noError := false: END

ELSE

BEGIN (* transmitting & no collisionDetect *)

wait(bitTime):

IF klaarMetZenden THEN notDone := false END END ELSE BEGIN IF carrierSense THEN BEGIN