TECHNISCHE HOGESCHOOL EINDHOVEN

TECHNISCHE HOGESCHOOL EINDHOVEN afdelingfler ELEKTROTECHNIEK vakgroep DIGITALE SYSTEIvlEN eEB)

LAN SOITWARE

voor het THE KUNix systeem

afstudeerverslag van: periode: hoogleraar: coach:

R.M Brinkmann oktober 1984 tim augustus 1985 Prof. Ir. A. Heetman Ing. L. A. van Bokhoven

De afdel ng der elektrotechniek van de Technische Hogeschool

Eindhoven anvaardt geen verantwoordelijkheid voor de inhoud van stage- en afstudeerverslagen.

INHOUDSOPGAVE

Samenvatting Inleiding

_

_

_

1

Hoofdstuk 1 Logisch gebruik 1.1 Inleiding _ _ _ 1.2 Client server model _ _ 1.3 Disk service _ _ _ 1.4 File service _ _.._ _ _ 1.5 Printer service _ _ _ 1.6 Protectie _ _ _ 1.7 Implementatie _ _ _ Hoofdstuk 2 Het gereedschap 2.1 De LEX _ 2.2 Data communicatie standaards 2.2.1 Link laag _ _ 2.2.2 Transport laag _ 2.2.3 Compatibiliteit _ 2.4 De Intel 82586 LAN controller Hoofdstuk 3 Het ontwerp 3.1 Het lagenmodel _ 3.2 Het raamwerk _ 3.2.1 Inleiding _ _ 3.2.2 Bufferorganisatie 3.2.3 Adressering 3.2.4 Resources _ 3.3 Het versturen van data _ 3.4 Het ontvangen van data 3.4.1 Low level data reception 3.4.2 High level data reception 3.4.3 Credit management _ 3.5 Acknowledge processing 3.6 Host interface 3.6.1 In1eiding 3.6.2 Command interface 3.6.3 Response interface _ 3.7 Timers en prioriteiten 3.8 Connection management 3.9 Datagram service 3.10 Name service _ _ 3.11 Initialisatie en reset

_ _.......•.._ _ _ _.•........_ _ _ _

3 3 6 7 7 8 8

_

10 11 12 12 17 18

_ _ _

_

_

_.._ _ _

_ _

_.._ _ _

_

_

_ _ _ _ _

23 25 25 _ 27 31 31 33 36 36 39 _ 40 . 42 45 45 _ 46 47 49 52 56 57 59

Hoofdstuk 4 Ina 960 4.1 Inleiding _ _ 4.2 Link laag _ _ _ _ 4.3 Transport laag 4.4 Network management facility 4.5 Evaluatie _ _ _ conclusies

_

appendix

_

_

_ _ _ _

_ _

_

_.._61 _ 62 64 _ 65 66 _ 68

_

_

_

_

_

_

69

afkortingen _

_

_

_

_

_

81

Iiteratuur

_

_.._

_

_

_

_

_ 82

SAMENVAITING

In een samenwerkingsverband met de Katholieke Universiteit Nijmegen wordt binnen de vakgroep EB van de Technische Hogeschool Eindhoven gewerkt aan de ontwikkeling van een multiprocessor computersysteem, "THE KUNix" systeem geheten. Deze machine is gebouwd op een VME bus die de afzonderlijke modules verbindt. Dankzij deze modulaire structuur kan voor een bepaalde toepassing een machine met een minimale configuratie gebouwd worden door alleen die modules in het systeem op te nemen die voor de beoogde toepassing benodigd zijn. Een LAN interface kaart is een voorbeeld van zo een module. Deze module biedt het systeem de mogelijkheid om met andere systemen te communiceren of gebruik te maken van gemeenschappelijke faciliteiten via een netwerk. Oit verslag behandelt de inrichting van een dergelijk Local Area Network. Er is gekeken naar de funkties die op een LAN aanweZig moeten zijn, hoe deze gerealiseerd kunnen worden en met name is er een zo compleet en effident mogelijk ontwerp uitgewerkt voor de communicatie software van een LAN interface module. Met het oog op de compatibiliteit met bestaande systemen is daarbij uitgegaan van internationale standaards voor datacommunicatie protocollen die zijn ontwikkeld door ECMA (European Computer Manufacturers aSSOCiation ). Er is naar gestreefd om tot een afgerond ontwerp te komen dat het geheel van data communicatie funkties op een LAN realiseert, van funkties op hoog nivo tot en met die op laag nivo. Oaarom zijn op een aantal plaatsen meer geavanceerde technieken uit de ECMA standaards voor latere invulling opengelaten.

INLEIDING

Door een computersysteem op een Local Area Network aan te sluiten kunnen de mogelijkheden van dat systeem enorm worden vergroot. De machine die zelf van relatief bescheiden omvang kan zijn krijgt opeens toegang tot aIle op het netwerk aangesloten systemen en fadliteiten. Hier gaat het met name om een LAN voor de "THE KUNix machine" waarbij het de bedoeling is om niet alleen meerdere Unix systemen maar ook systemen van andere huize met elkaar te laten communiceren. Een Kunix machine wordt op het LAN aangesloten via een I/O controller kaart die als LAN interface geconftgureerd is. Dit betekent dat er naast een Intel 80186 processor met bijbehorend dual ported geheugen en VME interface (wat tot de standaard uitrusting van een va controller module behoort) onder andere ook een Intel 82586 LAN controller co-processor aanwezig zal zijn. Deze co-processor verzorgt een veelheid aan datacommunic:atie funkties en betekent zodoende een aanzienlijke lastenverlichting voor de 80 186. Binnen de vakgroep is een speciale executive ontworpen voor dergelijke va modulen, de LEX. Bij het ontwikkelen v~ de communicatie software is uitgegaan van de geavanceerde multiprocessing omgeving die deze LEX biedt. Het ontwerp is overeenkomstig het ISO model in een aantal software lagen te verdelen. Tot de communic:atie software worden de onderste lagen tot en met de transport laag gerekend. waarbij de nadruk op transport- en link laag ligt. Bij de invulling van deze lagen is zorg besteed aan het volgen van de normen die de ECMA standaards voor deze lagen stellen. De basis van het geheel is de 82586 LAN controller die door een vorige afstudeerder van low level software werd voorzien. Het gros van het werk wordt echter in de transport laag verricht die hier bovenop ligt. De ECMA-72 standaard die het protocol voor deze laag beschrijft is zo uitgebreid dat ze ook hier niet in alle volledigheid kon worden ingevuld. Er is de voorkeur gegeven aan het leveren van een zo compleet mogelijk ontwerp in de diepte in plaats van een in de breedte uitgewerkt geheel. Het is belangrijk bij het ontwerpen van een effident systeem het zicht over het geheel te behouden. van hoog tot laag. Bovendien wordt zo een werkend geheel geleverd waar in de toekomst op relatief eenvoudige wijze meer geavanceerde zaken aan toe kunnen worden gevoegd. Dit in tegenstelling tot de situatie die ontstaat na afl.evering van een losse software laag die weI tot in alle details is uitgewerkt echter zonder rekening te houden met hoe deze in het grote geheel moet worden opgenomen. Laatstgenoemde aanpak leidt steeds tot grote problemen tijdens het inwerken van opvolgers en dWingt deze vaak tot herziening van het ontwerp. Een andere beweegreden voor deze werkwijze was het mogelijk beschikbaar komen van het intel ina-960 software pakket ongeveer halverwege het projekt. Dit is een pakket dat weI de onderste vier communic:atie lagen geheel volgens ECMA norm realiseert. Bovendien biedt het een veelheid aan netwerk monitoring en management funkties waarmee statistische gegevens over de werking van het net kunnen worden verzameld en geinterpreteerd. Als deze inderdaad beschikbaar zou komen en op het Kunix systeem zou kunnen

- 1-

worden geimplementeerd dan zou dit vanwege de volledigheid van het kant en klare produkt de voorkeur genieten. Echter, omdat hier nog onzekerheid over heerst en omdat er al veel werk aan het eigen ontwerp was verricht, werrl besloten hiermee door te gaan en met name voorrang te geven aan het afleveren van een basisontwerp dat aIle communicatie software lagen omvat, boven een ontwerp en mogelijke implementatie dat zich slechts tot een deel hiervan zou beperken. De opzet van het verslag komt globaal overeen met de chronologie van het projekt. Er wordt in hoofdstuk 1 begonnen met een beschouwing over het logisch gebruik van het LAN. Hier wordt gekeken naar wat voor funkties er op een netwerk aanwezig moeten zijn, hoe ze zouden moeten worden ondergebracht en wat er voor een goed bedrijf van het netwerk zelf benodigd is. Daarop voIgt in hoofdstuk 2 een Uiteenzetting over wat er op de LAN kaart aanwezig was (LEX en 82586 LAN controller), en wat er diende te komen (software die ECMA transport en link laag protocollen realiseert). Hoofdstuk 3 gaat dan in op het ontwerp zelf en tot slot wordt in hoofdstuk 4 aandacht besteed aan de mogelijke opvolger van het ontwerp, het intel ina-960 communicatie software pakket. Ter ondersteuning van de bespreking van het ontwerp in hoofdstuk 3 zijn in een appendix een aantal flow charts opgenomen die de belangrijkste processen beschrijven.

- 2 -

HOOFDSTUK 1 LOGISCH GEBRUIK

.Ll INLEIDING De kenmerkende eigenschap van Local area networks is sharing, het samen

delen. Een LAN is een communicatie pad tussen ren of meerdere computers en meerdere randapparaten. Door gebr.uik te maken van een LAN kunnen de kosten van relatief dure fadliteiten over meerdere gebruikers worden gespreid en krijgen de gebruikers de mogelijkheid gegevens onderling uit te wisselen. Ben dergelijk systeem benodigt een geavanceerd netwerk software pakket, maar voordat deze ingevuld kan worden is een analyse van de verlangde functies vanuit het oogpunt van de gebruiker op zijn plaats. De specificatie van deze functies gebeurt in tennen van logisch gebruik van het netwerk. Pas als hierover duidelijkheid heerst kan worden overgegaan tot de invulling van specifieke functies in hard- en software modulen.

1.2 CLIENT SERVER l'vtODEL

De misschien twee meest fundamentele functies zijn terminal emulatie service en file service. Vanachter zijn werkstation kan een gebruiker toegang tot een remote computer systeem (bijvoorbeeld een mainframe) krijgen als zijn station een passend virtual terminal protocol kan uitvoeren. Er kan een remote sessie worden aangegaan waarbij het net lijkt alsof alle faciliteiten van het remote station direct, lokaal, ter beschikking staan. Voordat een dergelijke verbinding tot stand komt moet de gebruiker met de LAN software communiceren die in verschiIlende modulen zal zijn ondergebracht. De gebruiker doorloopt de vereiste stappen via menus zoals "login", "resource selektie", "file manipulatie", etc. Zoals terminal service een gebruiker uitbreiding van zijn processing mogelijkheden biedt, krijgt hij via file service een grotere opslag capaciteit tot zijn beschikking, en beide kunnen tot data sharing leiden. Het is zelfs mogelijk dat een gebruiker lokaal helemaal geen mass storage ter beschikking heeft en al zijn disk activiteiten via het netwerk bedrijft. Een dergelijk station zal zich remote moeten laten booten waarbij het tijdens het opstarten vraagt om geladen te worden met de juiste programmatuur. In dit geval wordt niet aIleen gebruik gemaakt van de opslagcapaciteit van een remote server maar is er tevens sprake van boot service. Afhankelijk van de uitvoering van de service wordt over disk- of file service gesproken, dit onderscheid komt verderop aan bod. WeI dient men goed te

-3-

beseffen dat disk sharing niet hetzelfde is als data sharing: een disk kan door meerdere gebruikers gedeeld worden zonder dat de een bij de data van een ander kan komen. Echte data sharing gaat veel verder en brengt extra problemen met zich mee betreffende toegang tot en integriteit van de data. De toegang tot bepaalde faciliteiten is een vraag die van toepassing is op het hele netwerk. Men zal niet aIleen willen voorkomen dat zomaar iedereen in bepaalde gevoelige files kan gaan knoeien, maar zal ook een mate van afscherming rond bepaalde gepriviligeerde facliteiten (bijvoorbeeld dure printers) willen instellen. Hier is sprake van het verifieren van het recht van een aanvrager om van een zekere service gebruik te maken. Dit wordt vaak 'aangeduid als authentication service. Een andere op LANs veel gebruikte dienst is printer service. Meerdere gebruikers delen bepaalde hardropy hardware (printers, plotters) via een spooling mechanisme, waardoor een gebruiker zijn af te drukken file direct naar het betreffende device kan opsturen ongeacht de status van het apparaat. De data wordt desnoods bewaard totdat de printer klaar is om het op papier te zetten, en in de tussentijd kan de gebruiker doorgaan met andere activitei.ten. Het komt vaak voor dat een direct communicatie mechanisme tussen gebruikers op een netwerk wordt geboden, a(',ngeduid als mail service. Er moet daarbij onderscheid gemaakt worden tussen boodschappen die meteen op het terminal apparaat van de tegenpartij verschijnen en berichten die in een "postvak file" van de geadresseerde terecht komen. In het laatste geval kan de ontvanger zijn mail op een hem welgevallig moment uitlezen. Al deze funkties zijn een zaak van de netwerk software en niet van de communicatie media of protocollen. Een snel comrnunicatie medium en ingewikkelde protocollen bieden slechts het fundament waarop, en het gereedschap waarmee dergelijke services kunnen worden gerealiseerd. Uiteraard geldt weI dat hoe beter het gereedschap is, hoe beter het eindprodukt kan worden. De netwerk software kan beschouwd worden als een uitbreiding van het lokale operating system (OS) dat de gebruiker toegang tot de netwerk faciliteiten biedt. Het lokale OS wordt uitgebreid tot een netwerk operating system (NOS). Deze gaat steeds na of een bepaalde activiteit van het applicatie programma buiten de lokale processing omgeving reikt. Als een commando op de lokale configuratie betrekking heeft, dan wordt het direct doorgegeven aan de lokale machine. Echter, als het commando service van het netwerk verlangt dan wordt deze naar de betreffende server gestuurd om uitgevoerd te worden, langs het lokale OS heen. In het geval van DOS kan gedacht worden aan een shell die direct hoven het resident gedeelte van COMMAND.COM zit en aIle DOS calls (interrupt 21) opvangt. . De struktuur van het netwerk is tot zover precies volgens het client-server model. De gebruiker of een applicatie programma die commando's via de netwerk software over het net stuurt, treedt op als client, en de entity die de opdracht uitvoert is de server. De uitvoering van de servers bepaalt de snelheid, veiligheid en het gemak van het hele netwerk. Men dient goed te beseffen dat hoewel de funkties in theorie en in software duidelijk in client en server eenheden zijn te onderscheiden, ze in hardware mogelijkerwijs gedeeltelijk

- 4 -

•

samen zullen zijn gevoegd. Een station kan zowel een aantal directe gebruikers als clienten ondersteunen, als een bepaalde netwerk service verrichten, en in dit opZicht als server optreden. Hier is sprake van een non-dedicated server in tegenstelling tot een dedicated server die zuiver en aIleen op netwerk commando's reageert. Daarnaast kunnen de servers als gecentraliseerde of als gedistribueerde servers worden uitgevoerd, afhankelijk van de gewenste implementatie. In het eerste geval wordt de service door een hardware unit verricht, terwijl in het tweede geval de uitvoering van de service over meerdere stations wordt verspreid. Behalve de hoven besproken services, die elk een tastbare uitbreiding van de werkomgeving van de gebruiker representeren, zijn er ook services die onontbeerlijk zijn voor een goede werking van het netwerk op Zich. Een belangrijk voorbeeld hiervan is de name service die de adressering van de diverse applicaties en services, ondergebracht op verschillende stations, mogelijk maakt. Dit is een typische service die zich goed leent voor een gedistribueerde uitvoering: elk station heeft daarbij een naam tabel die geraadpleegd wordt zodra een applicatie service van het netwerk verlangt. Dan nog is het noodzakelijk om een centrale server te hebben die een "moeder naam tabel" administreert. Hier worden wijzigingen in de LAN confi.guratie geregistreerd en aan aIle naam tabel copieen op de verschillende stations doorgemeld. Tevens zal bij het opstarten van het netwerk vanuit deze centrale name server (eNS) het doorsturen van de naam tabellen aan aIle LAN stations plaats vinden. Andere netwerk ondersteunende services zijn het bijhouden van een administratie en het eventueel verTekenen van het gebruik van bepaalde netwerk services, de authentication service en ook de boot service. In frguur 1.1 zijn de genoemde services schematisch in beeld gebracht. Dit zijn de meest gebruikelijke services hoewel het duidelijk z~l zijn dat hiennee niet aIle denkbare servers aan de orde zijn geweest. De confrguratie van een LAN wordt enkel beperkt door fantasie en portemonnee van de ontwerper.

figuur 1.1 logisch model - 5-

1.3 DISK SERVICE

In essentie is een disk server niet meer dan een hard disk die door meerdere op het netwerk aangesloten computer systemen kan worden gebruikt. Netwerk aanvragen worden door elk afzonderlijk station lokaal afgehandeld en de sharro. disk is voor de gebruiker niet meer dan een extra disk device waar £lIes naartoe gestuurd en vandaan gehaald kunnen worden. Het gebruik van de remote disk gaat via een lokale device driver routine die vastlegt hoe het remote device aangesproken moet worden. Wat de gebruiker betreft werkt de remote disk drive op precies dezelfde wijze als een lokale disk. Het opsporen van de preciese lokatie van disk data gaat via een file aJ1ocation_ tabel (FAT). Ook voor het vinden van data op de remote disk moet de FAT geraadpleegd worden. Daarbij zijn twee uitvoeringen denkbaar: de FAT kan zich bij de server bevinden op het remote station of er kunnen copieen van de FAT bij de stations van de lokale gebruikers aanwezig zijn. In het eerste geval zal het netwerk herhaaldelijk in beslag worden genomen om data te localiseren, in het tweede geval wordt het netwerk minder belast maar wordt op elk gebruikers station extra geheugen ruimte in beslag genomen door de FAT tabeIlen. Deze laatste oplossing. hoewel aantrekkelijk wat betreft de belasting van het netwerk, brengt een ander probleem met zich mee: indien eeri gebruiker de inhoud van een £lIe wijzigt, en daarmee ook de FAT, dan zullen de copieen van de FAT op de afzonderlijke stations steeds moeten worden bijgehouden. en weI zodanig dat twee stations die tegelijkertijd gebruik van de £lIe maken elkaar niet in de haren vliegen. Heot probleem is gedeeltelijk op te lossen door een verdergaande nuancering van het disk gebruik in te voeren: de sharro. disk kan voor een deel opgedeeld worden in volumes die elk de exc1usieve eigendom van ren client systeem zijn. 20 heeft elke gebruiker een eigen workspace op de disk waar gelezen en geschreven kan worden zander tussenkomst van anderen. Een ander deel van de disk kan public worden gemaakt en worden gebruikt voor opslag van programmatuur en data bases voor algemeen gebruik. Deze sector biedt veel gebruikte routines en toegang tot bepaalde gegevens in read only mode o¢at multiple access geen probleem vormt. AIleen een daartoe bevoegde netwerk beheerder mag gegevens in dit gebied wijzigen. Voor intercommunicatie moeten er ook read/Write public volumes zijn. Omdat deze het hoven geschetste probleem met zich meebrengen zal de toegang ertoe beveiligd moeten worden zodanig dat slechts ren gebruiker tegelijkertijd met een bepaalde data eenheid mag werken. Mits men zich hieraan houdt kan de FAT van de disk zowel centraal als gedistribueerd worden uitgevoerd, afhankelijk van de wensen van de gebruikers.

- 6-

1.4 FILE SERVICE

Een file server is tegelijkertijd meer geavanceerd en flexibeler dan een disk server. Nu wordt het netwerk niet als een extra disk aangesproken maar via individuele files. Hier zal de netwerk software van het werkstation als een filter commando's van de gebruiker opvangen. Aanvragen die door de lokale as kunnen worden afgehandeld worden gewoon doorgegeven en uitgevoerd door de lokale machine, maar commando's die betrekking hebben op een remote service worden naar de file server gerouteerd en komen nooit bij het lokale as. Het werkstation doet niet meer dan het aanvragen van een file. De file server beheert de FAT en administreert de status van de file. 20 zal file sharing geen probleem opleveren omdat het beheer van de file steeds bij de file server ligt. Het updaten van een file (en met name de FAT) gaat veel sneller dan in het disk service geval omdat er slechts sprake is van een FAT; bovendien hoeft de disk niet gepartitioneerd te worden in volurnes van verschillende typen. In principe kan elke gebruiker elke sector op disk lezen of beschrijven, hoewel dit in de praktijk waarschijnlijk niet zo wenselijk zal zijn. Bepaalde files kunnen in dat geval door access privileges worden afgeschermd tegen algemeen gebruik. Typische file server commando's zijn: put file(fn); get file(fn); delete file(fn); make dirCdn); list dir(dn); delete dir(dn); copy file(fnl,fn2); move file(fnl,fn2) met fn-file pad en dn=directory pad. Een veelgevraagde toepassing op LANs is ondersteuning van systemen met verschillende operating systems. Het geval van een disk server kan vrij recht toe recht aan gerealiseerd worden door partitionering van de hard disk. Elke partitie wordt door het desbetreffende werkstation onder de lokale as beheerd, maar daarmee wordt nog geen data sharing bereikt. Daartoe zou een programma gebruikt moeten worden dat files van de ene partitie leest en naar een andere schrijft, een tijd- en disk intensieve bezigheid. De file server is efficienter. Het as van de file server station kan zodanig zijn dat het de opdrachten van de diverse operating systems op het net kan interpreteren en uitvoeren. Via het as van de file server kunnen systemen met verschillende operating systems elkanders files delen, aangenomen dat ze dezelfde file struktuur gebruiken. Een andere aanpak is het invoeren van een globale. as bij een file server. Elk station dient daarbij de commando's van zijn lokale as te vertalen naar de syntax van de globale as en de file server kan dan real time aan de slag gaan.

1.5 PRINTER SERVICE

Een printer server bestaat uit twee afzonderlijke modules: de controle van het eigenlijke printer device en het spoolen van de te printen files. Deze twee functies kunnen samen op een printer server of gescheiden op twee verschillende machines worden ondergebracht. Een user print commando

- 7-

resulteert in het copieren van de gespeciftceerde file naar een speciale spooler directory van de file server. Deze file kan zich Of lokaal bij de opdrachtgever of ergens op de file server zelf bevinden. Het dequeuen van de spooler gebeurt op aanwijzing van de printer server als deze gereed is om een nieuwe file af te drukken. In dit geval treedt de printer server op als client van de file server.

1.6 PROTECTIE

Evenals op een gecentraliseerd computer systeem dienen op een LAN gebruikers tegen elkaar beschermd, en bepaalde faciliteiten beveiligd te worden. Het eerste aspect is een kwestie van resource sharing dat het beste bij de betrokken resource zelf kan worden uitgevoerd, bijvoorbeeld multiple file access, printer spooling of multiple terminal sessies op ren systeem. Het tweede aspect betreft het recht van een gebruiker om een bepaalde faciliteit te gebruiken. Gedacht kan worden aan een password systeem waarbij geverifieerd wordt of een aanvrager bonafide is (authentication service). Er zijn hiervoor twee veeI toegepaste technieken te onderscheiden: de tabel methode waarbij users en resources via een coordinatensysteem afgebeeld worden op weI of geen recht van toegang, en de lattice methode, waarbij een resource ingeschaaid wordt op een bepaald "security nivo·. Ais de aanvrager de betreffende security rang bezit zal hij worden toegelaten, anders niet. Het gebruik van netwerk faciliteiten wordt op twee nivo's geregeld: allereerst dient de aanvrager zich te legitimeren om toegang tot het netwerk zelf te krijgen. Daarna zal per aangevraagde resource nagegaan moeten worden of de user het gebruikersrecht heeft. Een eenvoudig voorbeeld van dit mechanisme is het aangaan van een remote terminal sessie. Eerst moet de gebruiker op het netwerk inloggen, daarna specificeert hij de machine waarop hij wi! werken waarna hij vervolgens een login procedure op deze remote machine zal moeten doorlopen.

1.7 IMPLEMENT ATIE

Tot nu toe is er sprake geweest van een centrale disk/file server waar allerlei zaken als name service, boot service, printer spooling etc. aan toe kunnen worden gevoegd. Het inrichten van een dergelijke "superserver" als middelpunt van het netwerk brengt echter een aantal bezwaren met zich mee: zo zal het uitvallen van dit centrale station de uitschakeling van vrijwel het heIe net tot gevoig hebben. Bovendien gaat de interaktie tussen twee stations altijd via de centrale server waardoor de throughput van het LAN systeem er op achteruit gaat. Het zou ideaal zijn als de diverse services over meerdere machines gedistribueerd konden worden en als de services die zich beter voor een

- 8-

gecentraliseerde uitvoering lenen elk op een apart station zouden draaien. Uiteraard zal dit in het algemeen om financtele redenen niet haalbaar zijn en brengt het qua administratie en beveiliging grote problemen met zich mee. Voor een bescheiden Kunix LAN zou een configuratie met een file server station, een administratie server station en misschien nog een aparte printer server goed voldoen. Hierop zouden meerdere Kunix machines en systemen van ander kaliber kunnen worden aangesloten, mits ze zich aan de protocollen van de communicatie software en de conventies van de hogere netwerk software lagen houden. Elk LAN station zou daartoe voorzien, moeten zijn van hetzelfde communicatie software pakket, een uruforme module die in hoofdstuk 3 besproken wordt. De interface naar de host en de overige data processing funkties zijn specifiek per station en kunnen op de mogelijkheden van host en LAN station worden aangepast. Om financiele redenen en om vertrouwd te raken met het LAN systeem is een centrale file server met toegevoegde printer spooler een goede keus. Hoewel ook de netwerk administratie funkties hier zouden kunnen worden ondergebracht is het om performance redenen beter hier een aparte machine voor te kiezen. Deze zou boot service, authentication service, name service en mail service kunnen uitvoeren. Het station Z0U voor de opslag van boot files, data files en mail files een eigen disk medium moeten bezitten. Naast de naam- en veri.fi.katie tabellen zal het ook een login tabel moeten beheren waarin bijgehouden wordt welke gebruikers op het netwerk aktief zijn. De login procedure, die lokaal opgestart wordt als een gebruiker met het netwerk wi! werken, stuurt de gegevens van de aanvrager naar de log-server. Hier wordt de aanvrager via een verificatie tabel gecontroleerd en na goedkeuring opgenomen in een login tabel waarna de netwerk sessie kan beginnen. Het uitloggen resulteert in een boodschap naar de log-server die de desbetreffende entry in de login tabel zal uitwissen. Deze login gegevens zijn niet alleen van belang voor systeem beheerders die in de gaten willen houden hoe het netwerk wordt gebruikt, maar ook voor de implementatie van mail service. Er dient dUidelijk onderscheid gemaakt te worden tussen diroctemail service, waarbij de boodschappen van de zender meteen op het output device van de geadresseerde verschijnt (verder aangeduid als write service), en mail service waarbij de berichten in speciale mail files worden opgeslagen. Deze laatste kan op de administratie server geimplementeerd worden door een speciale mail directory in te voeren die per gebruiker een mail file bevat. Om "write" boodschappen over te kunnen sturen moet men eerst weten waar de tegenpartij zich op het netwerk bevindt. Dit is te achterhalen via de login tabel waarna het write bericht direct naar de plaats van bestemming kan worden verstuurd. Het ontvangende station is verantwoordelijk voor de afhandeling van het commando.

- 9-

HOOFDSTUK 2 HIT GEREEDSCHAP

De hier ontwikkelde communicatie software is gefundeerd op de faciliteiten die de LEX, een real-time multitasking operating system biedt. De communicatie software kan in drie flIes opgedeeld worden overeenkomstig de drie software lagen (zie hoofdstuk 3) I-Iaag, T-Iaag en L-Iaag. Deze moeten tot ren applicatie in een load module worden gecombineerd dat na toevoeging van de LEX een werkend geheel vormt. De applicatie bestaat uit een verzameling processen en handlers die via mailboxes met elkaar communiceren. De mailbox is behalve een communicatiemiddel ook een middel van synchronisatie daar het door zijn semafoor werking een proces kan laten wachten. Een proces is per deflnitie oneindig. Het voert een programma uit dat een Ius doorloopt, maar zal uiteraard niet altijd aktief zijn. Een proces heeft een prioriteitswaarde die met de system call MYPRlO1Y gezet kan worden. Processen zijn georganiseerd in een ready list en in queued lists, bijvoorbeeld horend bij een mailbox .. Om een bericht door te geven naar een ander proces zal het eerste proces een vmail operatie uitvoeren op de mailbox tussen deze twee. Het andere proces leest het bericht uit de mailbox middels een pmail operatie. Het kan ook anders gesteld worden: een proces dat op gegevens van een ander proces moet wachten doet dit door een pmail operatie uit te voeren op de mailbox die deze twee verbindt. Het proces staat bij de mailbox gequeued totdat er een bericht in gedeponeerd wordt door een ander proces. Dit is een erg bruikbaar concept bij het implementeren van data communicatie protocollen. Een mailbox bericht heeft een grootte van twee 16 bits woorden. Indien men meer' gegevens wil communiceren dan kan dit door het meegeven van een pointer die naar een communicatie buffer wijst. Er is steeds ren proces aktief. Dit is het proces uit de ready list dat de hoogste prioriteit heeft. Er wordt van aktief proces gewisseld als dit proces een mailbox operatie uitvoert of als een interrupt handler daartoe aanleiding geeft. Na de mailbox operatie kan het proces gequeued staan (pmail op lege mailbox of vmail op volle mailbox) of ready maar niet aktief zijn omdat een proces met hogere prioriteit door de mailbox operatie (vmail) ready is geworden. Door middel van een interrupt handler heeft een externe gebeurtenis de mogelijkheid om in het programmaverloop in te grijpen. Hier worden handlers gebruikt om op meldingen van de LAN controller en het verstrijken van een timer tick te reageren. De handler geeft via een mailbox informatie door over het gebeurde naar een proces dat hierop stond te wachten. Hoewel het concept van een verzameling processen en handlers, die via

- 10-

mailboxes communiceren, een erg plezierige en doorzichtige programma struktuur geeft, is het niet verstandig om elke afzonderlijke programma eenheid als proces uit te voeren. Dit omdat een dergelijke opzet veel overhead met zich mee zou brengen in de vorm van proces sWitching. Daarom is ernaar gestreefd om de subprogramma's zoveel mogelijk als routines uit te voeren en alleen gebruik te rnaken van processen waar het optreden van asynchrone gebeurtenissen (interrupts) dit voorschrijft, en waar sprake is van gebeurtemssen die "parallel" kunnen lopeno 20 kan het voorkomen dat een proces moet wachten op een resource, maar dat in de tussentijd een ander proces dat door eerstgenoemde ready werd gemaakt kan doorlopen. Op meerdere plaatsen in het ontwerp is sprake van resources die in de loop der tijd door verschillende processen gebruikt worden. Te denken valt aan hardware resources zoals dma- of LAN controller, en aan software resources zoals bufferpointers of variabelen in een tabel. Er moet voorkomen worden dat door gelijktijdige aanvragen vanuit twee onafhankelijke processen niet eenduidige situaties ontstaan met betrekking tot deze resources. Daartoe worden dergelijke resources via het monitor concept beschermd. Een monitor is een verzameling routines waardoor een aanroeper exclusieve toegang tot de beschermde resource kan kIijgen. Door een intern semafoor mechanisme wordt voorkomen dat een tweede proces ,toegang kIijgt tot een beschermde resource als een ander proces al met de uitvoeIing van een monitor routine bezig is. 20 wordt mutual exclusion van parallel lopende processen gerealiseerd. Een speciale LEX system call die nog niet aan de orde is geweest is de GEISEL call waarmee dynamische geheugenallocatie gerealiseerd kan worden. Dit is handig bij het defimeren van buffer, tabel, of queue ruimten. De LEX beheert geheugen segmenten in partities van 16 bytes. Na aanroep van GETSEG(segptr, siz) wordt, indien beschikbaar, een geheugensegment ter grootte van siz geretourneerd naar pointer segptr.

2.2 DATACOMMUNICATIE STANDAARDS

Open systems interconnection (OSO standaards zijn bedoeld om het verbinden van heterogene data processing systemen te vergemakkelijken. Verschillende internationale standaardisatie organisaties houden zich bezig met de ontwikkeling van netwerk standaards om zo de compatibiliteit tussen netwerken onderling te bevorderen. De International standards organization (ISO) is met een lagenmodel gekomen waar elke laag een verzameling afspraken behelst. De lagen aan de onderkant van het model specificeren de meest elementaire regels terwijl elke daar bovenop gelegen laag fWlkties toevoegt die afhankelijk zijn van het mechanisme van de onderbuur. ECMA en IEEE zijn organisaties die uitgaande van dit model, standaards voor een aantal lagen hebben ontwikkeld die speciaal toegespitst zijn op local area networks. Ofschoon IEEE ten tijde van dit schrijven het verst gevorderd was met dit werk, is vanwege moeilijkhed.en rond de verkrijgbaarheid van IEEE

-11-

documenten toch voor ECMA gekozen. Het ontwerp is gebaseerd op twee ECMA standaards van september 1982, standaard ECMA-82 Link Layer en standaard ECMA-72 Transport protocol.

De Link 1aag (verder aangeduid als L-1aag) rust direkt op de fysische laag die de fysieke signalering op het transmissie medium voorschrijft. De link 1aag

biedt "best effort, connectieloze data transmissie service. Dit houdt in dat aangeboden data niet op vooraf opgezette connecties verzonden wordt, en ook niet met garantie kan worden afgeleverd. De transmissie kan op point to JX>int basis zijn, tussen twee stations, of op multicast basis, tussen meerdere stations. Binnen de link laag zijn van hoven naar beneden de volgende drie sublagen gedefinieerd: logical link control (LLC), framing, en medium access control (MAC). De laatste twee worden geheel in hardware door de 586 LAN controller uitgevoerd. De primitieven van de link laag hebben de volgende struktuur: aanvrage: LSEND( source adres, destination adres, data ) gereedmelding: LSEND( source adres, destination adres, data ) De LLC sublaag regelt de aanvrage van een transmissie en is het enige deel van de link laag dat in het communicatie software ontwerp gerealiseerd hoeft te worden. Volgens protocol voorschrift voegt het een DLSAP (Destination link service access point) en een- SLSAP (Source link service access point) aan het data blok toe. Logical Link Control Data Unit geheten (LLCDU); zie figuur 2.1 voor de velden van de frame. Verder voorziet de L-laag de 586 LAN controller van voldoende infonnatie en resources om de protocollen van de onderste twee sublagen uit te kunnen voeren (zie § 2.3). 20 moeten source en destination dte adres (data terminal equipment) doorgegeven worden. Dit zijn 48 bits adressen die een uniek LAN station aangeven. Het eerste bit geeft aan of het om een individueel of om een multicast adres gaat. Als het adres uit 48 enen bestaat dan gaat het om een broadcast adres waarbij de data naar alle stations op het net wordt verstuurd. Aan het einde van de frame zijn een PAD en een frame check sequence (FCS) veld opgenomen. Beide worden automatisch door de 586 ingevuld. Eerstgenoemde zorgt ervoor dat, door opvulling van de frame, de frame een bepaalde minimale grootte heeft ( er moeten minstens 43 bytes data in de frame zitten ) en met de FCS wordt de correetheid van het ontvangen frame gecontroleerd. lO

2.2.2 TRANSPORT LAAG

Een van de fundamentele principes achter het ISO referentie model is dat de data processing georienteercie funkties, de gebruikers van de transport laag service, eenduidig ontkoppeld worden van de communicatie georienteercie funkties. De transportlaag dient daartoe twee gebruikers transparante,

- 12 -

7',

p* octet

PREA~1BLE

Start of Information Field

1 octet (ind i vidual/ multicast bit) 6 octets 6

HESTINATION DTE ADDRESS

.

l

.

':' ! I

I

i

U

octets

SOURCE DTE ADDRESS LLCDU octet count

A /, I

D L S A P

1 octet

; ;

I

I

:-'1

2 octets

I

,

, I

D

U

P h Y S 1

C

S L S A P

1 octet

Control

1 octet ,......

L L C D U

A

q*

to

0 to 1497 octets

DA T A

a 1

i

f :

r a m e ;

I

I

1.+97 octets

,>

,'/ PAD

'J 4 octets

FCS End of Frame Delimiter

, ,1/

figuur 2.1 frame struktuur

- 13 -

;

I

!

i

\Iv

betrouwbare, end-to-end data transport te bieden, ongeacht de eronder liggende communicatie middelen. Omdat de kwaliteit van service van netwerken tot en met de netwerk laag in de praktijk sterk kan varieren, is de standaard van het transport laag protocol uitgewerkt in een vijftal klassen van toenemende geavanceerdheid. Hier wordt gebruik gemaakt van de hoogste klasse, klasse 4 error detection and recovery protocol. De transport laag biedt transport service aan een gebruiker via een transport service access point (TSAP). Zo wordt de gebruiker via zijn transport adres, een combinatie van TSAP en netwerk adres, geidentificeerd. De essentie van de transport service komt neer op het afleveren van transport service data units -cTSDU's) over transport connecties (TCs) tussen twee transport adressen. De transport service gebruikers krijgen de middelen om deze tweeweg communicatie kanalen op te bouwen, te onderhouden en weer af te breken. De transport service kan in de drie afzonderlijke "levens-fasen" van een TC worden beschouwd: Tijdens de opbouw fase zijn de volgende handelingen aan de orde: - Er wordt een referentie paar geselecteerd. Elk station selecteert zijn eigen reference die door de partner bij adressering van de eerste dient te worden gebruikt. Via deze reference wordt het virtueel circuit (VC) binnen een station geidentificeerd. - Het voeren van onderhandelingen met de partner over de graad van service op het VC en de keuze van bepaalde parameters. .- Het afbeelden van transport adressen op netwerk adressen, het eventueel multiplexen van meerdere VCs op een netwerk connectie of het splitsen van de last van een TC over meerdere NCs. Binnen dit ontwerp is er slechts sprake van een klasse van service. Er wordt uitgegaan van klasse 4 met vooraf bepaalde parameters. Er is dus geen behoefte aan het voeren van onderhandelingen ten aanzien van klassen en opties tijdens de TC opbouw fase. Bovendien is hier sprake van maar een netwerk kanaal waarop aIle transport connecties worden aangesloten. Het opsp litsen van TCs is dus ook niet aan de orde. In de data transfer fase worden de volgende funkties verricht: - concatenatie: het samenvoegen van meerdere transport protocol data units (TPDUs) in een network service data unit (NSDU); wordt mer niet gebruikt. - segmentatie: het splitsen van een TSDU in meerdere TPDUs die op de plaats van bestemming weer tot een TSDU worden geassem bleerd. Dit is het msg/blok mechanisme dat in hoofdstuk 3 besproken wordt. - multiplexing: het gebruik van een netwerk connectie voor meerdere TCs. - Het opsplitsen van de werklast van een TC over meerdere NCs: wordt mer niet toegepast. - flow control: het reguleren van de data flow van TPDUs op een TC door de ontvanger, opdat deze niet overspoeld wordt met data die het niet kan ontvangen. - error detektie: het detekteren van verlies, verminking, duplikatie of uit

- 14 -

volgorde geraken van TPDUs. - error recovery: het herstellen van bovengenoemde errors. - expedited data: een optie dat een speciaal data kanaal aan het netwerk toevoegt waardoor de flow control van het normale kanaal omzeild, en data met spoed verstuurd kan worden. - afbakening van TSDUs. In de TC afbreek fase wordt, ongeacht de activiteiten die op dat moment op het VC plaatsvinden, het kanaal afgebroken. Het opzetten van een VC gaat uit van een station dat een connection request (CR) commando verstuurt. Dit commando bevat in elk geval een door de aanvrager gekozen source reference en, in het vanabele deel, de beide TSAPs, van source en destination. Verder kan er tot 32 bytes user data meegestuurd worden, hetgeen handig is bij de verstunng van een connectie aanvrage van een hogere orde protocol. Bij ontvangst van een CR zal de ontvangende partij de source reference van de zender opslaan als destination reference. Het kiest zelf een eigen source reference dat het in een connect confirm (CC) pakket terugstuurt aan de aanvrager van de TC. De CC bevat de source reference van de aanvrager, het TSAP paar, en mogelijk ook user data. Een aanvrager die een CC ontvangt waarvan het destination reference veld overeenkomt met de source reference die de aanvrager eerder opgestuurd had, weet dat het totstand komen van zijn VC succesvol verlopen is. Indien de TC om een of andere reden niet opgezet kan worden, dan zal de ontvanger antwoorden met de versturing van een disconnect request (DR) met opgave van de reden van afwijzing. Het protocol schnjft voor dat een TPDU tijdens data transport een zekere maximum grootte niet te boven mag gaan. Dit maximum wordt bij het opzetten van de TC afgesproken en mag 128, 256, 512, 1024 @f 2048 bytes bedragen. Omdat de Link 1aag een data veld van maximaal 1497 bytes toestaat, en de transport laag direkt op de link 1aag wordt afgebee1d, wordt hier voor 1024 bytes gekozen. De logische eenheid van data die bij de transport 1aag ter verstunng wordt aangeboden is de TSDU. Bij transmissie van data wordt deze in de header van het data transfer (DT) commando afgebakend door een "end mark", het EOT veld. Heeft deze de waarde een dan vormt de meegestuurde data het einde van een TSDU (hier msg. genoemd). De zendende partij bewaart a1tijd copieen van verzonden data totdat deze door de ontvangst van een acknowledge pakket (ACK) bevestigd worden. Een ontvanger za1 alleen bij de ontvangst van een ongeschonden TPDU hiervoor een ACK terugsturen. Constateert de ontvanger via het checksum veld, dat een TPDU niet in orde is, dan wordt deze verworpen en blijft de versturtng van een ACK uit. De zendende partij herkent dit door het afiopen van een timer en zal vervolgens overgaan tot hertransmissie van de TPDU in kwestie. Elke TPDU heeft een 16 bits checksum veld. Deze bevat de som van alle TPDU bytes volgens one's complement berekening en wordt ingevuld v1ak voor versturing van de TPDU. Als de ontvanger bij ontvangst van het TPDU een andere checksum berekent dan in het checksum. veld meegestuurd werd is er tijdens de transmissie verminking van data opgetreden.

- 15 -

Behalve door data verminking kunnen er ook fouten ontstaan door het verlies van TPDUs. Door gebruik te maken van sequence nummer velden wordt voorkomen dat ACK TPDUs de verkeerde TPDUs bevestigen en dat duplikaties van TPDUS die kunnen ontstaan door het kWijt raken van een ACK pakket, worden ontvangen. Elk data- en elk ACK TPDU is voorzien van een sequence nummer. Deze worden ingevuld aan de hand van een tweetal sequence tellers. een send sequence teller en een receive sequence teller die voor elke YC op beide stations mooten worden bijgehouden. De nummeIing ver100pt modulo 2 31 • Aan de send sequence teller en de waarde van zijn credit (zie verderop) ziet de zendzijde van een station of het een bepaald TPDU al mag versturen. Aan zijn receive sequence teller ziet de ontvangende zijde van een station of een net binnengekomen TPDU op volgorde ligt. Dit is alleen dan het geval als het sequence nummer van de ontvangen TPDU gelijk is aan de stand van de receive sequence teller van de ontvanger. Met het ACK pakket deelt de ontvanger aan de zender mee wat de stand van zijn receive teller is. Om te verhinderen dat een langzame ontvanger overspoeld wordt met data van een snelle zender vindt zogeheten receiver back pressure plaats door het tookennen van credit door de ontvanger aan de zender. Deze credit drukt de bereidheid van de ontvanger uit om op het desbetreffende YC een hooveelheid data tot en met de waarde van de credit te ontvangen. De credit wordt uitgedrukt in TPDUs en met een ACK pakket teruggestuurd naar de zender. Het is niet noodzakelijk dat een ACK TPDU een credit ongelijk nul met zich meedraagt. Credit waarden kunnen ook met CR en CC frames worden meegestuurd. Op deze manier ontstaat er bij de zender. per YC. een transmit window. Dit is de verzameling van opeenvolgende data TPDUs waarvoor toestemming tot verzending verleend is. De window wordt bepaald door de transmit sequence teller en de waarde van de credit die op het desbetreffende YC werd verleend. • Als bescherming tegen onverhoopte verbreking van een netwerk verbinding houdt de transport laag van elk station een inactivity tijdsinterval bij. Als er tijdens de duur van dit interval helemaal niets over een YC binnenkomt zal verondersteld worden dat de tegenpartij onklaar is geraakt. Er wordt dan overgegaan tot ontbinding van de TC. Om te voorkomen dat YCs tijdens perioden van weinig data verkeer onterecht worden afgebroken. moot elk station periodiek ACK pakketten versturen om aan te geven dat de verbinding in orde is. Door gebruik te maken van het Expedited data mechanisme kunnen data pakketten van maximaal 16 bytes worden verstuurd, parallel aan de reguliere datastroom op een Vc. De expedited data stroom (ED) heeft een eigen sequenCing en flow control mechanisme. Een station dat een ED pakket ontvangt zal reageren met de versturing van een Expedited data acknowledge TPDU (EA). Het zendende station mag pas overgaan tot versturing van een volgende ED pakket als de voIige door de ontvangst van een EA pakket bevestigd is. Het expedited data mechanisme is hier nog niet ingevuld. Een station geeft te kennen dat het een TC wenst af te breken door de versturing van een Disconnect Request (DR) commando. Deze TPDU is aan de gewone hertransmissie regels onderworpen en mag tot 64 bytes user data

- 16 -

bevatten. Dit commando moet beantwoord worden met een Disconnea Confirm (DC) TPDU, die geen user data mag bevatten en eenmalig wordt verzonden.

2.2.3 COMPATIBILITEIT

Het oorspronkelijke streven was om een communicatie pakket te ontwerpen dat in aUe opzichten overeen zou komen met de ECMA standaards zoals beschreven in de voorgaande paragrafen. Algauw is echter dUidelijk geworden dat deze taak te omvangrijk was voor het projekt. Om klasse 4 van het transport laag protocol te realiseren schrijft ECMA voor dat ook aUe daaronder gelegen klassen geimplementeerd moeten worden. Dit is noodzakelijk omdat bij de onderhandelingen die gevoerd worden bij het opzetten van een VC onder andere afgesproken wordt welke servire klasse men zal hanteren. Indien een station met slechts beperkte mogelijkheden wil communireren via een lagere protocol klasse dan moet het ontwerp hierop in kunnen gaan en de lagere protocol klasse uitvoeren. Het onderbrengen van aUe transport service klassen binnen het ontwerp werd als te omvangrijk bevonden en nadat ina 960 zich aandiende ook niet meer als zinvol beschouwd. Toen werd besloten om van koers te veranderen en niet langer aan een "copie" van ina 960 te werken maar een pakket te ontwikkelen dat weliswaar niet langer ECMA compatibel, maar door zijn compactheid, begrijpbaarheid en vooral effidency toch aantrekkelijk zou zijn. Een van de belangrijkste punten die tot deze verhoogde efficiency leiden is het ontbreken van buffering in de T-laag. De uitgebreidheid van de ECMA normen maakt buffering binnen vrijwel elke laag tot een noodzaak opdat de ingewikkelde handelingen die de protocoUen voorschrijven kunnen worden verricht. In dit ontwerp worden met name de funkties van de ECMA transport servire verricht zonder buffering in de T-laag, en voor een deel op meer effidente wijze. 20 is er het voorbeeld van de flow control. Deze werkt via credit toewijzing door de ontvanger welke volgens ECMA norm op TPDU basis geschiedt. Maar dit betekent dat per toegekende credit, aan ontvangstzijde buffer resources van ten minste de maximale grootte van de TPDUs (1024 bytes) moet worden gereserveerd, terwijl de TPDUs in kwestie mogelijkerwijs van veel kleinere omvang zijn. Op die manier worden resources verspild en de throughput van andere stations belemmerd. Dit ontwerp verleent credit op basis van eenheden van 64 bytes en gaat daarbij expliciet uit van het data verkeer dat over een VC zal stromen. De zender informeert de ontvanger over de data stroom zodat buffer resources bij de ontvanger optimaal op de wensen van de zender kunnen worden afgestemd. Het komt erop neer dat volgens de ECMA norm een variabel aantal TPDUs van constante grootte overeenkomstig een verleende credit mogen worden verstuurd, terwijl dit ontwerp voorschrijft dat steeds een TPDU van vaIiabele grootte al naargelang de uitstaande credit zal worden verstuurd. Dit brengt bovendien een veel eenvoudigere administratie aan ontvangstzijde voor wat betreft de sequencing met zich mee. Immers er zal steeds precies een TPDU uitstaan. Er kan geen sprake zijn van TPDUs die te vroeg aankomen. WeI

- 17-

kunnen duplikaten voorkomen ten gevolge van het verlies van ACK frames. Een andere omstreden kwestie is het weI of niet ondersteunen van datagram service. Dit is een mechanisme waarbij data pakketten parallel aan eventueel bestaande VCs worden verstuurd. Zo wordt verhoging van de throughput ten koste van verminderde zekerheid omtrent de afievering van berichten bereikt. Datagram service gaat bUiten de ECMA transport protocol om en is derha1ve niet a1s integraal onderdeel van het ontwerp opgenomen. Daarentegen zijn er situaties waarbij een dergelijk mechanisme zeer voordelig is (de versturing van korte eenmalige berichten), en is daarom besloten het als "eventuee1 mee te nemen optie" te behandelen. Tot slot voIgt een opsomming van de andere punten waarin dit ontwerp van de ECMA norm afwijkt: - Er wordt gewerkt met "gewogen" credit waarden in plaats van absolute credit toewijzing (een credit komt overeen met 64 bytes). - De laatste stap van de three way handshake voor het opzetten van een VC is weggelaten (ECMA verordent dat een VC pas bestaansrecht hoot nadat de aanvrager na ontvangst van het CC frame een eerste TPDU naar de andere partij hoot verstuurd). - Er worden geen onderhandelingen ten aanzien van service kIasse of te gebruiken parameters of opties tijdens het opzetten van een VC verricht. - Er is geen expedited data serVice ingevu1d. - Er vindt geen concatenatie van TPDUs binnen een frame plaats. - Het hanteren van een frozen state is achterwege ge1aten. (references die door ontbinding van een VC weer vrijkomen mogen pas na zekere tijd weer worden gebruikt o~ verwarring te voorkomen). - Er wordt geen checksum berekend op T-laag nivo aangezien de L-Iaag checksum voldoende beveiliging biedt.

2.4 DE INTEL 82586 LAN CONTROLLER

Hier wordt aIleen ingegaan op de basiswerking van de LAN controller, voor zover deze voor een goed begrip van het LAN software ontwerp van belang is. Voor een gedetaileerde beschrijving van de 82586 LAN co-processor wordt verwezen naar lit. 4. De belangrijkste funkties van de 586 zijn in drie groepen te verde1en: - Interaktie met de 186 host CPU - Zend funkties - Ontvangst funkties De 586 verstuurt data uit een dual ported geheugen over het netwerk en plaatst vanaf het netwerk ontvangen data terug in het geheugen. Dit data transport gebeurt op frame basis. Frames zoa1s beschreven in § 2.2 worden door de LAN controller geconstrueerd met de gegevens die het van de 186 krijgt, en na

- 18 -

CHANNEL ATTENnON

CJ'U

CA

INTERRUPT

8:l.586

INTR

..::; ::::..

.c:. .:::..

SHARED MEMORY

IHtl1AUZAnDN ROOT

•

~

SYSTEM CONTROL BI.OCK (SCI): "MAILBOX"

V

i

J1

i

RECEIVE FRAME AR£A

l'l

COMMAND LIST

frguur 2.2 shared memory & interaktie

IHlnALIZATIOH ROOT

_COM~UST...e!LI

STATUS COMMAND COllMAHOUST

RECEIVE FRAME POINTER

I

I I

L

-RECEIVEFRAMEAR£A (iifAj

r-

~":;';?_"NI

1_1 frguur 2.3 resources struktuur

- 19 -

I I --l

ontvangst geinterpreteerd en doorgegeven aan de CPU. De framing operaties die de 586 11itvoert hebben betrekking op de volgende velden (zie figuur 2.1): Preamble, start of information, dte adressen, LLCDU count, PAD, FCS en EOF. Het data veld wordt ingevuld met data die door de 186 in transmit buffers is klaargezet. Aan ontvangstzijde kijkt de 586 naar alle frames die langskomen. Het zal alleen die frames doorgeven aan de CPU die aan deze geadresseerd zijn en foutvrij werden ontvangen. Het adres kan daarbij specifiek op deze ene LAN kaart zijn gencht, het kan een groepsadres (Multicast) of een broadcast adres (aan alle stations) zijn. De 586 herkent de volgende foutsituaties: FCS error ten gevolge van incorrecte data of framing informatie. - een te kort frame. - ontbrekende EOF delimiter. - overrun: de frame kon niet in het geheugen worden opgeslagen omdat de systeembus de inkomende data niet kon bijhouden. - onvoldoende buffer resources: de receive buffers van de 586 zijn allemaal bezet. De communicatie tussen 586 en host verloopt via het shared geheugen waartoe de 586 direct memory acres heeft. 20 kan het transport van data blokken parallel aan de werking van de CPU plaatsvinden. De 586 bestaat uit een command unit en een receive unit die zich respectievelijk bezig houden met de uitvoering van commando's van de command list en het opbergen van ontvangen frames, beide in het shared geheugen. De 186 hoeft pas in te grijpen als een reeks commando's zijn u:itgev<Jerd of een reeks frames zijn ontvangen. Het shared geheugen bestaat uit een initialisatie blok, het system control block (SCB), een commando lijst en de Receive Frame Area (RFA, zie figuur 2.2). Het initialisatie blok wordt bij het booten van het station uitgelezen om de locaties van de andere strukturen te achterhalen. Centraal staat het SCB dat als mailbox tussen CPU en 586 functioneert. Via deze worden control en status informatie tussen beide uitgewisseld. Bovendien bevat het pointers naar de commando lijst en RFA (zie figuur 2.3). Tussen CPU en 586 lopen slechts twee hardware signalen, een interrupt en een Channel Anention (CA). De 586 activeert de interrupt lijn om de processor op de hoogte te brengen van een verandering in het SCB, bijvoorbeeld de melding dat een commando uitgevoerd of een frame ontvangen is. Met de CA trekt de CPU de aandacht van de 586, bijvoorbeeld om het uitvoeren van een zend commando te initieren. De 586 voert commando's uit die door de processor in een commando lijst zijn klaargezet, als een soort programma als het ware. Deze zijn vervat in commando blokken (CBs) waarvan het belangrijkste wellicht het transmit commando is. Dit blok bevat frame informatie zoals adressen en count veld en een pointer naar een lijst van gelinkte buffers die de te versturen frame bevatten en kns kras over het geheugen kunnen zijn verspreid (zie figuur 2.4). De eigenlijke data staat in transmit buffers (TBs), die een willekeunge grootte hebben en overal in het geheugen kunnen staan. Daarom hoort bij elke TB een transmit buffer descriptor (TBD) die informatie over het waar en hoeveel van

- 20-

de te versturen buffer bevat (figuur 2.4). De TBDs van ren frame zijn aan elkaar geUnkt en worden zelf geadresseerd via het transmit CB (zie figuur 2.3). Receive buffering gebeurt op soortgelijke wijze. De RFA bevat een lijst van vrije frame desriptoren (FOs) en een lijst van vrije buffers (RBs). elk vergezeld van een receive buffer descriptor (RBO). Als een frame binnenkomt dan zal de 586 de benodigde frame informatie in een FO invullen en genoeg RBDs en RBs reserveren om de data van het frame te bevatten. De Adres informatie komt met een pointer naar de data buffers in de PO te staan (zie figuur 2.5). Eike bij een buffer behorende RBO wordt ingevuld met informatie betreffende de Iokatie van de buffer en de hoeveelheid opgeborgen data (figuur 2.5). Opdat een frame in zijn geheel kan worden ontvangen is het nodig dat er genoeg RFA resources beschikbaar zijn. Er moet een PO vergezeid van genoeg RBDs en RBs om de data te bevatten vrij zijn. De 586 eigent zich automatisch genoeg RBs uit de RFA toe. maar het is de link Iaag software die ervoor moet zorgen dat er continu genoeg vrije resources beschikbaar zijn. Het is daarom belangrijk dat gebrUikte receive resources zo gauw mogelijk weer vrijgemaakt worden om ze daarna te kunnen retourneren aan de RFA. Een soortgelijke situatie doet zich voor bij het invullen van commando biokken. De link Iaag neemt de benodigde commando resour,ces uit een vrije lijst en prepareert ze voor de 586. Het is belangrijk dat na uitvoering van het commando de L-laag software ervoor zorgt dat de weer beschikbaar gekomen resources teruggegeven worden aan de vrije lijst. o

IS

C

8

MAXCOI.L

OK

LINK OFfSET

TBD OFFSET I

2ND BYTE

1ST 8YTE

Me::

•

I A

DESTINATION AODRESS ~_.:.:.NT.:.:.H:.:8~Yn~

L--

I ......J.I

TYPE FIELD

""18 --'C

o

11

EOF

ACT COUNT

o

1---J-'-i...l:L---L_...L.._.L..--I.._...L...---JL..---L.._...L---J_--L.._I.----'-_-'---1 (STATUS) NEXT TID OFl'SET

I-----------------------------i

2

BumR ADOAESS

LL..:.Lt..J..J..'-I-(..J..j'...J..J...Li-.LL.J..J..L.L.Li...I.'...J..J.:.LI.

figuur 2.4 transmit command biok en - 21 -

....... •

transmit buffer descriptor

0

15

C

B

EL

S

0 (STATUS)

2 LINK OFFSET

4

R8000FFSET

6 1ST BYTE

2NOBYTI! DESTINATION AODRESS

MC

8 10

NTH BYTE

12 1ST BYTE

2ND BYTE SOURCE ADDRESS

14 16 18

NTH BYTE 1ST BYTE 2ND BYTE

TYPE FIELD

15 EOF

20

0 ACT COUNT

NEXT RBD OFFSET

0 [STATUS)

2

BUFFER ADDRESS

8 A23

SlZI!

figuur 2.5 frame descriptor en receive buffer descriptor

- 22 -

•

HOOFDSTUK 3 HETONTWERP

3.1 HEr LAGENMODEL

Bij het ontwikkelen van de LAN software is ervoor gezorgd dat de struktuur ervan overeenkomt met het ISO OSI lagenmodel voor datacommunicatie. In dit model verzorgen de onderste vier lagen (transport laag, netwerk laag, link laag en fysische laag) de typische communicatie georienteerde funkties, terwijl de bovenste drie lagen (sessie laag, presentatie laag en applicatie laag) zich al met data processing beZig houden. Het ontwerp dat hier behandeld wordt omvat het geheel van data commurucatie funkties met daar een klein beetje data processing bovenop. Het ISO lagenmodel is een standaardmodel dat juist tot doel heeft vele verschillende toepassingen onder een noemer te brengen en de verschillende implementaties compatibel te maken. De aard van de toepassing schrijft voor welke funkties weI en niet benodigd zijn en bepaalt de implementatie ervan. De toepassing waar het hier om gaat is een Local Area Network voor de THE KUNix machine. Voor een LAN zijn de funkties van de netwerklaag niet benodigd. Immers het LAN is een opzichzelf staand fysisch geheel dat aIleen van internetworking funkties gebruik zal maken als het via een gateway op andere netten wordt aangesloten. De struktuur van de hier ontworpen communicatie software wordt in figuur 3.1 vergeleken met het ISO lagenmodel.

figuur 3.1 lagenmdellen

APPlic.AT io N P R.e:~EN TA.Tio N SE5Sio~

TRAN5?ORT

TR.ANSPORT

NaT

N ET'N'ORK

LIONK -p Htsic.A L

I.so

Kut-JiX

- 23 -

Vanwege de aard van de KUNix machine is hier een Interface laag bovenop de transport laag (verder aan te dUfden als T-laag ) aangebracht. Met de architectuur van de KUNix machine in het achterhoofd (Een LAN interface 110 kaart die via een VME bus met een host communiceert) is deze laag ingericht om toegang tot het netwerk en met name de netwerk communicatie funkties te bieden. Data en commando's worden hier gebufferd op voor de host transparante wijze. In dit licht bezien verzorgt deze laag dus een deel van de ISO applicatie laag funkties. namelijk de interface tussen applicatie en netwerk. Een applicatie zou met het hier gebodene al op het netwerk kunnen werken, maar voor een meer geavanceerd systeem is de invulling van sessie en presentatie laag funkties benodigd. Ueze funkties zouden, juist vanwege hun data processing karakter, zowel bij de remote host ergens op de VME bus, als lokaal op de LAN kaart, bovenop de I-Iaag, aangebracht kunnen worden. Dit ontwerp beperkt zich niet tot het geval van een remote applicatie op de VME bus. De applicatie zou net zo goed, en nog veel eenvoudiger, lokaal op de 80186 LAN interface kaart kunnen draaien. De software zou zelfs op een volkomen ander systeem geimplementeerd kunnen worden waar van een heel andere host sprake kan zijn. Het zal dUidelijk zijn dat de top van de I-laag een zeer implementatie afhankelijke zaak is. Daarom zijn in deze laag alleen die zaken vastgelegd die voor een goede werking van het net vereist zijn, en kunnen de zaken die met de host communicatie te maken hebben op de betreffende applicatie worden afgestemd. Dit is precies de grens die het uniforme communicatie georienteerde software pakket, dat op elk netwerk station gelijk is, scheidt van het applicatie afhankelijke deel van de LAN software. De opzet van de I-Iaag is niet het uitvoeren van een applicatie laag protocol maar een applicatie een aantal primitieven te bieden waardoor het op het LAN kan werken. Een kernverzameling van primitieven is onmisbaar om bberhaupt het LAN te kunnen gebruiken, een deel ervan komt de efficientie ten goede en een paar zijn er voor het gebruikersgemak. De I-laag primitieven zijn als voIgt: voor data: SEND (source host, dest. host, data adres, data size) RECEIVE (data adres, data size, dest. adres) voor de connectie: CONNECT (source host, dest. host) DISCONNECT (source host, dest. host) AWAIT CONNECT (source host) CANCEL AWAIT (source host) voor netwerk administratie: BIND (source host) UNBIND (source host) LIST (dest. adres) RESET (source host) De T-laag biedt betrouwbare connectie georienteerde data communicatie service. In overeenstemming met het ECMA protocol verloopt de communicatie over virtuele circuits. Het beheer van deze VCs en daannee het zorgdragen voor foutvrije, sequentiele, op maat gesneden datacommunicatie gebeurt binnen de

- 24 -

T-laag. Een applicatie heeft toegang tot de T-laag via een Transport Service Access Point (TSAP). De TSAP vormt het uiteinde van een VC en biedt twee applicatiES de mogelijkheid om elkaar te adresseren. Hoewel elke applicatie op een netwerk station achter een unieke TSAP zit wordt dit uiteraard niet voor de fysieke adrESSering van de applicatie gebruikt. Daartoe dient er een extra vertaalslag te geschieden die via de Naam TabeL (NT) verloopt, ondergebracht in de I-laag. Met de naam tabel kunnen applicatie namen van- en naar fysieke adrESsen of van- en naar TSAPs vertaald worden. In dit hoofdstuk wordt tevens aangegeven hoe een datagram service gerealiseerd zou kunnen worden. AangeZien deze buiten de ECMA norm omgaat is het niet de bedoeling dat dit een onderdeel van het communicatie software pakket wordt, tenzij daar behoefte naar ontstaat. Dit is een data communicatie mechanisme dat niet over virtuele circuits gaat en bedoeld is voor relatief kleine pakketten data die met een minimaal oponthoud over het net dienen te worden verstuurd. Enerzijds wordt door het ontbreken van een VC protocol tijdwinst geboekt bij de versturing van een pakket, maar anderzijds kan niet meer gegarandeerd worden dat het pakket foutvrij aankomt. Indien dit van belang is dan kan bovenop de datagram service een .protocol mechanisme opgenomen worden die weI foutvrije transmissie garandeert. De primitieven van de T-laag zijn afgeleid van die van de I-laag en luiden als voIgt: DTRFR (data versturing) CRQ (VC aanvrage) DRQ (VC afbreken) AW CON (VC reserveren) (gereserveerde VC terugnemen) CAN AW en eventueel: DGRAM (datagram versturing) De Link Laag verzorgt versturing en ontvangst van data frames. Daarbij wordt

weI gegarandeerd dat afgeleverde frames correct zijn, maar niet dat opgestuurde framES aan zullen komen, en als ze arriveren dat dit in de juiste volgorde is gebeurd. De funkties van de link laag worden grotendeels door de 82586 LAN controller in hardware uitgevoerd. De belangrijkste taak van de L-laag software is ervoor te zorgen dat de 82586 van voldoende rESources in de vonn van buffers en dergelijke wordt voorzien.

3.2 HEr RAAMWERK

3.2.1INLEIDING

In dit hoofdstuk wordt het ontwerp stukje bij beetje opgebouwd. Daarom wordt in deze paragraaf begonnen met het beschrijven van het raamwerk (zie figuur 3.2) waar in de volgende paragrafen steeds meer aan toe zal worden'

- 25-

gevoegd. Elk station kan verdeeld worden in een zend- en ontvangst zijde, respectievelijk boven- en onderaan in de figuur te zien. Verder zijn de lagen van hoog naar laag in de figuur van links naar rechts weergegeven.

ITBUF

NAAM TA8EL

IRBUF

•

figuur 3.2 het raamwerk

Ais de I-laag opdracht krijgt om een bericht te versturen dan zal het deze eerst overnemen in zijn eigen lokale ITBUF (interface transmit buffer) ruimte. Vervolgens wordt de T-laag geseind dat er data verstuurd moet worden met vermelding van de bestemming. De T -laag leidt af over welk VC het transport zal gaan en construeert dienovereenkomstig een header in een lokale transport laag buffer (TBUF). Dan wordt de link laag aangeroepen met de opdracht om data en header naar de gewenste bestemming te verzenden, hetgeen door de 82586 wordt uitgevoerd. , De ontvangende partij slaat deze frame op in zijn 82586 receive buffers (RBs) en genereert een interrupt. De geactiveerde interrupt handler controleert dat de ontvangen frame in orde is· en waarschuwt de T-laag dat er werk aan de winkel is. De T-laag kijkt over welke VC het frame binnengekomen is en construeert een Acknowledge (ACK) bericht. Door aanroep van de L-laag zendzijde wordt deze over het VC teruggestuurd naar het zendende station ter bevestiging van de ontvangen frame. Zou da niet gebeuren dan zou de zendzijde als gevolg van het afiopen van een timer op het verstuurde pakket tot hertransmissie hiervan overgaan. Op deze manier wordt er gewaakt tegen het verloren gaan van data frames op het net. Het gevolg is dat de ontvangende T-

- 26-

laag ook regelmatig Ack-pakketten binnenkrijgt. De ontvangst van deze wordt meteen doorgemeld aan de zendzijde opdat de desbetreffende timer stopgezet en hertransmissie voorkomen kan worden. Gaat het echter om een "gewone" data frame dan kijkt de T-laag waar het in de Interface receive buffer (JRBUF) thuishoort en verzoekt de L-laag vervolgens om de data hier naar toe te copieren. Is dit eenmaal gebeurd dan kunnen de gebruikte 82586 receive buffers weer vrijgegeven worden en kan, indien nodig, de I-laag of de geadresseerde host op de hoogte worden gebracht van de ontvangst van data.

3.2.2 BUFFERORGANISATIE

De vorige paragraaf bevat de essentie van het ontwerp maar zit nog vol met

concepten en termen die om een nadere toelichting vragen. Een daarvan is de kwestie van buffering en dataorganisatie. De opzet is om zo weinig mogelijk tijd en geheugenruimte te verliezen door het copieren van data van het ene buffergebied naar het andere. Dit wordt met name bereikt door af te zien van data buffering in de T-laag. Data wordt op twee plaatsen gebufferd, in de I-laag en in de L-laag. Globaal gezegd heeft de data in de I-laag de struktuur zoals de host deze wil hebben en in de L-laag de struktuur die de 586 benodigt. De organisatie van data is zodanig dat er binnen het ontwerp sprake is van drie eenheden van data. Bij de applicatie, op het nivo van de host, wordt de term file als dataeenheid gehanteerd. Dit begrip omvat elk logisch datageheel dat op een host betrekking heeft, van een kort bericht tot een groot bestand. Het zal niet altij<1 mogelijk zijn om op een LAN kaart een complete file in behandeling te hebben, zeker als het om een groot bestand gaat. Daarom is hier de dataeenheid message (msg) ingevoerd. Dit is de eenheid van data zoals het bij het LAN station vanaf de host binnenkomt en aan ontvangst zijde ook weer verlaat. Er wordt pas met de fysieke transmissie begonnen als een complete msg op de LAN kaart aanwezig is, en aan ontvangst zijde worden de I-laag en de geadresseerde host pas gewaarschuwd als de msg in zijn geheel correct is ontvangen. Op T-laag nivo is er tenslotte sprake van een blok. data. Dit is de eenheid data die als afzonderlijke frame over het net gaat, en dus ook de dataeenheid die aan het T-laag flow control mechanisme onderhevig is. 20 is het mogelijk dat een msg als een verzameling afzonderlijke blokken verzonden wordt, of in een keer in zijn geheel. Dit is afhankelijk van de grootte van de msg en de bufferings capaciteit van het ontvangende station dat de flow control regelt. In de I-laag bevinden zich twee grote data buffers, een transmit en een receive buffer, de Interface transmit buffer (ITBUF) en de Interface receive buffer (IRBUF). Dit om te voorkomen dat een enkele buffer vol zou lopen met te versturen data en daardoor niet meer in staat zou zijn om van het net binnenkomende data te ontvangen. Beide zijn op predes dezelfde wijze georganiseerd. Het zijn lineaire buffers waar msgs in hun geheel, achter elkaar,

- 27-

worden opgeslagen (zie figuur 3.3). De msgs worden in de buffer voorafgegaan door een bijbehorende descriptor, Interface transmit descriptor (lTD) of Interface receive descriptor (IRD). Deze bevatten infonnatie over source en destination van de msg en hoever de transmissie/ontvangst van de msg al gevorderd is. Bij het aanbieden van een nieuwe msg wordt in de ITBUF genoeg ruimte gereserveerd om de hele msg te bevatten (inclusief descriptor). Pas dan kan worden begonnen met het overnemen van de msg. Daarom is er vooraan in het datagebied van de msg een size veld opgenomen die de ontvanger van een nieuwe msg op de hoogte brengt van hoeveel data er nag gaat komen.

> Gte:8iEC

I figuur 3.3 I-laag buffer

ITfiR!>T

)

'I.TO

I S~

J

'" 50. -1

)

I o.rSiEC

I

I'\~e:.

2.-

.II:

De allocatie van bufferruimte aan msgs kan men zo geavanceerd uitvoeren als men wil. Het komt neer op het probleem van het onderbrengen van segmenten van variabele grootte in een lineaire buffer. Men dient weI te beseffen dat hoe vernuftiger men de bufferorganisatie maakt, hoe meer de administratie ervan gaat kosten. Hier is, in overeenstemming met de doelstelling van het ontwerp, een zeer simpele techniek toegepast. Het uitgangspunt is dat een nieuwe msg in een van de twee in figuur 3.3 aangegeven gebieden moet worden ondergebracht, in gebied I, voor de eeISte msg, of in gebied 2 na de Iaatste msg. Krijgt de msg eenmaal ruimte toegewezen dan wordt er een descriptor geconstrueerd dat Via next en previous velden aan de voor- of achterkant van de dubbel gelinkte lijst van descriptoren wordt toegevoegd. Komt de ruimte waar een msg staat weer vrij dan is dit een kwestie van het aanpassen van ITFIRST of ITLAST als de msg aan de rand van het bezette gebied zit. Is dit niet zo dan wordt enkel een status bit in de descriptor geset en komt de ruimte pas vrij als de msg door het vrijkomen van andere msgs aan de rand van het bezette gebied komt. Een te versturen datablok wordt doorgegeven aan T- en L-Iaag middels een pointer naar de plaats waar het zich in de ITBUF ruimte bevindt~ Door deze pointer door te geven aan de Transmit buffer descriptor van de 586 (TBD, zie hoofdstuk 2) gaat het datablok direct vanuit de ITBUF het net op, zonder interne copieerslagen. Aan ontvangstzijde is de bufferruimte van de 586 georganiseerd in buffers van 64 bytes. Als een groter blok binnenkomt dan zal

- 28 -

de 586 automatisch beslag leggen op voldoende Receive buffers (RBs) om het blok te kunnen bevatten. Er is voor deze dimensionering gekozen uit de overweging dat hiermee veel van het dataverkeer in ren transmissie kan worden afgehandeld. Het merendeel van het verkeer op een typisch netwerk bestaat uit korte berichten, commando's, status meldingen en dergelijke over een bestaand Vc. Het komt de efficientie ten goede als deze in ren keer over het net kunnen worden getransporteerd zonder daarvoor overvloedig veel bufferruimte te moeten reserveren. Daarmee is deze 64 bytes de atomaire eenheid van credit. Credit toewijzing zal altijd geschieden in veelvouden van 64 bytes waarbij de hoeveelheid van nog te versturen data in de msg en de beschikbare receive buffers op een gegeven moment, bepalend zijn voor de absolute credit toewijzing.

3.2.3 CONNECTIES

Datatransport gebeurt binnen de T-laag op connectie georienteerde basis over zogeheten virtuele circUits (VCs). Virtuele circUits verbinden twee applicaties via hun TSAPs en vormen het mechanisme dat garandeert dat wat de ene partij verstuurt uiteindelijk foutvrij en op volgorde bij de andere zal aankomen: Ze kunnen beschouwd worden als tweeweg communicatie kanalen waarover data blokken worden getransporteerd die onderheVig zijn aan credit toewijzing, time out en hertransmissie (flow control), en sequencing. Voordat data transport kan beginnen moet een dergelijke VC worden opgebouwd en na gebrUik moet het ook weer worden afgebroken. Hoe dit dient te gebeuren wordt voorgeschreven door het ECMA transport laag protocol (zie hoofdstuk .2). Bovendien kunnen meerdere VCs tegelijkertijd op ren TSAP aktief zijn. Om dit alles te administreren is in de T-laag een connectietabel (CTAB) opgenomen waarin elke VC beschreven staat. Hoeveel VCs er tegelijkertijd in bedrijf mogen zijn hangt af van twee zaken: ten eerste kunnen de resources die op een bepaald station aanwezig zijn (buffers) de beperkende faktor vormen. Omdat VCs direct tussen hosts lopen bepaalt ten tweede het vermogen van de hosts om het verkeer op meerdere VCs te ondersteunen hoeveel VCs er maximaal op ren TSAP aktief mogen zijn. Daarom verloopt het opzetten van VCs via een posting mechanisme. Dit houdt in dat voordat een host op een VC kan worden aangesloten deze aan moet geven dat hij in principe bereid is om dat VC te ondersteunen. Via een AWAIT CONNECT commando geeft een host deze bereidheid te kennen, hetgeen via zijn TSAP in de CTAB wordt geregistreerd. Aanvragen voor het opzetten van VCs, zowel van de eigen lokale host als die van een remote host op het net, zuHen dan ook alleen succes hebben als er een vrije VC bij het aangevraagde TSAP aanwezig is. Voordat begonnen kan worden met het versturen van een msg moet de host van wie de msg afkomstig is expliciet een connectie aanvragen. Dit wordt binnen de I-laag vertaald naar een aanvrage voor een vc. De VC komt alleen tot stand als zowel op het eigen station als op het station van bestemming vrije VCs bij de desbetreffende VCs aanweZig zijn. Het totstand komen van de

- 29-

verbinding wordt teruggemeld aan de aavrager en deze kan nu overgaan tot het versturen van data. Pas als het eerste blok data verstuurd gaat worden zijn alle velden van het VC in de CTAB ingevuld. Deze zijn als voIgt: (de funk ties van de diverse velden komen later aan de ordeJ TSAPL TSAPR sref dref dteR Imptr IRDptr CDT ACTIM DTTIM RETCNT RECSEQ TRSEQ NEXT PREY

adres lokale applicatie adres remote applicatie adres lokale uiteinde VC adres remote uiteinde VC adres van remote station ITBUF descriptor pointer IRBUF descriptor pointer credit timers retry count sequence nummers link naar volgende VC link naar voorafgaande VC

Men dient onderscheid te maken tussen een connectie op applicatie nivo en de virtuele circuit verbinding binnen de T-laag. Eerstgenoemde wordt in de I-Iaag vertaald in een VC connect request (CR) en in het data veld van deze over het net verstuurd. Een eventuele connect confirm (CC) van het remote station geeft aan dat het VC op T -laag nivo is opgezet, maar betekent nag niet dat de verbinding die de aanvragende host wenst, tot stand is gekomen. Daartoe moet er eerst van de remote host een connect confirm uitgaan die als gewone data over het VC wordt verstuurd en door de I-laag doorgegeven wordt aan de aanvragende host. De administratie rond deze connecties en de bewaking ervan is een zaak van de applicatie laag en dient in het applicatie laag protocol gerealiseerd te worden. Bij het aanvragen van een connectie hoort onlosbrekelijk het na verloop van tijd weer afbreken ervan. Op welk moment dit gebeurt is weer afhankelijk van de applicatie. Er zijn allerlei applicaties denkbaar die om het opzetten van een connectie kunnen vragen, maar de volgende twee uitersten zijn illustratief voor hoe deze zaak kan verlopen: ten eerste kan gedacht worden aan een gebruiker die een terminal sessie via het netwerk wi! aangaan. Hij zal een expliciete aanvrage voor een connectie met een remote host geven. Ais gevolg hiervan wordt een VC opgezet en pas als de sessie afgelopen is wordt de connectie afgebroken. Dit gebeurt wederom door een expliciete aanvrage en leidt vervolgens tot het afbreken van het Vc. Hier is sprake van een VC dat gedurende erg lange tijd kan blijven bestaan. Anderzijds is het mogelijk dat een applicatie in de vorm van een autonoom programma tijdens het doorlopen hiervan gegevens aan het netwerk kWijt wil of juist gegevens van het netwerk benodigt. Hier zal volstaan kunnen worden met het opzetten van een VC voor de duur van het file transport. Connect en

- 30-

disconnect afhand.eling van de verbinding op applicatie nivo zal door een driver bij de host gerealiseerd moeten worden opdat het applicatieprogramma helemaal van het netwerk gescheiden blijft. Hier is er sprake van een VC dat slechts relatief korte tijd blijft bestaan.

3.2.3 ADRESSERING

Om met elkaar te communiceren zullen twee applicaties elkaar moeten kunnen adresseren. Daartoe moeten, overeenkomstig het lagenmooel, verschillend.e lagen van adressering worden doorlopen. De volledige adres informatie van een applicatie staat in een Naam Tabel (NT). Deze tabel is ondergebracht in de 1laag van elk station. Op de eerste plaats moet een applicatie vanuit een LAN kaart geadresseerd kunnen worden en moet het zich anderzijds bij de LAN mooule kunnen identiflceren. Dit adres kan afhankelijk van de hoedanigheid van de applicatie vele versehillende vonnen aannemen, maar hoe dan ook, er zal een wijze van communicatie tussen de LAN kaart en de applicatie moeten worden afgesproken. Infonnatie over de manier van communicatie en het adres zelf, verder aangedUid als fysiek adres , staan in de naam tabel. Daarnaast is er de TSAP, de toegangspoort tot het netwerk. Door gebruik te maken van TSAPs om applicaties aan de uiteinden van een VC te koppelen heeft men de mogelijkheid meerdere applicaties via een LAN station op het netwerk aan te sluiten. De TSAP kan gezien worden als het adres waarop de ene applicatie de andere kan aanspreken, als een socket waarachter een bepaalde applicatie schuilgaat. Om op het netwerk toegelaten te worden zal een applicatie dan ook een explidete BIND commando moeten geven. waarmee het een TSAP voor zichzelf aanvraagt. Tenslotte is er nog het station adres, het adres dat een LAN interface kaart van de andere LAN kaarten op het netwerk onderscheidt. Dit dte adres (data terminal equipment) hoort thuis in de link laag en wordt direct geinterpreteerd door de 586. Als een applicatie service van het net verlangt dan zal het in eerste instantie de tegenpartij via een naam specificeren (bijvoorbeeld laserprinter1 ). VanUit applicatie oogpunt bezien, is de naam van de server de sleutel tot de naam tabel. Deze tabel kan ook gebrUikt worden om naast de naam van een applicatie in het kort enkele gegevens over die applicatie op te slaan. 20 heeft een gebruiker de mogelijkheid om door een liST commando aan de I-laag te geven, infonnatie in te winnen over de fadliteiten die tot zijn beschikking staan via het LAN.

3.2.4 RESOURCES

Op verschillende plaatsen in het lagenmooel zijn resources van een of andere aard benooigd voor het transport van data. Het ontwerp is zooanig dat deze

- 31 -

resources zoveel mogelijk op elkaar zijn afgestemd zodat er geen vertraging ontstaat bij het aanvragen van steeds weer nieuwe resources. Het duidelijkste voorbeeld is de grote interface receive buffer. Hier wordt ruimte gereserveerd op msg basis zodat bij de ontvangst van elkaar opvolgende datablokken gegarandeerd is dat deze snel doorgeschoven kunnen worden. Aan de zendzijde zijn de resources nag sterker aan elkaar gerelateerd. Om een blok data te kunnen versturen zijn de volgende resources benodigd: een transportlaag buffer (TBUF) om de header van het blok te bevatten, een timer queue element die waakt tegen het verloren gaan van een frame (zie § 3.6), een 586 command blok (CB) en twee 586 transmit buffer descriptoren (TBDs), een voor de header en een voor het datablok. De TBUF wordt als eerste aangevraagd dus is een dimensionering genomen waarbij de keuze van het aantal beschikbare TBUFs op een station meteen vastlegt hoeveel van de andere genoemde resources er moeten zijn (bij de dimensionering van de 586 resources moet erop gelet worden dat ook van ontvangst zijde het versturen van een data frame kan worden opgestart. Dit gebeurt bij verzending van een ACK frame, met of zonder credit, en een connect- of disconnect confirm frame). Heeft een station N TBUFs dan zal het ook N timer queue elementen, N CBs en 2N TBDs tot zijn beschikking hebben. Aan ontvangst zijde worden de beschikbare resources bewaakt door het credit mechanisme dat de flow control over de VCs regelt. De resources zijn de 586 frame descriptoren (FDs), de 586 receive buffer descriptoren (RBDs) en de 586 receive buffers zelf (RBs). Deze laatste twee zijn direct aan elkaar gekoppeld, bij elke RB hoort ren RBD. Maar een FD beschrijft een frame als geheel en kan dus van 1 tot 1024/64 = 16 RBs bij zich hebben. Bij het bepalen van een nieuwe credit toewijzing zal met deze twee resources afzonderlijk rekening gehouden moeten worden. Er wordt ren teller bijgehouden voor het aantal beschikbare RBs en een andere voor de vrije FDs. Als het totaal aan receive resources weergegeven wordt door N dan geldt steeds voor de tellerstanden: resource teller ... N - aantal afgegeven resources. De afgegeven resources kunnen in drie categorieen worden verdeeld: - afgegeven credit voor data - afgegeven resource voor verwachte ACK frame (horend bij frames die al verstuurd maar nog niet bevestigd zijn). - een vaste reserve voor de ontvangst van data die niet geantidpeerd kon worden. Tot deze laatste groep behoren de connect request frames en eventuele datagrammen. Juist vanwege deze laatste categorie frames kan ongeacht de dimensionering van de bufferruimte nooit gegarandeerd worden dat een frame dat bij een station aangeboden wordt ook meteen ontvangen kan worden. Echter dankzij het hertransmissie mechanisme op T-laag nivo kan met beperkte middelen tijdens normaal bedrijf de aflevering van een verzonden blok data tach worden gegarandeerd. Hoeveel resources een bepaald station moet hebben om goed te kunnen functioneren hangt sterk af van de applicaties die dat station ondersteunt. Het zal duidelijk zijn dat een file server veel meer buffer reserves zal benodigen dan een simpel terminal station. Een veld in het SCB (system control blok) van de

- 32-

586, de resource error tally (deze houdt bij hoeveel correct overgedragen frames moesten worden verworpen op grond van onvoldoende buffertngscapaciteit), kan een handig hulpmiddel zijn bij het op empirische wijze bepalen van het minimaal benodigde aantal resources waarbij het station nog voldoende goed functioneert. Dit gegeven, dat voor het in bedrijf nemen van een station moet worden bepaald, kan daama als initialisatie parameter worden meegegeven. Bij initialisatie krtjgt het station dan altijd voldoende bufferruimte toegewezen.

I I HEr VERSTUREN VAN DATA In de volgende twee paragrafen wordt nader ingegaan op de fundamentele funkties die verrtcht worden bij respectievelijk het versturen en het ontvangen van data messages. De opdracht tot verzending van een msg komt bij het proces Interface layer transmit manager (ITMAN) binnen, zie ftguur 3.4. Dit proces interpreteert de diverse I-laag commando's en zal in het geval van een SEND het commando doorgeven aan het proces ICOPY via mailbox ICOPY. ICOPY is een dedicated proces dat speciaal belast is met het overnemen van data msgs die bij een host op verzending wachten. Het zal daarvoor eerst voldoende ruimte in de ITBUF toegewezen moeten krtjgen. Daartoe wordt een aanvrage bij de routine ITBUF.REQ geplaatst dat als monitor routine uitgevoerd is, dit om de ITBUF pointers ITFIRST en ITLAST te beschermen. Immers bij het weer vrtjgeven van bufferruimte worden deze pointers door een ander onafhankelijk proces gebruikt. Is er niet direct genoeg ruimte beschikbaar dan moet de aanvrage gequeued worden totdat het door het vrtjgeven van buffers weI gehonoreerd kan worden. Als ICOPY eenmaal over voldoende bufferruimte beschikt wordt het copieerproces op dma-basis opgestart. Oak het opstarten van dma is al5 monitor uitgevoerd om de dma hardware te beschermen tegen een gelijktijdige aanvrage van de ontvangstzijde van het LAN station. Omdat het dma proces relatief langdurig is en bovendien zelfstandig kan draaien, en omdat ICOPY door het aanvragen van de IBUF en dma resources mogelijkerwijs enige tijd zal moeten wachten, zijn ICOPY en ITMAN al5 processen uitgevoerd die parallel kunnen lopeno Zo wordt bereikt dat lTMAN op vlotte wijze andere host commando's kan afhandelen terwijl het dma transport van een vorige aanvrage aan de gang is. Is het dma proces ten einde dan initialiseert ICOPY de bijbehorende Interface transmit buffer descrtptor (lTD) met de velden die in ftguur 3.5 zijn aangegeven. Het veld adr.host geeft het fysieke adres aan waarop terugmeldingen betreffende de msg aan de host kunnen worden gegeven. Aetsz geeft aan hoeveel data er nog verstuurd moet worden en dataptr wijst steeds naar het volgende te versturen blok van de msg. Next wijst naar de ITD van de volgende msg en Previous naar die van de voorafgaande. Het statusbit wordt gereset om aan te geven dat de bufferruimte waar deze msg zich bevindt

- 33 -

ftguur 3.4 zender

DLS1\P AOR. HoST

5LSAP C.ONiR= C3

DATI'I ~TR..

u= 06

ACT SZ

DT: Fo

NEXT

dref

PREVIOUS

EoTsO

STATuS

ftguur 3.5 lTD

TBUF

TRSEQ

ftguur 3.7 DT header

Hex

TBuFs

ftguur 3.6 TBUF beheer

- 34 -

bezet is. Als ~aatste schrijft ICOPY de grootte van de msg op de eerste plaats van het datagebied. Vervolgens wordt in de response mailbox een bericht geplaatst als terugmelding aan de host dat de data msg overgenomen is. Het proces lRESP leest deze mailbox uit en verzorgt de terugmelding naar de host. Voordat de data doorgegeven kan worden aan de T-laag moet eerst de adressering geregeld worden. Via de naam tabel wordt het fysieke adres van de host en de Ilaam van de bestemming vertaald in respectievelijk de TSAPs TSAPL en TSAPR + het remote station adres dteR. Proces ICOPY lokaliseert hiermee het betreffende VC en initialiseert het ITDptr veld hiervan. Nu wordt de T-laag geac1tiveerd. Via de send mailbox worden het send commando en een pointer naar de VC entry in CTAB doorgegeven. Het proces Transport Layer Manager (TMAN) leest deze gegevens uit de mailbox, interpreteert het send commando en roept direct de re-entrant routine TSEND aan. TSEND vraagt eerst een TBUF aan via mailbox TBUF om de transport laag header van het datablok te kunnen construeren. Mailbox TBUF bevat pointers naar vIije buffers van dit type. Door een pmail op deze mailbox wordt, indien aanweZig, een pointer naar een vIije buffer doorgegeven. Is er geen vrije buffer dan wordt gewacht totdat door het uitvoeren van een vmail, geinitieerd door een ander proces, de pointer naar een buffer wordt vrijgegeven (zie ftguur 3.6). TSEND haalt de gegevens die volgens het T-laag protocol in de header moeten komen te staan via de VC pointer uit de betrokken VC entry die in CTAB staat. Dit zijn de destination reference (dref) en het transmit sequence nummer (TRSEQ). Omdat het hier om het eerste blok van een nieuwe msg gaat heeft deze VC voorlopig slechts een credit ter waarde ren, overeenkomstig 64 bytes. Dit betekent dat de complete frame, inc1usief T-laag header, niet langer dan 64 bytes mag zijn. AangeZien deze header 10 bytes inneemt resteren nag 54 bytes msg data die bij het eerste transport over het net zul1en gaan. Als laatste worden in de TB~F een drietal bytes ingevuld die helemaal vooraan staan en Link laag informatie bevatten. De eerste twee velden bevatten zogenaamde Link Service Access Points (LSAPs), adressen voor source en destination die gebruikt kunnen worden indien men direct boven de L-laag verschillende entities wenst op te nemen. Hier is dit niet het geval, er is maar ren T-laag die direct op de L-laag past zodat volstaan kan worden met het invullen van een vaste waarde die op elk station gelijk is. Het derde byte bevat een control veld en dient met de waarde hex C3 geinitialiseerd te worden. Deze velden worden in dit ontwerp verder niet gebruikt maar dienen ingevuld te worden omwille van behoud van compatibiliteit met andere stations die de ECMA link laag uitvoeren. De header ziet er nu uit zoals weergegeven in ftguur 3.7. In het CTAB moet een pointer naar de nieuwe header (TBUFptr) worden opgenomen en tenslotte moet de timer worden gestart en TRSEQ worden geincrementeerd. Op dit punt zijn al1e voorbereidingen getroffen die benodigd zijn voor een eventuele hertransmissie. Blijft om een of andere reden de bevestiging van dit blok langer uit dan het time out interval (ten gevolge van het verlies van de frame zelf of van de bijbehorende ACK frame), dan loopt de timer af en wordt TSEND gesignaleerd met een aanduiding van het betreffende Vc. TSEND gaat dan over tot hertransmissie van het laatste datablok: uit het

- 35 -

CDT veld wordt afgeleid om hoeveel data het gaat en via de pointer naar het lTD (figuur 3.5) wordt de fysieke locatie van de data achterhaald. Na het ophogen van de retry counter van het VC kan de L-Iaag worden geactiveerd. De ontvangst van het bijbehorende ACK frame zal ondermeer leiden tot het bijstellen van de velden dataptr en Act sz in de lTD. Weer wordt het CDT veld gebruikt om af te leiden om hoeveel data het gaat en worden dataptr en Act sz overeenkomstig verhoogd respectievelijk verlaagd. De L-Iaag voort de transmissie uit door het invullen van de 586 resources command blok (CB) en transmit buffer descriptor (TBD). Deze worden uit een pool van vrije resources betrokken en na verzending hier meteen weer ingeleverd. Omdat het aanvragen en vrijgeven van deze resources onafhankelijk van elkaar gaat en omdat aanvragen voor verzending van verschillende kanten kunnen komen ( van zendzijde bij normale data blok transmissie, van ontvangst zijde bij versturing van ACK frames), is het beheer van deze resources beschennd door monitor LSEND. Bij het aanvragen van transmissie dienen de volgende parameters meegegeven te worden: dteR, TBUFptr, TBUFSIZE...I0, IBUFptr en IBUFSlZE. De L-laag leidt hieruit de grootte van het LLCDU (logical link control data unit) af: LLCDU SZ -= IBUFSIZE + TBUFSIZE. Omwille van de compatibiliteit met het link laag protocol moot deze waarde in het type veld van de 586 command blok (CB) worden ingevuld. Met de andere gegevens wordt de rest van het CB en twee TBDs ingevuld, een voor de TBUF en een voor de IBUF. Na het geven van een channel attention (CA) aan de 586 wordt de fysieke transmissie door de chip uitgevoerd. Is de frame verstuurd dan reageert de 586 met een CX (command executed) interrupt die via de interrupt handler het proces LDONE zal activeren. Deze zorgt ervoor dat de zooven gebruikte resources teruggegeven worden aan de vrije resources pool.

3.4 HEr ONTVANGEN VAN DATA

3.4.1 LOW LEVEL DATA RECEPTION

Aan de ontvangst zijde komt de data van het net binnen in de 586 receive buffers (RBs). Het is van belang dat deze zo snel mogelijk weer vrijgemaakt worden opdat nieuwe data van het LAN kan worden ontvangen. Er dient onderscheid gemaakt te worden tussen de ontvangst van een data blok dat het begin van een nieuwe msg vormt, de ontvangst van een vervolg data blok uit een msg en de ontvangst van een acknowledge frame (ACK) of VC control frames. Bij ontvangst van een frame genereert de 586 een interrupt die via de interrupt handler tot een vmail op de frame receive interrupt mailbox leidt (zie frguur 3.8). Alvorens de data Via een pointer naar de FD door te geven, heeft de interrupt handler de correcte ontvangst van de frame geverifreerd. Zou een

- 36 -

frame door gebrek aan resourcesniet in zijn volledigheid kunnen worden ontvangen dan ziet de interrupt handler dit aan het status veld van de frame descriptor. Het zal in dit geval de data van dat deel van de frame dat ontvangen is negeren, en de overeenkomstige resources teruggeven via de routines RELEASE RB en RELEASE FD. Is de frame weI correct ontvangen dan leest proces RIXJNE middels een pmail operatie de FD pointer uit de FR INT mailbox. RDONE kijkt eerst naar het commando veld van de T-Iaag header. Het herkent het data transfer commando CDT) en gaat vervolgens via het destination reference veld na bij welke VC de frame hoort.

~~ I

"""-------1

figuur 3-8 ontvanger

•

Het receive sequence veld van de VC entry geeft aan of de ontvangen frame in de pas loopt met eventuele voorgangers. Komt RECSEQ overeen met het TRSEQ nummer veld uit de header, dan is de zaak in orde en wordt RECSEQ geincrementeerd. Is RECSEQ groter dan TRSEQ, dan gaat het om een frame dat eerder goed ontvangen werd maar bijvoorbeeld ten gevolge van het verlies van de overeenkomstige ACK toch heruitgezonden is. De frame is dus dubbel ontvangen en wordt daarom vrijgegeven en door versturing van een nieuwe ACK frame alsnog bevestigd. Als TRSEQ groter is dan RECSEQ dan is er iets raars aan de hand. Immers volgens het hier gehanteerde ACK protocol zal een zender nooit overgaan tot uitzending van een volgende frame alvorens de vorige bevest1gd is. Komt dit toch voor dan worden de 586 resources teruggegeven en de frame verder genegeerd. Een correct ontvangen frame wordt op dit punt geacknowledged door het versturen van een ACK frame en de bijbehorende FD wordt vrijgegeven via routine REL FD. Door het IRDptr veld (Interface receive buffer descriptor pointer) van de VC entry te inspecteren ziet RDONE of het hier om een vervolgblok van een msg of om het eerste blok ervan gaat. Is dit veld niet geinitialiseerd (dus gelijk aan NILL = FFFF), dan gaat het om een beginblok, anders om een vervolgblok. In

- 37-

het geval van een vervolgblok kan meteen begonnen worden met het copieren van de data in de 586 RBs naar de lRBUF ruimte. RDONE activeert daartoo proces RCOPY via mailbox RCOPY en de parameters lRDptr en RBDptr. Gaat het om het eerste blok van een msg dan moot eerst lRBUF ruimte voor de complete msg worden aangevraagd. Dit gebeurt door aanroep van de monitor routine IRBUF.REQ: call IRBUF.REQ(msgsz,RBDptr,TSAPL). Als er niet meteen voldoonde bufferruimte voorhanden is wordt de aanvrage gequeued. Nadat de buffer is toegewezen wordt het bijbehorende lRD geinitialiseerd (met msgsz en TSAPL) en proces RCOPY, wederom via mailbox RCOPY, verzocht te beginnen met het copieren van de ontvangen data. RCOPY leest de pointers naar het RBD en het IRD uit de mailbox en leidt hieruit de source respectievelijk destination adressen van de te copieren data af (RBptr en IRB dataptr). Het is niet mogelijk om direct de pointers naar de databuffers door te geven aan RCOPY omdat deze na het copieren de administratie van het VC en de IRBUF moot bijwerken. De informatie hierover staat juist in RBD en IRD. 20 worden de veiden dataptr en actsz van het IRD na het copieren als voIgt bijgewerkt: dataptr :- dataptr + data blok size (zie nguur 3.9)

actsz := actsz - data blok size

nguur 3.9 IRD

T5AP HOST DI\TA PTR.. M';)e:. SZ-

fileT sz.. NEXT PR.EVIOUS ~T""TUS

T

i~e.R.

PiR..

Dataptr geeft steeds aan waar het volgende blok van de msg ondergebracht moot worden. Het wordt geinitialiseerd met een pointer naar het begin van het datagebied van de toegewezen buffer. Actsz geeft aan hooveel msg data er nog ontvangen moot worden. Het wordt geinitialiseerd met msgsz en wordt af gelaagd tot nul. In het geval van een eerste data blok is data blok size = 54 bytes. Daarna is de grootte van het datablok afhankelijk van de verleende credit en zal proces

- 38 -

RCOPY bij het copieren moeten bijhouden om hoeveel data het gaat. (dit kan direct uit het ACTCNT veld van de RBDs afgelezen worden.). Dit is niet alleen van belang om de IRBUF administratie bij te kunnen houden maar ook om de resource counters weer "up to date" te brengen. Alvorens dit te doen zal RCOPY het IRDptr veld van de VC entry in CTAB initialiseren als het blok de eerste van een serie uit een msg is. Immers als de msg maar uit een blok bestaat en het blok dus tegelijkertijd de eerste en de laatste van de msg is. hoeft de IRBUF helemaal niet meer geadministreerd te worden en is het niet meer nodig om vanuit de T-laag een link hiemaartoe te onderhouden. Het feit dat het om het laatste blok van een msg gaat leidt RCOPY af uit het EaT veld van de Tlaag header. Dit bitje zal geset zijn als de frame het laatste deel van een transport service data unit (TSDU) bevat (Hier aanged.uid als msg). Tijdens het copieerproces zal RCOPY na een RB geropieerd te hebben deze steeds met het bijbehorende RBD teruggeven aan de resource pool door aanroep van de routine RELEASE RB. Na het copieren weet RCOPY hoeveel RB en FD resources er zijn vrijgegeven en zal het de credit management hiervan op de hoogte brengen opdat deze de resource counters overeenkomstig kan verhogen. De aanvrage om nieuwe credit die nu bij het credit management wordt geplaatst is afhankelijk van de vraag of het laatste biok uit een msg werd ontvangen of niet. Was EaT inderdaad geset. dan wordt een credit van €en aangevraagd. Dit is noodzakelijk opdat het remote station in staat gesteld wordt te beginnen met de transmissie van de volgende msgs. of. als er geen msgs meer te versturen zijn. komt deze credit overeen met het disconnect request (DR) frame dat zal volgen. Gaat het niet om het laatste blok dan wordt bij het aanvragen van credit de actuele waarde van het actsz veld uit de IRD meegegeven. Dit is immers een maat voor de hoeveelheid data van een msg die nog uitstaat. en bepaalt samen met de beschikbaarheid van receive resources op dat moment. hoeveel msg data de zender nu mag gaan verzenden. De credit management gaat aan het rekenen en zal de credit die verleend wordt opsturen naar de zender in een ACK frame. In het geval van een EaT frame zal RCOPY tot slot "bericht van ontvangst" doorgeven aan de I-laag door een pointer naar het desbetreffende IRD in de receive mailbox te plaatsen.

3.4.2 HIGH LEVEL RECEPTION

Als een msg in zijn geheel op een station is ontvangen moet de host voor wie de msg bestemd is bericht worden dat er data voor hem klaar staat. Het proces IRMAN (Interface layer receive manager) leest de IRD pointer uit de receive mailbox en weet hiermee de ontvangen msg te localiseren (zie nguur 3.10). Uit het IRD bepaalt IRMAN voor welke host de msg bestemd is. Daartoe moet de TSAPL waarde eerst via de naam tabel vertaald worden naar het fysieke adres van de host. IRMAN schrijft de parameters die doorgegeven moeten worden in een kleine respond msg buffer. De host moet weten dat het om een ontvangen msg gaat. waar de msg staat en hoe groot de msg is. Verder moet het IRESP

- 39-

proces de host kunnen adresseren. Al deze gegevens komen in het respond msg buffer te staan. IRMAN signaleert het proces IRESP door een vmail op de irespond mailbox waarbij respond code == msg received, en een pointer naar het respond msg buffer doorgegeven worden. IRESP construeert een respons bericht voor de host en brengt deze vervolgens op de hoogte van de ontvangen msg (zie § 3.6). Vlak voor verzending van het response bericht zal IRESP een timer starten die er op toe moet zien dat de host tijdig reageert met het overnemen van de msg data. Het afiopen van de timer zal resulteren in het vrijgeven van de bufferrnimte die de msg in IRBUF inneemt.

nguur 3.10 I-Iaag ontvanger

~

bJ

De host ontvangt het response bericht en kan zich nu prepareren op de ontvangst van de data. Ais de host klaar is zal het een RECEIVE opdracht aan de LAN kaart geven waarbij vermeld wordt waar de data terecht dient te komen, om hoeveel data het gaat en waar de data op dit moment staat (pointer naar IRBUF). Proces ITMAN decodeert dit commando en geeft via de DMA mailbox de afhandeling ervan over aan proces DMA REC. Dit proces zal allereerst de timer stoppen die het reageren van de host bewaakte. Dan wordt meteen monitor DMA aangeroepen om de msg op dma basis naar de host te copieren. Ais dit ten einde is wordt monitor IRBUF aangeroepen om de buffers in IRBUF weer vrij te geven. Deze gaat daarbij te werk zoals beschreven in § 3.2.2 en kijkt na afioop of door het Vrijkomen van buffer ruimte eventueel gequeuede aanvragen geholpen kunnen worden. Is dit het geval dan wordt opnieuw buffer ruimte gereserveerd, een IRD ingevuld en RCOPY gesignaleerd via de RCOPY mailbox.

3.4.3 CREDIT MANAGEMENT

Aan de kant van de ontvanger is er een credit manager proces opgenomen dat

- 40-

de administratie rond het aanvragen en verlenen van credit regelt. Het verlenen van credit is direct afhankelijk van de beschikbaarheid van receive resources. am deze resources te administreren zijn twee resource counters gedefrnieerd, een voor de frame descriptoren (FD CNT) en een voor de RBDs en RBs (RB CNT). Deze counters worden vanuit verschillende processen benaderd en zijn daarom ondergebracht binnen de beschermde omgeving van een monitor, RES MAN (Resource manager). De resource manager omvat een drieta1 routines, een om de tellers met een meegegeven waarde te verhogen, een om de tellers te ver1agen en een derde routine waar aan de hand van een aangevraagde credit een nieuwe credit wordt berekend en de tellers overeenkomstig worden verlaagd. Het criteri1llIl voor toewijzing van credit zou kunnen zijn dat steeds een fractie f van het meest schaarse resource a1s credit wordt ver1eend. Het a1goritme voor credit toewijzing wordt dan: FCALC (actsz) x- min(FD CNT. RB CNT) IF actsz ~

f * x THEN cdt :- actsz ELSE cd t :- f

*x

RETURN cdt De berekende credit waarde wordt aan proces eDT MAN geretourneerd, die vervo1gens het versturen van een ACK frame initieert (zie frguur 3.11 en § 3.6).

cl.~,1

figuur 3.11 credit beheer Is er he1emaa1 geen CDT te vergeven dan moet proces CDT MAN op semafoor NO CDT wachten. Beha1ve CDT MAN zijn er drie andere processen die rege1matig de resource

- 41 -

tellers zullen willen bijstellen. Dit zijn: I) RCOPY die na het copieren van RBs deze weer vrijgeeft en de RB teller overeenkomstig ophoogt 2) ROONE die de FD teller incrementeert en na ontvangst van een ACK, DC of CC frame ook de RBteller verhoogt. Anderzijds zal ROONE bij eventuele ontvangst van DGRAM data de resource tellers verlagen omdat er nu receive resources door niet geanticipeerde data worden bezet. 3) TSEND zal de resource tellers decrementeren na het versturen van een data of connect request frame, dit in anticipatie van de hierop volgende ACK of Cc. Tenslotte zal de interrupt handler de tellers incrementeren als een frame incorrect blijkt te zijn ontvangen.

3.5 ACKNOWLEDGE PROCESSING

Het versturen van acknowledge frames heeft drie onderscheidbare funties. Ten eerste een controle funktie op het correct en op volgorde aankomen van verzonden frames; ten tweede het overbrengen van credit waarden van ontvanger naar zender; de derde funktie is het aandUiden van de goede werking van een Vc. Dit laatste houdt in dat periodiek, na een zekere inactivity interval een station een frame over elk actief VC moet Uitsturen om aan te geven dat zijn kant van het VC nog in orde is. Het transport protocol schrijft voor dat voor deze activity frames een ACK pakket moet worden genomen. Er moet op elk station een timer lopen die het versturen van activity ACKS (AC ACKS) initieert. Na het afiopen van deze timer verstuurt de T-laag over elke uitstaande VC een AC ACK. Tevens dient elke VC een eigen timer bij te houden om de activiteit van de VC aan de kant van de tegenpartij te bewaken. Is na een zekere tijd, de inactivity tijd. van de tegenpartij geen levensteken meer vernomen, dan wordt verondersteld dat er iets mis is en wordt overgegaan tot het afbreken van het Vc. 20 wordt voorkomen dat "dode VCs" nodeloos resources in beslag blijven nemen. Er moet op gelet worden dat de inactivity timer van het VC (ACTIM) correct gedimensioneerd wordt ten opzichte van de activity timer die de AC ACKs verstuurt. Men dient rekening te houden met het feit dat frames, dus ook AC ACKs, op het netwerk verloren kunnen gaan, en dus niet te lichtvaardig over moet gaan tot ontbinding van een VC op grond van het uitblijven van een AC ACK. Een ACK frame heeft een sequence nummer dat het op volgorde aankomen van data frames bewaakt. Als een zender een dataframe over het VC verstuurt met seqnr = i, dan verhoogt het zijn eigen transmit sequence teller (TRSEQ) in CTAB tot i+ 1. De ontvanger van deze frame heeft in zijn VC entry een receive sequence teller die ook i aangeeft (RECSEQ). Als de frame wordt ontvangen zal

- 42-

de ontvanger zijn RECSEQ incrementeren en een ACK retourneren met seq nr = i+ 1. Hierdoor ziet de zender dat het volgende blok dat hij voor verzending klaar heeft staan op volgorde is met de al ontvangen blokken. Deze ACK is van belang voor het hertransmissie mechanisme en de v01gorde bepaling, maar bevat nog geen credit. Er wordt pas credit verleend nadat de ontvangen data is afgehandeld door de T-laag. De credit manager zal daartoe de versturing van een speciale ACK met credit initieren. Deze hoot als sequence nummer de huidige stand van RECSEQ, dit om verwarring bij de hertransmissie timer te voorkomen. Ook de AC ACKs zullen een sequence nummer krijgen dat gelijk is aan RECSEQ om deze dUidelijk te onderscheiden van "gewone" ACKs. 20 bezien kan de aanvrage ter versturing van een ACK van drie kanten komen (zie figuur 3.12): van RDONE (gewone ACK), van CDT MAN of van TSEND (AC ACK). De eerste twee gaan via een ACK manager proces dat de ACK frames invult. De informatie daarvoor krijgt het uit het ACK mailbox dat het commando send ack en een pointer naar de desbetreffende VC bevat. IDerin staat alle benodigde informatie voor de constructie van een ACK frame en de aanroep van LSEND (dref, CDT, RECSEQ en dte adres). TSEND verricht deze handelingen zelf. Het ACK bericht wordt in een TBUF ingevuld (zie figuur 3.13) dat via een pmail op de TBUF mailbox wordt aangevraagd. De transmissie wordt opgestart door het aanroepen van monitor LSEND. Na afloop moeten deze TBUFs weer worden teruggegeven. Daarom is er een proces Release manager (REL MAN) dat in de gaten houdt wat voor soort frames er net zijn verstuurd. Na het versturen van een frame wordt een CX interrupt gegenereerd die de interrupt handler ertoe zal bewegen een pointer naar de desbetreffende CB in het CX mailbox te plaatsen. Proces LDONE wordt hierdoor geactiveerd en zal de pointerCs) naar het verstuurde datab10k (ITBUFptr, indien aanwezig), en de header (TBUFptr) afleiden. Deze worden via de release mailbox doorgegeven aan REL MAN. Proces REL MAN interpreteert het type frame door naar het commando veld van de header te kijken en zal alleen actie ondernemen als het om een DGRAM (vooropgeste1d dat deze optie wordt gebruikt), een ACK, of een CC gaat ("gewone data" wordt immers via het VC mechanisme geregeld). Gaat het om een ACK of CC, dan wordt het desbetreffende TBUF weer vrijgegeven middels een vmail op de TBUF mailbox. Is er net een DGRAM verstuurd dan moet niet alleen de header weer vrijgegeven worden maar ook het datagebied dat de datagram msg zelf inneemt. Daartoe wordt monitor routine ITBUF.REL aangeroepen met een pointer naar de bufferruimte van het datagram. (DGRAMs benodigen deze speciale behandeling omdat het juist om frames gaat die zelf niet geacknow1edged worden, evenals bij ACKs en CCs). De handelingen die verricht moeten worden bij ontvangst van een ACK frame zijn weergegeven in figuur 3.14. Proces RDONE herkent de ontvangst van een ACK frame en signaleert ACK MAN met het commando receive ack en een pointer naar de RB die het ACK frame bevat. Proces ACK MAN bepaalt om wat voor soort ACK het gaat door naar de sequence nummers van het frame en de VC entry, en' het frame CDT veld te kijken. Is er sprake van een "gewone

- 43 -

nguur 3.12 Ack beheer

DLSAP

SLsAP CONT'R~

LIz

C.3

80

f\c..K:

60

dTl~f

Rec.5e:Q COT z 0

figuur 3.13 Ack pakket

figuur 3.14 Ack reception

- 44-

ACK" (ACK seqnr = TRSEQ), dan zal ACK MAN de timer die het laatst verzonden blok bewaakt stopzetten, de velden dataptr en ACT S2 van de lTD overeenkomstig het CDT veld van de VC bijwerken, en dit CDT veld resetten. Indien ACK seqnr = TRSEQ - 1 of ACK seqnr = TRSEQ en de timer ptr van de VC staat op NILL. dan gaat het om een AC ACK en zal ACK MAN enkel de ACTIM timer van het VC herstarten. Bevat het frame nieuwe credit dan werkt ACK MAN eerst het CDT veld van de VC bij en roept vervolgens routine TSEND aan met het commando send en een pointer naar het desbetre.ffende VC. TSEND gaat via het actsz veld van de lTD na of er nog meer data uit de msg verstuurd moet worden. Ais dit het geval is dan wordt de transmissie van de msg voortgezet. Indien de msg al in zijn geheel verstuurd is, zal TSEND de monitor routine ITBUF.RFL aanroepen om de msg bufferruimte weer vrij te geven. Daarna zal het via proces IRESP de host op de hoogte brengen van de succesvolle transmissie van de complete msg. Afhankelijk van het host-host protocol zal de zendende host wachten op een bevestiging van de ontvanger dat de msg overgenomen is (hetgeen als een DT pakket wordt verstuurd), alvorens over te gaan tot verzending van een eventuele volgende msg. of direct na ontvangst van het respons bericht de transmissie voort zetten. ACK MAN eindigt steeds met het vrijgeven van de RB ruimte ingenomen door het ACK frame door aanroep van REL RB (In het laatste geval gebeurt dit voor de aanroep van TSEND). Door het introduceren van proces ACK MAN worden zend- en ontvangst zijde van een station zoveel mogelijk gescheiden gehouden. Dit is van belang om het parallel lopen van zend- en ontvangst processen te bevorderen.

3.6 HOST INTERFACE

3.6.1 INLEIDING

Degene die opdrachten geeft aan de LAN software, hier aangeriuid met host, kan vele gedaanten aannemen. In het geval van de Kunix machine kan de host zich ergens op de VME bus bevinden op een andere kaart, of een lokale applicatie zijn, op de LAN kaart zelf. Daarom moet de interface naar de host zo algemeen mogelijk worden gehouden en wordt niet ingegaan op specifieke hardware aspecten. Een host communiceert met de I-laag via berichten die onder te verdelen zijn in instroctie blokken, commando's bedoeld voor de LAN kaart, en respons blokken, antwoorden of meldingen van de LAN kaart aan de host. Beide soorten hebben dezelfde struktuur en vallen uiteen in drie delen: a) een identificatie veld waar de nodige adressen staan. b) een control veld dat het

- 45-

commando of type respons bevat. c) een data veld met ruimte voor parameters behorend bij een control veld. De eerste twee hebben een vaste grootte, die van het derde deel is afhankelijk van het type commando. Aan zowel command als respons zijde wordt gecommuniceerd via een buffer pool opdat de afhandeling van een bericht niet meteen het plaatsen van een volgende in de weg staat. Aan respons zijde kan immers vertraging ontstaan totdat de host klaar is om het bericht weer vrij te geven. Door middel van een timer wordt erop gelet dat de host het bericht inderdaad vrijgeeft en wordt gewaakt tegen eventuele storingen bij de host. Aan commandzijde zal ITMAN de instructies zo snel mogelijk afhandelen maar kan er toch enige vertraging ontstaan alvorens het instructieblok weer vrijgegeven kan worden (bijvoorbeeld door het wachten op monitors).

3.6.2 COMMAND INTERFACE

De host initieert de actie door een instructieblok buffer aan te vragen (zie fi.guur

3.15). Dit gaat via een pmail op een mailbox die een verzameling pointers naar vrije instructieblokken (IBs) bevat. Aan de hand van de geretoumeerde pointer schrijft de host zijn instructie bericht in dit IB en signaleert vervolgens het ITMAN proces via een vmail op de attention mailbox waarbij de IB pointer wordt doorgegeven. Proces ITMAN doet niets anders dan op dit soort berichten wachten, de instructie interpreteren en de juiste handler aanroepen om de instructie uit te voeren. Ais de commando informatie is overgenomen zal de desbetreffende • handler het IB weer vrijgeven door een vmail operatie op het IB mailbox. De commando's die kunnen worden gegeven zijn:

SEND

ter versturing van data msgs

RECEIVE

ter ontvangst van data msgs

CONNECT

het opzetten van een verbinding op applicatie nivo

DISCONNECT

het afbreken van een verbinding op applicatie nivo

AWAIT CON

het reserveren van een connectie

BIND

het toevoegen van een applicatie

UNBIND

het wegnemen van een applicatie

LIST

ter uitlezing van de naam tabel

- 46-

RESET

brengt het station in de begin toestand

3.6.3 RESPONSE INTERFACE De response interface lijkt veel op de command interface maar is toch niet helemaal het spiege1beeld ervan. Dit vanwege de onbekendheid rond de host applicatie hardware/software configuratie. waardoor de signa1enng van de host opengelaten moet worden. Het is mogelijk dat op ren LAN station verschillende soorten hosts met verschillende manieren van signalering zijn aangesloten. De informatie hieromtrent kan opgeslagen worden in de I-laag naam tabel. Aanvragen ter versturing van respons berichten worden afgehande1d door het proces Interface Layer Respond (IRESP, zie figuur 3.16). Deze leest uit de irespond mailbox het type respons en een pointer naar een buffertje ciat ciaarbij behorende . parameters bevat. Er wordt een response in1erface buffer (RIB) aangevraagd door een pmai1 op de RIB mailbox. Het respons bericht wordt in de toegewezen RIB geschreven en na het starten van een timer wordt de host gesignaleerd met een pointer naar dit bericht. De host dient hierop te reageren door het bencht over te nemen en na afloop een bevestiging te geven middels een vmail op mailbox HOST ACK. Proces REL RIB reageert hierop met het stoppen van de timer en vrijgeven van het RIB. De mogelijke responsen zijn: SEND:

1) data msg copied (I-laag) Of

data refused. no VC Of data refused. VC busy 2) data transfered (remote T-laag) of time out op data msg (T-laag) 3) data accepted (remote host) RECEIVE:

data valid of data error (I-laag)

CON/DIS:

1) request transmitted (T-laag) Of

local denied (T-laag) 2) connect confirm (remote host) Of remote denied (remote T-laag)

- 47-

TNnlWC.

BLoL(

BUfFER

HosT

figuur 3.15 command interface

'R ES1'. HosT

'R'AD

~;"---.l~

TI.JTcRfp,c..E

io"-_=-

'BufFER

•

.5ie:.NAL

figuur 3.16 response interface

i

I ... E

QlJT ¥~LuE.

ST~uc..

PTR

NEXT

figuur 3.17 timer queue element

- 48-

AWAIT:

await setup Of await denied

BINDIUNBIND:

1) request transmitted CT-laag) of

request denied CI-laag) 2) name accepted Ccentral name server) of name denied Ccentral name server) LIST:

data valid of request denied CI-Iaag)

RESET:

reset perfonned Of reset denied (I-laag)

3.7 TIMERS EN PRIORITElTEN

Timers worden op verschillende plaatsen in het ontwerp gebruikt om VO handelingen waarvan niet met zekerheid kan worden gezegd dat ze zullen slagen te bewaken. De software van de timers is gebaseerd op een hardware timer in de 80186 processor. Een hardware tick zal via een timer interrupt handler de software timers bijstellen. Als een software timer afioopt, dan wordt een bepaalde routine uitgevoerd om een mogelijk opgetreden fout weer recht te zetten. In dit ontwerp kunnen timers voor vijf verschillende zaken worden onderscheiden: a) timer op verzonden pakket Cop VC basis). b) timer voor periodieke versturing van AC ACKs Cop station basis). c) timer op het ontvangen van AC ACKs Cop VC basis).

d) timer op het overnemen van ontvangen data door host Cop msg basis). e) timer op het overnemen van respons interface messages door de host Cop RIB basis). De timer van categorie b) verschilt in ren opzicht van de anderen: deze kan volkomen onafhankelijk lopen, zonder tussenkomst van andere processen. De time out heeft een constante waarde en heeft betrekking op het geheel van aktieve VCs, dus niet op een speciaal item. Deze timer mag steeds door blijven lopen en hoeft nooit van bUiten gewijZigd of gestopt te worden. Voor de andere timers geldt dat de mogelijkheid moet bestaan om ze te starten, te stoppen of te resetten Ceen speciaal geval van stoppen en starten). Het zou handig zijn om over een globale timer utility binnen de LEX te

- 49-

beschikken, maar aangeZien deze nog niet zo ver is, wordt het timer gebeuren voorlopig als gewoon proces, dat via mailboxes met andere processen communiceert, in het ontwerp opgenomen. Het zal duidelijk zijn dat de timer processen de hoogste prioriteit binnen het ontwerp dienen te krijgen. Dit omdat een goede synchronisatie met de buitenwereld vereist is voor de bewaking van de correcte werking van het station. Elke gebeurtenis waarvoor een timer benodigd is kom t overeen met een timer queue element. De queue elementen zijn georganiseerd als een linked list in volgorde van time out waarde. Elk element bevat een time out waarde, een aanduiding van de soort timer (categOrie a,b,c.d of e). eventueel een pointer naar de betrokken data struktuur, en een next veld dat een pointer naar het volgende queue element bevat (zie figuur 3.17). Timer queue elementen kunnen aan de lijst worden toegevoegd of eruit worden weggehaald door proces TIMADM (timer administratie) via de timer mailbox te signaleren (zie figuur 3.18). Na e1ke timer tick zal de timer handler nagaan of de time out van het eerste timer queue element is afgelopen. Als dit het geval is zal een painter naar dit element aan het proces TIMEOUT worden doorgegeven. Dit proces verricht de nodige handelingen en geeft het queue element daarna terug aan een free list (of zal het in het geval van een AC ACK time out weer in de timer queue terugzetten). Gaat het om een data transfer time out, of een time out op een remote AC ACK, dan wordt TSEND aangeroepen met respectievelijk het commando DR timeout of AA timeout en een pointer naar de betrokken ve entry.

figuur 3.18 timers In het eerste geval kan TSEND overgaan tot hertransmissie en herstarten van de timer. of beslUiten het VC af te breken door verzending van een DR, dit indien al MAXTRY hertransmissies hebben plaatsgevonden. In het tweede geval zal altijd worden overgegaan tot het afbreken van het ve. Als TIMEOUT een categorie b) time out constateert, dan wordt eveneens

- 50-

TSEND aangeroepen maar deze keer met het commando send AA hetgeen zal leiden tot versturing van AC ACKs op alle actieve YCs. Ais de timer van een data msg, dat op overname door een host wacht afloopt. zal TIMEOUT de monitor routine IRBUF.REL aanroepen met een pointer naar het desbetreffende IRD om de bufferruimte weer vrij te geven. De laatste soort time out wordt door TIMEOUT zelf afgehandeld. Het leest de pointer naar een RIB uit het timer queue element en geeft deze weer VIij middels een vmail op de RIB mailbox. Als alles goed gaat dan lopen de timers nooit af Cbehalve die van type b). Het is dan weI nodig om de timers te stoppen naar aanleiding van een bepaalde gebeurtenis. Om dit te kunnen doen moet de datastruktuur die door een timer bewaakt wordt. een pointer bevatten naar dit timer queue element. 20 heeft elke YC entry twee velden waarin pointers naar timers staan. een voor de data transfer timer en de ander voor de AC ACK timer Ctype c). In het IRD dat bij een ontvangen msg hoort is ook een timer pointer aanwezig. Deze wijst naar een timer queue element van het type d). Tenslotte bevat het respons bericht dat naar een host verstuurd wordt een pointer naar de timer die dit respons buffer bewaakt. Het stoppen van deze timers gebeurt door achtereenvolgens ACK MAN. DMA REC en REL RIB. die via de timer mailbox aan proces TIM ADM het stop commando met een pointer naar het desbetreffende queue element doorgeven. De ontvangst van een AC ACK leidt niet tot het stoppen van de timer maar tot het resetten ervan met een vaste waarde die bij proces ACK MAN bekend is. Ook de andere timers moeten ooit door externe processen zijn opgestart. Dit gaat wederom via de timer mailbox en proces TIM ADM die het timer queue element construeert in de buffer van een free list element en vervolgens in de timer queue tussenvoegt. Mocht er geen vnje timer queue element direet voor handen zijn. dan wordt met een LEX GETSEG call voldoende geheugenruimte aangevraagd om het nieuwe element onmiddellijk te kunnen aanmaken. Het opstarten van de verschillende timers is als voIgt: a) DT timer:

opgestart door TSEND bij verstunng van een frame, Cdtstart. YC: DTIIM).

b) send AC ACK:

opgestart tijdens initialisatie.

c) ree. AC ACK:

opgestart door TSEND bij het opzetten van een nieuwe

YC. CYCstart. YC: ACTIM). d) data naar host:

opgestart door IRMAN na ontvangst van complete msg.

Cmsg ree start. IRD: TIM).

- 51 -

e) respons aan host: opgestart door IRESP na het aanmaken van een respons msg, (resp start, RIB: TIM). De LEX biedt de mogelijkheid om elk proces van een prioriteit te voorZien. Dit betekent dat na het uitvoeren van mailbox operaties gekeken kan worden welk van de processen die in principe zouden kunnen doorlopen op dat moment het belangrijkste is. In het algemeen kan gesteld worden dat de processen die zich met timers beZig houden een hoge prioriteit dienen te hebben. AIleen het reset proces dient voor de timers te gaan. Verder krijgen de processen die met ACK processing te maken hebben een hoge prioriteit. Globaal komt het erop neer dat de processen uit de lagere software lagen een hogere prioriteit verdienen dan die uit hogere lagen.

3.8 CONNECTION MANAGEMENT

Er is al uitgebreid ingegaan op het data transport over virtuele circuits, wat er aIlemaal bij komt kijken en waar het goed voor is. Ook is herhaaldelijk aan de orde gewet'St hoe VCs in een connection table (CTAB) geadministreerd dienen te worden. Hoe d~ VCs precies opgebouwd, bijgehouden en afgebroken worden is nog niet behandeld en is het onderwerp van deze paragraaf. Binnen de T-laag draait, op een enkele uitzondering na, aIles om virtuele circuits. Het is daarom van groot belang dat ze op een dusdanige wijze georganiseerd worden dat de toegang tot de gegevens van een VC zo effident mogelijk verloopt. Daarbij dient men zich te realiseren dat een VC vanaf twee kanten gerefereerd kan worden, vanaf hostzijde (de I-Iaag), of vanaf netwerkzijde (de L-laag). Eerstgenoemde referenties lopen via TSAPs terwijl laatstgenoemde middels het zogenaamde source reference gaat. Verder dient het await mechanisme, waarbij VCs door een host gereserveerd worden, in het ontwerp te worden ondergebracht. Daarbij moet steeds gelden dat de som van het aantal aktieve en het aantal "geprepareerde VCs" niet meer mag bedragen dan een maximale waarde die aangeeft hoeveel VCs een LAN kaart tegelijkertijd kan ondersteunen (MAXVC). Wat tot nu toe als CTAB werd aangeciuid bestaat feitelijk Uit twee tabellen, een request table en een virtueel circuit table (VCTAB). De sleutel tot de eerste is het lokale TSAP en via deze tabel wordt het await mechanisme gerealiseerd. De sleutel tot VCTAB is de source reference (zie figuur 3.19 inclusief voorbeeld). In de REQTAB staan de TSAPs van het station op een rij met bijbehorende await waarden om aan te geven hoeveel nieuwe VC aanvragen op dat TSAP gehonoreerd kunnen worden. Verder is per TSAP een pointer opgenomen naar het VCTAB en weI naar de eerste entry (volgens sref) horend bij dat TSAP (een TSAP kan immers meer VCs tegelijkertijd ondersteunen).

- 52-

TSAPL

AWAiT

Vc..PiR

1

2

'Ie:;

2

4

vc. 1

3

-1

'Ie 2...

4

1

NiLl

REQ TAl;

ftguur 3.19 connection tables

VC.iPlB

~rl!f

Jrtf

TSAPL

.............

NexT

PRE'V"OUS

~

l

~c..

it

NiLl

2.

3

Vc..3

vcA

J

~

Y<:5

Vc.2..

~

2-

Vel.

Vc..1

5

1

NiLL

VC.3

frguur 3.20 connectie beheer

- 53 -

In de VCTAB zijn de entries van een TSAP aan elkaar gelinkt via de NEXT en PREVIOUS velden. Hier zijn de VCs ondergebracht in volgorde van sref, opdat de VC gegevens snel opgevraagd kunnen worden door routines die reageren op ontvangen frames. De VCs zijn hier niet alleen geordend op sref waarde maar bovendien in een dub bel gelinkte lijst gerangschikt naar TSAPL adressen. Dit bevordert de toegang tot de VC gegevens van host zijde en vergemakkelijkt het toevoegen en wegnemen van respectievelijk nieuwe en oude VCs. Een niet meer in gebruik zijnde VC entry wordt weergegeven door de waarde NILL ... FFFF in het sref veld. Deze entry kan bij het aanvragen van een nieuwe VC direct gebruikt worden. Een nieuwe VC wordt aangevraagd via een TSAPL, TSAPR paar. Het krijgt een sref toegewezen door de T-laag als het eenmaal in de vcr AB wordt opgenomen. Daartoe wordt vcr AB van boven naar beneden afgelopen en de eerste entry met sref .. NILL wordt toegewezen aan de nieuwe aanvrage. Eerst worden de pointers van de lijst struktuur aangepast: Er wordt voor gezorgd dat de pointer NEXT, van de laatste VC entry met dezelfde TSAPL waarde, nu naar het nieuwe VC wijst, en dat het PREVIOUS veld van de nieuwe VC naar deze oude VC wijst. Bovendien moet het NEXT veld van de nieuwe VC naar dat VC wijzen dat eerst door het oude VC, dat nu aan de nieuwe entry voorafgaat, werd aangewezen. Bestaat er nog geen VC entry met dezelfde TSAPL waarde, dan komt het nieuwe VC achteraan de lijst met NEXT - NILL. Omdat aanvragen voor het opzetten of afbreken van VCs van twee kanten kunnen komen worden deze tabellen, en met name de hier beschreven akties, in de beschermde omgeving van de monitor CONN MAN ondergebracht. De routines van deze monitor zijn als voIgt: await(TSAPL,value); cancel(TSAPL,value); vcenter(TSAPL,TSAPR,dteR,ITDptr) en vcerase (TSAPL,TSAPR). De eerste twee I-laag commando's waar het hier om gaat, await en cancel, worden door proces ITMAN direct naar de T -laag doorgesluisd via de send mailbox. De parameters zijn TSAPL en de awaitwaarde (... het aantal te reserveren VCs) dat in een veld met het await commando wordt ondergebracht. Het T-laag proces TMAN loo;t de commando's uit de send mailbox, activeert CONN MAN en deponeert een terugmelding voor de host in de respons mailbox (zie figuur 3.20). Het uitvoeren van een await of cancel houdt niet meer in dan een controle op het niet overschrijden van MAXVC en het aanpassen van een await veld in REQTAB via CONN MAN. Een T-laag connect (CR) of disconnect (DR) commando heeft een dataveld die tot 54 bytes mag bevatten (= een blok). Het is in dit veld dat de applicatie connectldisronnect commando's, plus eventuele parameters of data, worden getransporteerd. Deze data wordt door de communicatie software al5 een gewone msg behandeld. Het wordt eerst in ITBUF opgeslagen compleet met lTD in bufferruimte dat via monitor routine ITBUF.REQ door proces ICOPY werd aangevraagd. ICOPY activeert daarop de T-laag door het commando CON of DIS met een pointer naar een msg bUffertje in de send mailbox te plaatsen. Dit msg buffertje werd daarvoor met een pmail op de msg mailbox aangevraagd en gevuld met de parameters TSAPL, TSAPR, dteR en ITDptr. Proces TMAN neemt deze gegevens over door uitlezing van send mailbox en het

- 54-

msg buffertje en geeft deze laatste daarna weer vrij middels een vmail. Een connect commando vereist dat eerst gecontroleerd wordt dat bij het aangevraagde VC een passend.e "await" gevonden kan worden. 20 ja dan wordt middels de CONN MAN routine vcenter deze await waarde gedecrementeerd en de nieuwe VC ergens in VCTAB ondergebracht. Daarbij worden de velden sref,TSAPL,TSAPR,dteR,ITDptr,NEXT en PREVIOUS geinitialiseerd. TMAN zal dan TSEND aanroepen om een CR blok samen te stellen aan de hand van de net ingevulde VC informatie, en om deze te verzenden met de ITBUF data. TSEND zal alvorens dit te doen eerst een timer op het CR blok starten en het overeenkomstige veld in de VC entry initialiseren. Immers connect/disronnect requests zijn aan dezelfde hertransmissie bepalingeno onderhevig als "gewone" data transfer (DT) pakketten. Ais de tegenpartij akkoord gaat dan zal na verloop van tijd een CC voor dit VC worden ontvangen. Proces ACK MAN krijgt deze frame binnen en hoeft niet meer te doen dan het dref veld van de VC entry in te vullen en de receive resources van het CC frame weer vrij te geven. Via de routine ITBUF.REL zal ACK MAN eindigen met het vrijgeven van de buffer ruimte die de CR data inneemt. Anderzijds is het mogelijk dat een connect request in de vorm van een CR frame van het net binnenkomt. Dit wordt door ACK MAN gedecodeerd die CONN MAN.vcenter activeert om het VC in de tabellen op te nemen. Daarbij geld.en dezelfd.e voorwaarden en wordt dezelfde werkwijze gevolgd als voorheen. Ais dit succesvol verloopt dan construeert ACK MAN een CC frame en stuurt deze naar de tegenpartij via LSEND. Het zal daarop monitor routine IRBUF.REQ aanroepen om de overname van CR data te initieren. Deze data wordt verder als een gewone msg beschouwd en afgehandeld zoals in §3.4 (het ontvangen van data) beschreven staat. In een opzicht vormt de ontvangst van een CR frame een uitzondering: proces ACK MAN wordt gesignaleerd met een pointer naar de FD en niet met een pointer naar de eerste RBD van de ontvangen frame. 2odoende kan de dte adres infonnat,ie van de aanvrager in VCTAB worden opgenomen (als de connectie tot stand komt). In dit geval is het dus ook proces ACK MAN en niet RDONE die de FD na afloop weer vrijgeeft. In het geval van een disconnect commando wordt de VC pas afgebroken als het DC (disconnect confinn) van de tegenpartij binnen is. Dit opdat later eventueel tot hertransmissie kan worden overgegaan. Heeft men na MAXTRY hertransmissies nog steeds geen DC als respons gekregen dan wordt de VC eigenmachtig afgebroken. De ontvangst van DC zal leid.en tot het vrijgeven van d;e ITBUF ruimte ingenomen door DR data en de aanroep van routine CONN MAN.vcerase die de VC entry zal resetten en de bijbehorende await waarde in REQTAB zal incrementeren. Bij ontvangst van DR vanaf het net wordt het VC door aanroep van routine CONN MAN.vcerase weI direct afgebroken. Alvorens dit te doen zal ACK MAN weI de nodige gegevens overgenomen hebben om een DC frame samen te kunnen stellen dat vervolgens via LSEND wordt opgestuurd. De door ACK MAN verstuurde CC en DC frames worden in speciaal aangevraagde TBUFs geconstrueerd. Een belangrijke taak die implidet door de connection management wordt

- 55-

verricht is de verincatie van host send commando's. Een host mag pas een msg bij de LAN kaart aanbieden als a) er een connectie bestaat en b) het station niet bezig is een vorige msg van die host af te handelen. Als de host zich hieraan houdt zal het tot nu toe beschreven ontwerp goed functioneren, maar het is toch van belang dat het LAN station beschermd wordt tegen hosts die zich niet netjes gedragen en het station met data proberen te overstelpen. Daartoe wordt de VC entry in de VCTAB gebruikt. Een host biedt een send commando aan met opgave van host adres en destination naam. Deze worden vertaald in respectievelijk TSAPL en TSAPR. Via de REQTAB wordt TSAPL op de VCTAB afgebeeld en hier wordt gezocht naar een entry met bijbehorende TSAPR. Is die er niet dan bestaat er geen VC en praat de host dus voor zijn beurt. Deze controle wordt direct uitgevoerd door ICOPY en het is dit proces dat meteen het respons "data refused, no VC" via IRESP aan de host terugstuurt (zie nguur 3.4). 20 wordt het zend proces gestopt nog voordat er data bij het LAN station begint binnen te stromen. Oak al5 de host al een data msg in behandeling heeft wordt de nieuwe send aanvrage geweigerd. Dit herkent ICOPY door naar het ITDptr veld van de VC entry te kijken. Is deze ongelijk NILL dan krijgt de host al5 respons "data refused, VC busy", anders wordt het zend proces voortgezet en zal .proces ICOPY ter zijne tijd het ITDptr veld initialiseren. Het spreekt voor zich dat na ontvangst van een ACK frame, die het laatste blok van een msg bevestigt, het IIDptr veld op NILL gereset moet worden.

3.9 DATAGRAM SERVICE

Wil men een LAN systeem ontwerpen, met de bed6eling om daar onder andere gangbare, op de markt verkrijgbare, apparatuur aan toe te voegen, dan doet men er goed aan om het ontwerp volgens een internationale standaard zoals dat van ECMA uit te voeren. Als toch van deze standaard wordt afgeweken dan dienen daar hele goede red.enen voor te bestaan. Het invoeren van een T-laag datagram service is een voorbeeld van een dergelijke afwijking, of beter gezegd toevoeging, aan de ECMA standaard. Er is besloten om dit niet als integraal onderdeel in het ontwerp op te nemen maar als optie voor eventueel later gebruik. Daarom wordt hier aangegeven hoe een datagram mechanisme in het ontwerp past. Kenmerkend voor datagram men zijn hun kleine omvang en de noodzaak om ze zo snel mogelijk op de plaats van bestemming te krijgen. De aangeboden data wordt direct verstuurd zonder de rompslomp van het opzetten, bijhouden en weer afbreken van een VC er omheen. Een datagram msg wordt via een dgram commando bij de T-laag aangeboden. Het wordt als "gewone" data compleet met lTD in de ITBUF opgeslagen volgens de gangbare methode. ICOPY zal de T-laag echter via een speciale mailbox signaleren, mailbox DGRAM. (zie nguur 3.21) Deze wordt tevens door een speciaal T-laag proces uitgelezen (DMAN) dat een net iets hogere prioriteit heeft dan TMAN. Op deze manier krijgt het datagram verkeer als het ware een

- 56-

bevoorrecht communicatie kanaal binnen de T-laag, waardoor vlotte versturtng wordt bevorderd. DMAN vraagt een TBUF aan, construeert een datagram header en initieert de verzending van het geheel door LSEND aan te roepen. Na de transmissie wordt het ITBUF gebied door proces REL MAN weer vrtjgegeven (zie nguur 3.12). Als een datagram frame van het LAN binnenkomt dan wordt de data als een gewone data msg naar IRBUF geropieerd, waarop de host via IRESP direct gewaarschuwd zal worden (Immers het EOT veld van de header zal geset zijn). AHeen het administreren van een VC en de versturing van een ACK frame blijft achterwege.

nguur 3.21 DGRAM processing

•

3.10 NAME SERVICE

De naam service is in zoverre een bUitenbeentje dat het een brug slaat tussen applicatie- en communicatie eenheden. Het is derhalve in de I-laag goed op zijn plaats. Een nieuwe applicatie dat zich aan het netwerk wi! toevoegen zal zich eerst moeten aanmelden bij de centrale name server (CNS). Omgekeerd moet een applicatie dat zich terugtrekt zich bij deze afmelden. Dit houdt niet meer in dan het versturen van een (UN)BIND aanvrage en het ontvangen van een bevestiging of afwijZing hierop. Voor het uitvoeren van deze handelingen wordt een "tijdelijke" VC naar de CNS gebruikt. Doordat elk station zijn eigen naam tabel bezit blijft de adressering van een remote applicatie een lokale aangelegenheid. Deze tabel moet daartoe weI continu "up to data" worden gehouden. Als ergens op het netwerk een nieuwe applicatie aan het LAN wordt toegevoegd moet dit op elk station in de lokale naam tabel in rekening worden gebracht. Natuurlijk is het ook mogelijk dat de nieuwkomeling zich via de eigen LAN kaart aanmeldt. Deze wordt echter pas in

- 57 -

de naam tabel opgenomen als de terugmelding van de CNS binnenkomt. Aanvragen voor een plaats op het LAN gaan via het I-laag BIND commando. Deze bevat de adres informatie in het parameter deel van de instruktieblok. Dit wordt door ICOPY overgenomen in de ITBUF, waar een bijbehorend lTD wordt aangemaakt. Daar er nog geen VC is begint ICOPY met een CON aanvrage naar de T-laag waarbij de TSAP van de lokale naam service en de adres gegevens van de CNS worden meegegeven. De T-laag zal in samenwerking met de CNS op de normale manier een VC opzetten en de adresinformatie in ITBUF wordt als data met het CR frame meegestuurd (zie figuur 3.22). De CNS ontvangt de aanvrage en zal beoordelen of de nieuwe applicatie op het LAN mag worden opgenomen. Zo ja, dan krijgen alle stations bericht van het feit dat een nieuwe applicatie aan de LAN omgeving is toegevoegd. Voor het verrichten van deze handeling zal de CNS een VC naar de name handler van elk station moeten opbouwen en naderhand weer afbreken. Het is duidelijk dat dit veel overhead vergt en is een voorbeeld van een toepassing waar DGRAM service zeer nuttig zou zijn. Zit het LAN al vol dan wordt toestemming geweigerd en kIijgt alleen het aanvragende station hier boodschap van.

figuur 3.22 name processing Een ontvangen frame met naam tabel informatie wordt als dusdanig herkend via zijn TSAPR adres. Op elk station is een name handler routine (NH) gedefinieerd die zich achter een speciale uniforme TSAP bevindt. ROONE herkeilt dat het om ontvangen data gaat en de boodschap wordt via de normale weg (IRBUF,RCOPY) overgenomen. IRMAN wordt gesignaleerd dat er een bericht binnengekomen is en ziet aan het meegegeven TSAP adres dat het om een name service bericht gaat. De NH wordt aangeroepen met een pointer naar het IRD en zal het registreren van de adres infonnatie uitvoeren. Vervolgens geeft het de IRBUF ruimte weer vIij, initieert het afbreken van de VC door een DIS commando in de send mailbox te plaatsen, en waarschuwt het de host dat zijn BIND commando met succes is uitgevoerd (Deze laatste twee handelingen alleen als de aanvragende host zich op dit station bevindt, hetgeen afgeleid wordt uit het dte veld van het adres van de nieuw opgenomen applicatie, anders wordt het VC door de CNS afgebroken). Een UNBIND opdracht volgt precies dezelfde weg. Wederom gebeurt het

- 58 -

bijwerken van de naam tabel pas na ontvangst van een CNS respons.

ftguur 3.23 list command Er is nag een derde type opdracht die met de naam service te maken heeft: het LIST commando. Wanneer een gebruiker gegevens wil over de inrichting van het net, dan geeft hij daartoe een LIST commando, met opgave van data buffer adres en respons adres. aan de l-laag van zijn LAN station. Proces ITMAN geeft het commando door aan ICOPY, die via een monitor routine het dma transport van de naam tabel gegevens. van LAN station naar host zal opstarten (zie ftguur 3.23). Als dit afgelopen is zal ICOPY via de respons mailbox een terugmelding aan de host geven dat de aangevraagde data klaar staat.

3.11 INITIALISATIE EN RESET .

Het is denkbaar dat bepaalde stations zelf geen disk opslag medium bezitten en via hun LAN station disk service van het netwerk vragen. Een dergelijk station zal zich ook bij power up tot het LAN moeten wenden om zijn communicatie software, en de software van de applicaties die daar bovenop liggen, te booten. Daartoe is op het LAN een boot server gedeftnieerd dat bij een centrale file server of administratie server ondergebracht kan worden. Het station dat om een remote boot vraagt zal een minimale link laag in PROM moeten beZitten die het versturen van de boot aanvrage en het ontvangen van de voor hem bestemde code mogelijk maakt. De aanvrage kan als een datagram naar een welbekende TSAP, waarachter zich de boot service bevindt, worden verstuurd. De transmissie van de code zal volgens een speciaal bilateraal protocol moeten verlopen, waarbij sequencing en flow control over een eenmalig virtueel circuit worden uitgevoerd. Als het station eenmaal geboot is zal het met een opstart programma beginnen dat in proces INIT/RESET is ondergebracht. Daarbij worden de resources van het station gedeftnieerd en geinitialiseerd. De resources van de communicatie software (IBUFs, RBs, CTAB, CBs etc.) kunnen op verschillende manieren worden geinitialiseerd. Het meest eenvoudige is de reservering van ruimte voor de diverse structuren direct bij de declaratie te laten plaatsvinden, en de initialisatie ervan tijdens het opstarten uit te voeren. Dit betekent dat de dimensionering tijdens compile tijd gebeurt, en het resultaat is een vaste "ingebakken" aantal resources. Aangezien een uniform communicatie software pakket wordt nagestreefd betekent dit dat elk station

- 59-

aan eenzelfde hoeveelheid resources vast zit. Dit is verre van wenselijk. zoals de vergelijking van de werklast van een file server met die van een terminal station laat zien. Deze aanpak zou een geweldige overdimensionering van de laatste of een vastlopen van de eerste met zich meebrengen. Het is beter om in de communicatie software enkel de declaratie van de verschillende structuren plus de benodigde pointers op te nemen. De definitie, dus de echte geheugenreservering en initialisatie van de pointers. zal dan gebeuren op commando van een hogere software laag. Dit past in het concept van een applicatie afhankelijke I-Iaag en een uniforme communicatie software pakket. De LEX biedt de middelen hiertoe in de vorm van de GETSEG call. Het proces INIT/RESET verzorgt de definitie van de communicatie software resources. Na het booten van de "kale" communicatie software gaat !NIT via GETSEG calls over tot reservering van vold.oende geheugenrUimte en zal het deze daarna ook initialiseren. Tenslotte loopt het proces tegen een reset mailbox aan. Ais op een later tijdstip het I-Iaag commando RESET gegeven wordt. dan zal dit in deze mailbox terecht komen waarna proces INIT/RESET alle structuren zal clearen. De structuur van het proces is als voIgt: PROC INIT/RESET 1••• getseg(IBUFsz, init: getseg( VCTABsz, VCTABptr).... } while true do I < reset alles> pmail(RESET mbx); }

- 60-

IBUFptr);

HOOFDSTUK 4 INA 960

4.1 INLEIDING INA 960

INA 960 is een local area network software pakket voor a1gemeen gebruik, dat klasse 4 van het ISO transport protocol volledig implementeert. Het is uitstekend geschikt voor een hardware configuratie waar een 82586 LAN controller samenwerkt met een 80186 processor, zoals op de Kunix LAN kaart het geval is. De meest geschikte software omgeving voor het pakket is het iRMX operating system, waar het als first level job naast andere gebruikers applicaties kan draaien. Daarnaast is het mogelijk om ina 960 op een dedicated processor (zOaIs de 186) te implementeren en zelf de user interface te schrijven. 20 heeft ina 960 twee onderscheidbare interfaces: de iRMX 86 interface en de component support interface (CSI). In beide gevallen is de interaktie tussen ina en de client gebaseerd op het uitwisselen van geheugensegmenten, request blocks geheten. In iRMX mode is de communicatie met de gebruiker als voIgt: een gebruiker plaatst een opdracht door het invullen van een request blok en het verrichten van een system call naar ina 960. Na uitvoering van het commando zal ina het request blok retourneren naar een in het commando gespeci.ficeerde return mailbox. Daarbij is een respons code ingevuld die aangeeft hoe de uitvoering van het commando is verlopen. In iRMX mode is er ook een procedure interface aanweZig waarbij de gebruiker het invullen van een request blok aan ina 960 overlaat. De gebruiker heeft zo het gemak van een simpele procedure call ten koste van extra processing overhead binnen ina. In de CSI mode loopt ina onafhankelijk van het host systeem op een aparte processor. De hardware afhankelijke zaken zoals timers en interrupts worden via macro's in een hardware dependent module (HDM) geconfigureerd en tijdens initialisatie met ina 960 meegelinkt. De communicatie met de gebruiker verloopt via een message delivery mechanism (MDM) die in twee modules is gesplitst, de een bij de host en de ander bij ina 960 ondergebracht (zie figuur 4.1 ). De invulling van deze modules kan op drie manieren geschieden: a)volgens het multibus interprocessor protocol (MIP), b)volgens een base control blok interface (BCB!), of dop basis van een user-supplied interface. De MIP is gedacht voor een systeem met verschillende host kaarten op een gemeenschappelijke multibus en is hier dus niet van toepassing. De BCBI is speciaal gericht op een systeem waar slechts een host gebruik maakt van ina 960 en valt dus ook af. Het MDM van deze twee wordt met het ina pakket geleverd en hoeft slechts van enkele initialisatie routines te worden voorzien. Maar, gezien de aard van het KUNix systeem zal men de "user supplied

- 61 -

interface" moeten gebruiken waarbij de complete MDM zal moeten worden geschreven. Deze dient ten eerste een interrupt service routine te bevatten die uitgevoerd wordt als de host een request blok heeft klaargezet. Er moet een routine aanwezig zijn die na voltooiing van het request blok commando dit blok terugstuurt naar de host en tenslotte is een routine benodigd die de eigen MDM initialiseert. De communicatie software kan in meerdere opzichten naar de wensen van de gebruiker worden geconngureerd: naast de standaard transport service kunnen een datagram service, een boot server, een directe toegang tot de link laag en een network management facility (NMF) opgenomen worden.

HOST PflOCUSOR TASKS

COMPONENT SUPPORT

INA PROCESSOR

INTER~"'CE

TASKS

rNAMO

nguur 4.1 component support interface

4.2 LINK LAAG De ina 960 data link laag biedt een datagram service, houdt statistische informatie bij over de werking van het station en conngureert de 82586. Het komt overeen met de IEEE 802 specincaties en realiseert klasse 1 van de LLC sublaag. De link laag wordt aangesproken via LSAPs (Link Service Access Points), codes die een andere laag of een onafhankelijk gebruikers proces speciftceren. Behalve de transport laag die op LSAP = OFE zit (oak ina 960 heeft een lege netwerk laag), bevindt de NMF zich achter LSAP ,.. 08 en kunnen gebruikers processen directe toegang tot de link laag krijgen via LSAP 12 en hager (zie figuur 4.2 ).Dit is handig bij het booten van een station of het gebruik van een user specinek protocol in plaats van de standaard transport laag. =0

- 62 -

De link commando's zijn als voIgt:

CONNECT: Het opzetten van een verbinding tussen gebruiker en net via een LSAP. Alvorens via het net te kunnen communiceren moet een gebruikersproces aan de hand van een connect bij de link Iaag aangemeld worden. DISCONNECT: Het vrijgeven van een LSAP. Er mogen hoogstens acht LSAPs tegelijkertijd aktief zijn. TRANSMIT: Het versturen van een pakket over het net. POST RBD, POST RPD: Het klaarzetten van receive pakket descriptoren en receive buffers bij een LSAP opdat een gebruikersproces binnenkomende data kan ontvangen. Heeft een LSAP geen resources gereserveerd dan kan het geen data ontvangen. CONFIGURE: Het configureren van de 82.586 LAN controller. lA-SETUP: Het instellen van het dte adres van het station. MC-ADD. MC REMOVE: Het toevoegen/weghalen van een multicast adres aan/van de bestaande groep.

T1IIANSPOAT LA"fR

US8I TASI(

t

LSAP- Off"

NE'TWORK LA"fR

USER

TASI(

TASK

LSAI'

~

1'"

•••

tLSAP -lAM

DATA LINK USER INTlEfIIFACI!

NMF

LSAP

LSAI' -12H

uaR

~

OIH

DATA UNK INT!Il'ACf

OATAUNll: CONT1IIOLLfR

figuur 4.2 data Iink interface

NeTWOAll: !IlfOIUM

Bij initialisatie moet een configuratie file voor de link Iaag worden geexecuteerd. Deze bevat calls naar configuratie macro's waarin de gebruiker de parameters

- 63 -

van de desbetreffende laag kan invullen.

4.3 TRANSPORT LAAG Ina transport laag gebruikers hebben de keus uit twee soorten service: a) betrouwbare VC geonenteerd transport volgens ISO 8073 klasse 4 standaard. b) datagram transport. De gebruiker wordt geidentificeerd door een transport adres (TA) welke samengesteld is uit een netwerk adres (NA) en een TSAP. Voor een goede communicatie zijn per gebruiker drie soorten buffers benodigd: a) transport adres buffers om de source en destination TAs te bevatten. b) aaneengesloten buffers om initiele data tijdens het opzetten, of terminale data bij het afbreken van een VC te bevatten. c) niet aaneengesloten buffers om tijdens normaal bedrijf VC of datagram data te bevatten. Voor de ontvangst van data moeten altijd gereserveerde buffers bij het desbetre1fende TSAP klaarstaan. Is de vereiste bufferruimte niet aanwezig dan wordt de data niet ontvangen. De transportlaag krijgt zijn commando's via de request blok interface zoals in § 4.1 beschreven. De volgende commando's worden onderscheiden: OPEN: Het eerste commando bij het opzetten van een nieuwe Vc. Er wordt geheugenruimte gealloceerd om de VC descriptor te bevatten, de zogenaamde connection data base (CDB). CONNECT REQUEST: Aanvrage voor een VC naar een remote TA. AWAIT CONN REQ/TRAN: Dit is een passieve open. De transport service gebruiker geeft zijn bereidheid te kennen om passende CRs die binnenkomen te accepteren. Bij het plaatsen van een await kan het remote TA al of niet gespecificeerd zijn. 20 kan onderscheid gemaakt worden tussen de remote gebruikers die men weI en die men niet wenst aan te horen. Ais er geen "await klaarstaat" bij een zekere TSAP, en er komt een CR aanvrage binnen, dan wordt er geen VC opgezet. AWAIT CONN REQ/USER: Deze is gelijk aan de vorige met bijkomende feature dat een CR die voldoet qua adressenng en opties eerst doorgegeven wordt aan de gebruiker ter verdere beoordeling alvorens overgegaan wordt tot het opzetten van een Vc. De transport laag wacht.op het respons van de gebruiker (ACC CON REQ of CLOSE). ACCEPT CON REQ: Positief respons op het voorgaande commando. De gebruiker kan een user data buffer met dit commando meegeven ter verstuIing met de CC frame. SEND (EOM) DATA: Aanvrage voor transmissie van data buffers over gespecificeerde Vc. EOM duidt het einde van een TSDU aan.

- 64-

RECEIVE DATA: De gebruiker zet receive buffers klaar voor een bepaa1de Vc. A1s data over een VC binnenkomt waar niet voldoende buffers gereserveerd zijn. za1 de data verloren gaan. SEND EXP DAT: Aanvrage voor transmissie van ten hoogste 16 bytes user data met speed. REC EXP DATA: Het k1aarzetten van expedited data receive buffers. CLOSE: De gebruiker vraagt om sluiting van een bestaande verbinding of wijst een binnenkomende CR af. Daarbij wordt de bestaande CDB uitgeveegd. Er kan tot 64 bytes user data meegestuurd worden die zal worden ontvangen als de remote partij middels een await close hiervoor bufferruimte heeft gereserveerd. AWAIT CLOSE: De gebruiker wenst geinformeerd te worden over het sluiten van een VC als deze afgebroken wordt. Indien aanwezig, kan remote data dat met een DR werd meegestuurd worden ontvangen. SEND DGRAM: Aanvrage voor verstunng van gebufferde data via DGRAM service. RECEIVE DGRAM: Het k1aarzetten van buffers bij een TSAP voor de ontvangst van DGRAM data.

Onder iRMX kan men gebruik maken van de gebruikers vnendelijke procedure interface waarbij commando's door procedure aanroepen met meegegeven parameters worden uitgevoerd. De transport service retourneert respons infonnatie naar een in het parameter veld gespecificeerde respons mailbox na afhandeling van het commando. Ook de transport1aag wordt via een configuratie file opgezet volgens de wensen van de gebruiker.

4.4 NETWORK MANAGEMENT FACILITY

De NMF biedt planning, beheer en onderhoud van het netwerk. Planning omvat het 1everen van infonnatie over het netwerkgebruik, hetgeen van nut kan zijn bij toekomstige expansie. Onder beheer vallen alledaagse funkties a1s initialisatie en tenninatie, maar ook monitoring en optimalisatie van de performance van het netwerk. Met onderhoud wordt de detectie. iso1atie, amputatie en herstel van netwerk fouten zoa1s kortsluitingen en breuken bedoe1d. De funkties die de gebruiker direct ter beschikking staan zijn: Laagsgewijze beheer: Het inspecteren en desnoods wijzigen van interne data bases op zowe1 het 10ka1e station a1s op remote stations. Hiermee kunnen

- 65-

objecten als parameters, counters, statistische gegevens etc. worden opgevraagd en gewijzigd. Debugging: Met read memory en set memory kan het geheugen van elke host worden gewijzigd. Down line loading: Het laden van een of meerdere remote stations vanuit een station dat de boot server moo.ule bevat. Dumping: Het leveren van een geheugen image door een station op aanvrage van een remote station (upline·dump). Echo testing: Het nagaan van de aanwezigheid en bedrijfswaardigheid van een host. De NMFs op verschillende stations communiceren onderling om de besproken funkties uit te voeren. De loading en dumping funkties gebruiken slechts de

link services terwijl alle andere funkties van de transport VC service gebruik maken. Een interessante toepassing van NMF is het realiseren van een centraal boot server station dat op zijn mass storage device de programmatuur Cinclusief operating system en communicatie software) van een verzameling remote stations bevat. Deze remote stations kunnen dan bij power up via het netwerk geboot worden middels de down line loading service. Ze hoeven daartoe slechts een minimum aan boot consumer en data link software in PROM te bezitten. Bij power up van het station wordt deze code uitgevoerd. Er wordt een aanvrage bij de boot server geplaatst om met een bepaalde £lIe geboot te worden. De boot server stuurt als respons het eerste data blok bestaande uit control en data informatie waarna de consumer om het volgende blok zal vragen etc. totdat het boot proces teneinde is.

4.5 EVALUATIE

INA 960 is zonder tWijfel een veel completer pakket dan het eigen ontwerp. Bij het opzetten van een LAN zijn de faciliteiten die de NMF biedt een grote steun. Een ingebouwde boot server is erg praktisch en met name de volledige ISO compatibiliteit spreekt voor ina 960. Daarentegen zal de implementatie van het pakket op de Kunix machine niet zo een-twee -drie gaan, en is het eigen ontwerp op een aantal punten effidenter. Ina 960 werkt optimaal in een iRMX omgeving. Daarnaast kan het ook op een dedicated processor draaien. Ina 960 kan echter niet op de LEX geimplementeerd worden. Het is niet mogelijk aIle iRMX calls op LEX calls af te beelden, daarvoor is de struktuur van de beide operating systems te verschillend. Zo kent iRMX het job en het region concept die niet in de LEX

- 66 -

zijn terug te vinden. en is bijvoorbeeld de mailbox struktuur van beide operating systems helemaal anders. Resteert de mogelijkheid om ina %0 als enige applicatie op de 186 processor van een LAN kaart te implementeren. Dit gaat in tegen de fJ.losofJ.e van een 186 I/O controller met LEX multi tasking omgeving. maar er is geen andere keus. Bovendien maakt de omvang van een volledig geconfJ.gureerd ina pakket ( 50 a 60 Kbytes) de haalbaarheid van een multi tasking omgeving onder de LEX erg tWijfelachtig. Door haar volledigheid neemt ina 960 uiteraard veel meer geheugen ruimte in dan het eigen ontwerp, maar dit wordt ook veroorzaakt door de minder efficiente buffer struktuur. Op de eerste plaats is ina duurder uit doordat het zowel in de link als in de transport laag zijn data buffert. Maar vooral het feit dat ina 960 werkt met "posted buffers" maakt het erg verkwistend. Omdat de flow control op TPDU basis werkt. moeten steeds buffers van de maximale TPDU grootte (een kleine 1500 bytes) worden klaargezet. en dit terwijl de ontvangst van data vaak toch niet geanticipeerd kan worden. Zo zal in het algemeen veel te veel bufferruimte gereserveerd staan om te voorkomen dat eventuele frames van maximale omvang verloren gaan. Tenslotte moet men goed realiseren dat hoewel ina een volledige connectie georienteerde transport service conform ISO standaards realiseert. het zich met zijn datagram service weer buiten de norm begeeft. Evenals bij het eigen ontwerp is dit geen bezwaar als men zich er maar terdege van bewust is. Immers het sturen van datagram data naar een commercieel LAN produkt dat strikt een 8073 transport laag protocol uitvoert zal beslist niet goed aflopen.

- 67-

CONCWSIES

Het projekt heeft veel voorstudie vereist op terreinen als algemene LAN technieken en applicaties, communicatie protocollen en standaards, de LEX multi tasking operating system, de programmeertaal C en de Intel 82586 LANoontroller chip. Als eerste werd een werkende hardware opstelling met onboard 82586, seriele controller en kIok gerealiseerd. Hierop werd een link laag applicatie aangebracht die tevens de eerste test-software was voor de deftnitieve versie van de LEX. Met de 82586 in loopback mode (waarbij alle verstuurde data meteen door hetzelfde station weer ontvangen wordt) werden de link laag software en LEX tot een werkend geheel gemaakt. Er is een gedetaileerd en voll~g ontwerp geleverd voor de communicatie software die hier bovenop dient te komen. Hieraan werd in overleg met de coach de voorkeur gegeven boven het afieveren van een halve implementatie gebaseerd op een onvolledig ontwerp. Het ontwerp is aantrekkelijk door haar compactheid en effidentie en kan, indien daarvoor wordt gekozen, direct geimplementeerd worden. Deze fase en de testfase zijn echter pas zinvol als er ook een fysisch communicatie medium beschikbaar komt (bijvoorbeeld ethernet). Daarnaast is gekeken naar een altematieve implementatie en zijn voorstellen gedaan ten aanzien van het gebruik van het commerciele ina %0 commurucatie software pakket. Hoewel dit een uitgebreider, ECMA compatibel, pakket aan services biedt past het niet zo goed op het KUNix systeem en zal de realisatie ervan nog vele inspanningen kosten. Voorwaarde hiervoor is ook weer het beschikbaar zijn van een fysisch medium en de beschikbaarheid van de ina software zelf.

- 68-

APPENDICES

Flow charts van de processen:

ITMAN ICOPY lMAN

TSEND RDONE RCOPY

ACKMAN CDTMAN

- 69-

IT MAN ____w

~

PW\~, L f\TT. MaX

( ::tBf'l:(.)

1 ---

SEND

REC

(ON

DIS

I

CAN

I --

I

L - ._ _~ _ - - - J

!

UNBiND

I

~

a

\

VmQ.~L I,"opy Ml3X

( SE WD, II!> ph.)

,-------l---.--

VI'Y\Cl..:.L

DMA MBX

~._--"----~

Vma.~L Ic.opy MBX

v~"IA.iL ICop1 MBX:

VMCil~L IcoPY

T~I\PL ,

Au 1c.IUJ V*\LtJE.

( ... ~) 6111I0, I&ptr.)

(Lin, IBPtr)

'RI'.AO:

v~",iL \

Ie

MB'x

M&

( :r a pl.:r.)

\

lI~OPY

I

--,

J' P",a.lL I cory !"'ex

(''''0, reptr)

I

~

6

cb

SEND

LisT

R~ ...lA:

h~l:. cA ... t4.bl.\t

hoA "(t~l'l~ ad.r.

v"",..il IRESP M13ll.

(NO'/c.., "~APL) v'M«il IR£SP Max ('Ie 811'.y, iSA PL)

CALL OMA (ko~'t ~\a.rh­

".rrp\:c.)

NiSl..,

IL..-__..--_---'

...

vl'I'\~;l Infolg)(

Vi'I'\O.il IBM8X

('t13pt:r. )

v,..."il

( l13pl:(.)

I.~E~P M6X

(Lltoy,

T$~l"L)

(ALL J:.i6UF ~EO (SL)

-+ :ITo pt'(.

lit>

::1'liU.

'( "Que.ue. >--~ 'RfQUE.ST

f..-L1------------------------?'l'

N

con~t(1J(t I.TD:

"~elf

"'"",t,

cl-.t.",p\:t, o.<.\:.!;~

"Jli~e. ~ ~ll'" 1'\.lIllc!

1>muf c;{~~tr

ll\

~

VC.TP,B

(.I'ILL. DMA

Cl-lostc.ltlaptr,

V~iL

ter

E.... I101"*-1":

Sl., t

IRESP

Max (J4.ta. ,opi~, TSAfL)

"--

'i) - 71 -

VMl1IL SE: t-ID

-

M8X (5€....cL, V<.pk)

C)

CD

LON IDiS

BiNO!UNl1i~O

~

\~

host. "c\,r ~ Ts~pl

NAMe: ~ TSAP~,

,HeR

ho!.\. I\~

eNS ~ 1IAi'R,cHl.R

~ TSA~L

~ N

Co

O~il\

PRe>fNT

All "I i 13 ""F· ~eQ ( ~ iNDS~)

'(

- - liD. ph

\

C Ptll Ii auf. R. EQ (S!') ~

SET ? \; ~

""ill

y

I'D ptr

~Y 'N,Ll

lTD ,Il/ill

1'.1 QUEUE: ~

/

REq~ST

COoJ\1'RVc. T

1:"-0

N

CON!'Tf.l.vc.i 1: TD·. "ell. ho~t,

ci"Io.Ptr, "c. tsz.

CooP ~i ....

1

o

1

O/'lil'\

10 :L ToUF

CoPy <. ON. / D's

t

DATA

Ie. ...... !.iBUF

VIWI(1'i.l l.BMBX (I5 ph,)

.I VMa.'l I13nB)( (n l'tc)

PY\"lll.i l 1'1 ~6t. Me.X

~

l ,""s(", ? tr,)

P"""i l MSCA f\o1!3X ( MS(;o.

,IJ

Ph.)

1

CONs,1<,vcT MSIir T~"'p

l, .,. SI\Pl<,

,H:1. R,

(o""S1Rv<.T MSu',

J: TO ph,

TSApL, '1SApl:t,

c.lt~ 1<., 'ITD 1't'.

t

VlV>4,;l SE:NO MCx.,

'JIYICl,L 5t=:ND

(CoON)

MSl<.

(<."",(ois ,ms(" ph.)

- 72 -

""~ lA. pb'.)

P""... , L SEND

Mex:

("""P"

AW

SEND

.-)

CAN

CON

(ON / DiS

'REAO MSC»5Vf;

(.ALL

'"f)I'Ii'

c. ~ LL

c.ooJ MAN.

CANC.E

L('IAPL,

L,

1~"'f'R

ct~R, "I"'J:)~.

VAlvE. )

C.ALl

(ON

MJ:\N.

AWAiT (T)flf'L, VA

Oi~

LuJ:.)

-?Vc..ptC

CALL

c..o",

VC,t",tll.(

MAN,

CT\Apl,'I~R,

dUR, I'Op\:.r.) ~ Vc.

ptr.

I (fill

TSENO

(I);" v<'l'u)

,

JJ (ALL

v\'V\<1.~L

T,ENO

IR EST'

(l'>.l, Vel'tr.)

Mt;,X

(AW S't\;Vf,'~APl)

,II VM~iL :I:.Resp ~BX

(<:'R "'(NT, \':>Af'L)

- 73 -

v........ L I~'E~p

M1!>)(

(tl~So"'-\:;TI~)

TSEND

(.01'1

IDiS

Vc..pt(.

REI\O'

N

~ T Dpolr '-D\

Ae,.TSZ

clQ:Tar Cr. Tsi:. =A c.TSl.

TS2 =0 N

.+I..e"'l eL)'!.

CALL

;)~ ~ 1\(..; Yi!

Eo;

,,-I

IT~\Jf

(o",s"~T

'K.e L (~;O,,~f'.)

}

iSi= CoOT

Tclcah'l'tr = c.l. ... \:aptr.

y

o LVI fl.

7<

113Vf:

~LSAI'. (Q/

DR,

S.-ef.1~AllL, T~IlI'~

f"", .. i.\. \~UF

v"""Q.lL

'Mln( (T\3vf

pt·!".)

("""(.n c.o ... ~T~"CT

IRESp

M~X

.hlT,

"HAPL)

i~\)F·.

Ttlvf~c ::'10

'PbAP, SLSA~. J (c

f, DT

EOI,T~SEQ

C.ALL RES~AN

( ,)te.,

1)

S, ... RT ,",MER:

v"".. ~l "TiMER. ( DT START,

M13X

14(" V,-

)

OTii,...,

cp\lL

LSEND.

REO

(J ~t. 1<.," SVf pte, T~, ., tlvf'5l., T.4 ..I"l'lr.)

- 74-

SEND

fie.. ACt-<

At

Dr

I'\c.l,(

li.. "i2 ouT,

TiM£: ouT) \j(.

pk

ve. pte

N

y

PlY'llil TClliF Fo( i..:; Vc.1P1{3

To LAS-We. do \ F",,"11 Te.VF MBX

t

MBX (TI!>Vf ph.)

P",,,il

If>vfJlll13X

('BUF ph.)

( ,- 8\1f P~( .)

lOr-lHRV(.T Ali\ FII.III'1E I ~

CJI I

(ALL L~E ND.1l.EQ

C. ONS TAVL T

(JkR. TB'-fI'+C,

OJ<. fRAME. v(.fl. I! TI{ Y =1

IIIVf}~. Nill, Nill)

5"{Plli1."" TIMER

'REAo:

ITop\r.

c. Df

T6vfp\r

e..p,lL LSI;:ND. REG! "R £: STAR, ,i 1"1 Ell \JWIo.ill if1[R t1BX

(AA\l..f\l~Rl, VAL\! E)

(J ~(. 'R,'\)Vf l'~r,

1<
T8vrsl, NiLl, NiLL) STAIn TiMER; V"'-Illl T it'lfR.

""ex I/e.

(DT.."ART pll. , DTTit-l)

(A Il bE.NCl. R EQ

(d \
Tsvn2., HiLL,

(ALL Ls END. 'REQ (,H~R, TBvFpH,

T(}upl, Id.~A('ff.ISe)

' HiLL)

r R:NE_1 Ip~~t I

DT

~

(R

I

MI?>X ( '- R, fD

J,

.L

Dc --

I

~-

RfL fD

pl.r)

4)-=--N-----X\.?>----~,

,IJ

VMQLl Ad<

'REL RB

M13X ('-MD, 'R13Dph-.)

:ING R ECSEQ

v""""L

ReI,( MI!lX

(olD Ac.K, VLfh.)

Y

,

( A LL I R \) Uf. REQ

(~''J}Z, R6D~t<,"'H~pR)

VIY\a.~L Ac.\..(MBX I - - - - - - - - - - - - - - - - - - - K"" / "1110 .. ill

(SI;"lD,

\J(f'lc.) N

J,

f'cK

cc.. ~-

.

Ae.t,<.

.,j1V)
t

DR

1 BEL FD

FR Max

(FD rtf)

,

J,

-------'

I

.

~

~

I

- . .,

eDT

Reop! I

MAN

J

I

j

Pma.;l ReofY i

MBX

fM~;l C.DI M13)(.

I

erR-Opt-f) RBDl*f)

~

(C.DTVll.III't6t, Vc..ptr.)

i Y\; \: 1 F\D~\::(. ;'"

Y(lAB

1 Fo~

all 'Ri).. ~lo

{copy 'RG

*0

II

I R{30F

(ALL ~El1~B

i V1<"

fl! l

rcA LL RES MAN

va\l.\e.

(~EQ cPT, c.oT VRFt6)

etGl t a. pt(: d... tClf't(

-!> C.'OT

----,-----'

+S2

PI c..ts2. : Rc..\ Sc. - Se} CALL 'RES MI1N( i~"ltl t"lofj

v""",il N

(SEN\) A'~

y

(>IT

r - - - - - - ' \ E'oT

Iii JMQ,L 'Rf'- I-IBX

J!

r~ol'h) II

(cla.\MC. )

I

(DI VQ.AA 61=

ACT S2-

I I

1/

F\(\(

M€>X

1I

II eDT \JRAIIG

=1

- 77 -

,'I,-p'\() '
ACK MAN

!

1

A'~ MBX

p""C.\1

(Co MD) ve./Ra/FDph)

L

,_----' ~

4

I

i I F(A\L (oN MAN. I V, et"l t.el'" (is'''r L, · 1>1'\l"P., olld<, ... iU) ~ 'Ie pCI': I

(.All

VC.H"-"€' (i~ArL, i::'A(>l<)

II N

'Ie.

F""... i l i1)Uf

y

Mex'

:NilL

1

t P""... i\

PMQ,,\ Tc,vf

(HIJFP\:d

1B-;r

I"';l<

1\10;\

zrUV\~pTr)

(O'l1Slrvd:

(i Bvr I'trJ

~

DC,

~

rq.AME.

COr-t ~trvlt

(o(\~huc\:

Cc:.

DR

FRAME:

FI2AME

t

I

'RtL

fO,'Q13

FDJRB

(ALL L)tNOgEQ

(PI

LL LSE NO REQ

( vi k, 1" BvF (Jtr, IDvF ~e. N,LL, NiLl)

N

r<EL

I FD

~

REl

I

(ON Mf'lN.

y

C. AI.L IR Buf RE"Q ( S~J R BDpt<j i\ fill L)

- 78-

I

1<13

I

@ ~

J

-1

ec- ,

~

DC, R Bcp·k

i< \3Dplr

t

J

1

e. {\ce.'

R e.o.c.l

! I

d.1ef

ITO

pk

I

~

~ REL

(Ft LL (C;I'I \1 AN

1<.6

Vc.e. r Gl~ e(T\ II pL,T1 A?R)

II C.~ll

R £L

R.E<;Mi>,N

RB

( \~c, 1)

I

t

\Ii IT])

, "\ :'l

• ~I

•

~

(Al\'1: i avfRfL

(r

1

I

TO P\:f.)

I

i

~ (All1H,uF l'.iL

Tlllpt( 7

N

1

iLL

(lTD'" (oj

I ,

/

/

N~Y \

I

F'

( ALI IRBUf~fQ

/

"

! !

CALL RE i"IAN

YI

(<,~, KBDpk, 1SAPL)

- 79-

I I

~. t

l 1
SEw.D ~tK /CCT J " <.

N

RBV I't1

pI-<

y

<0

1 ;«iEQ '" REC.iEQ

Y

Tl<.SEQ

':" ~ l:<:.SEQ-1

AN

cOT

At\.(

".Ie.

If

1=1<.1.(,

N

t:

\iJ 'J'MCl,ll\M€r'MGx

Vt\"a i\ I 1>'-1t ( M[3 x'

((e~\".et, Ih iiMpf<)

(,> TDP,+i_/lll<)

III

upc;l,,\e CDT v~\d

~

Pf'l"a.' \

T~vl=

M!3;(

(T~l.Jf ph)

I~O

Ti"",ptf

REl

: '" NiLL

'RB

v COVld,vc.1

1I

If

R.EL

(AlL \>E"ND At\..(

().(",G4 vc.p1<)

F( (;I.vv-.€.

J

(,htr. 1~~E'Q lPT

J t:I. \ ",ph e", AcHe VaJ./I

.ITDvrddtel1

C. All L':lEND. REQ (DI=O

1

REl 1<6

(ALL 12ES MAN

lINC,1)

- 80-

AFKORTINGEN

AcACK ACK ACfIM AWCON CA CANAW CB CC CDT CNS CNT CR

CTAB

ex

DC

DGRAM DMA DR dref

DTTIM EA ECMA ED EOT FCS FD FR IB

INT

IRD IRBUF IRESP ISO ITBUF lTD LAN LLC LLCDU LSAP LSEND MAC MAN msg

NC

NH NSDU NT OSI RB RBD RECSEQ

activity acknowledge REL acknowledge REQTAB activity timer RETCNT await connection RFA channel attention RIB cancel await SCB command block sref connect confirm TBD credit TBUF central name server TC count TIM ADM connect request TPDU connection table TRSEQ command executed TSAP disconnect confirm TSDU datagram TSEND direct memory access VC disconnect request VCfAB dest ination reference VME data transfer timer expedited acknowledge . . European computer manufacturers assocIatIOn eXpedited data end of text frame check sequence frame descriptor frame receive instruction block interrupt interface receive descriptor interface receive buffer interface respond proces international standards organisation interface transmit buffer interface transmit descriptor local area network logical link control logical link control data unit link service access point link send proces media access control manager message network connection name handler network service data unit name table open systems interconnection receive buffer receive buffer descriptor receive sequence count

- 81 -

release request table retry count receive frame area response interface buffer system control block source reference transmit buffer descriptor transport buffer transport connection timer administration proces transport protocol data unit transmit sequence count transport service access point transport service data unit transport send proces virtual circuit virtual circuit table virtual module extension

LITERATUUR

1) The Cambridge distributed computing system R.M Needham & A.J Herbert 1982

Addison wesley publishing company

2) Protocols & techniques for data communication networks Franklin F. Kuo Prentice Hall Inc.

1981

3) Ina 960 programmers reference manual nr. 122193-001

1983

4) Intel LAN components user manual nr. 230814-001

5) Standard ECMA-72 Transport protocol. 2nd edition. sept. 1982

6) Standard ECMA-82 Local area networks (CSMAICD baseband) Link layer. sept 1982

7) TH verslag: Een local area netwerk voor THE KUNix machine -

Henk Peters. 1984

8) TH verslag: Ontwikkeling van systeem software voor de serie I/O controller van THE KUNix machine Rene Deliege. 1984

9) TH verslag: Disk software voor het THE KUNix systeem l.P Dubbelman. 1985

- 82 -