INF3190 - V?r 2018

INF3190 - Hjemmeeksamen 1 - V?r 2018
Ruting


 

Formelt

Denne oppgaven er karaktergivende og skal l?ses individuelt. Karakteren som gis teller omlag 20% p? sluttkarakteren. Oppgaven blir vurdert etter i hvor stor grad kravene i avsnittet "Oppgave" er oppfylt.

 

Utleverte filer

Programmet testes med mininet topologien som vist her, og python-scriptet som kan lastes ned her.

Det m? v?re mulig ? kj?re pingm?linger mellom MIP-adresse 10  og MIP-adresse 100.

 

Oppgave

M?let med denne oppgaven er ? implementere en rutingserver som tilbyr rutingfunksjonalitet til nettverkslaget. Med disse funksjonene kan nettverkslaget utf?re ende-til-ende overf?ring av pakker mellom alle endesystemer som er knyttet til nettverket. Selv om det ikke finnes noen direkte Ethernet-forbindelse mellom to endesystemer skal disse kunne kommunisere med hverandre med hjelp fra mellomsystemene (intermediate systems). Systemer som bare tar imot pakker og sender dem videre p? vei til mottakeren skal virke som rutere. Alle noder m? v?re i stand til ? jobbe b?de som endesystem og som ruter samtidig. Rutingmekanismen som skal implementeres er Distance Vector Routing (DVR) with Split Horizon (distansevektorruting med delt horisont).

Kjernen i oppgaven er implementasjonen av DVR med Split Horizon. Du m? implementere en rutingprokoll p? nettverkslaget som oppdaterer rutingtabeller slik som det er definert i DVR. Du skal anta at alle direkte sammenkoblede nabonoder har avstand 1.

 

Spesifike krav til implementasjonen

Du m? implementere en rutingserver. Hver host kj?rer en slik rutingserver, og tilbyr rutingfunksjonalitet ved ? kommunisere med MIP-daemonet p? samme host. Grensesnittet til MIP-daemonet mot applikasjonen m? ikke forandres fra den obligatoriske oppgaven.  Hver node skal kun st?tte én applikasjon til enhver tid, fordi MIP-daemonet implementerer nettverkslaget. Nettverkslaget utf?rer ikke multipleksing og demultipleksing for flere applikasjoner, dette er oppgaven til transportlaget. Til tross for denne begrensningen m? MIP-daemonet skille mellom pakker som rutingserveren bruker for ? kommunisere med andre rutingservere og pakker til og fra applikasjonen.

MIP-daemonet m? forandres litt. Det m? kunne f? adressen til riktig neste hopp (nabo) fra rutingserveren slik at det blir mulig ? kommunisere mellom endesystemer som ikke er koblet direkte til det samme Ethernet-nettverket. Dette betyr at pingserveren og pingklienten fra den obligatoriske oppgaven burde fungere uten forandring, og det burde v?re mulig for en klient ? ”pinge” en server som befinner seg mer enn ett nettverkslagshopp unna.

Rutingserveren m? svare p? foresp?rsler om ruter fra MIP-daemonet for ? gi MIP-daemonet muligheten til ? utf?re videresending av pakker. Den mottar en MIP-destinasjonsadresse fra MIP-daemonet og returnerer MIP-adressen til den riktige nabonoden. P? den andre siden m? rutingserveren bruke MIP-daemonet for ? kommunisere med rutingserverne p? andre noder, noe som trengs for ? oppdatere rutingtabellene. For ? skille mellom kommunikasjon ang?ende ruteoppslag for videresending (forwarding) og utveksling av rutinginformasjon med andre rutingservere m? det brukes to forskjellige sockets mellom rutingserveren og MIP-daemonet.

Rutingserveren m? oppdatere rutingtabellene regelmessig (periodisk). Rutingalgoritmen som brukes er Distance Vector Routing with Split Horizon (distansevektorruting med delt horisont). MIP-daemonet skiller rutingpakker (meldinger som brukes av rutingprotokollen for ? holde tabellene oppdaterte) fra MIP-ARP og fra datapakker ved ? sette TRA-bittene til 010 (dvs. ikke transport, ikke ARP, men ruting). Rutingprosessen begynner s? snart alle n?dvendige prosesser er startet p? et system. MIP-daemonet m? videresende transportpakker (TRA = 100) i henhold til den aktuelle tilstanden i rutingtabellen, eller sende dem til applikasjonen n?r destinasjonsadressen i pakken er adressen til hosten selv. Som i den obligatoriske oppgaven skal pakker droppes hvis ingen applikasjon lytter etter pakker.

Hvis MIP-daemonet videresender en pakke i sin rolle som ruter, s? skal TTL (Time To Live)-feltet i pakken reduseres med 1. Hvis TTLen n?r -1, m? MIP-daemonet droppe pakken istedenfor ? videresende den. Dette er n?dvendig for ? unng? at pakker g?r i evig l?kke hvis det oppst?r feil i rutingtabellene.

Det gis bonuspoeng til l?sninger der hverken MIP-ARP-oppslag eller rutingoppslag for videresending blokkerer videresending av andre pakker som ankommer senere (dvs. hvis oppslagene skjer asynkront).

 

Du skal levere f?lgende:

  1. Et designdokument som inneholder:

    • En forside med kandidatnummer, oppgavetittel, kurs og semester. Vi skal ikke ha navn eller brukernavn.

    • En beskrivelse av din implementasjon av Distance Vector Routing (DVR) with Split Horizon.

    • Hvordan programmet er designet. Gjerne med en tegning (flytdiagram) som viser i hvilken rekkef?lge de forskjellige funksjonene blir kalt.

    • Dokumentasjon av hvordan programmet skal startes og evt. avsluttes.

    • Hvilke filer programmet best?r av (C-filer, headerfiler osv.).

    • Eventuelle andre s?regenheter.

  2. Kildekoden, hvor koden er beh?rig kommentert (der det er n?dvendig), og en README fil som inneholder kort informasjon om hvordan programmene kj?res. Dokumenter alle variabler og definisjoner. For hver funksjon i programmet skal f?lgende dokumenteres:

    • Hva funksjonen gj?r

    • Hva inn- og utparametre betyr og brukes til

    • Hvilke globale variabler funksjonen endrer

    • Hva funksjonen returnerer

Om poengfordelingen:

 

Spesifikke krav til koden

Koden din skal kompileres p? og vil bli testet p? den samme virtuelle maskinen som ble brukt i den obligatoriske oppgaven.

 

Orakeltjeneste og administrative sp?rsm?l

F?r du problemer under implementasjonen anbefaler vi deg ? sjekke FAQ p? orakelsiden som ligger under INF3190 sin hjemmeside. Du kan ogs? stille sp?rsm?l p? Piazza. Benytt de ukentlige orakeltimene godt.

For administrative sp?rsm?l rundt hjemmeeksamen, ta kontakt med inf3190-admin [at] ifi.uio.no

 

Besvarelse

Designdokumentet skal redigeres vha. et egnet verkt?y, f.eks. LaTeX, OpenOffice, Word, osv. Dokumentet skal inneholde besvarelsen med alle etterspurte detaljer, samt ha en forside hvor f?lgende opplysninger er angitt: kandidatnummer, oppgavetittel, kurs og semester.
F?r levering skal dokumentet konverteres til PDF-format.

Omfanget av dokumentet beh?ver ikke n?dvendigvis v?re s? stort, men det m? inneholde tilstrekkelig informasjon til ? oppfylle kravene som beskrevet under avsnittet oppgave. Det som er viktig er ? kunne dokumentere forst?else for de temaene oppgaven ber?rer, i tillegg til selve gjennomf?ringen. Vi stiller krav til ryddighet og struktur.

Elektronisk innlevering

Eksamen er anonym. Bruk idchecker.sh for ? unders?ke om navnet ditt er i koden (./idchecker.sh dittBrukernavn og ./idchecker.sh enLitenDelAvDittNavn). Scriptet unders?ker om navnet ditt eksisterer i .tex, .c, .h og .txt-filer i mappa (husk ? legge til eventuelle andre filformater du bruker). Det er ditt ansvar ansvar at din innlevering ikke inneholder personlig informasjon.

Alt skal leveres elektronisk hvor alle filer (Makefile, *.c, *.h, design.pdf, README.txt, etc.) er samlet i én katalog med kandidatnummeret som navn. Av denne katalogen lager du en komprimert tar-ball. Den elektroniske innleveringen skal leveres via web. Linken Innlevering av oppgaven finnes p? kursets hjemmeside.

Etter innlevering anbefales det at du laster ned arkivet du leverte inn, pakker det ut og unders?ker at alt fungerer (inkludert at README og design er med). Det anbefales ogs? ? levere inn utkast av eksamnen i god tid f?r fristen i tilfelle du f?r tekniske problemer eller gj?r en alvorlig feil rett f?r innlevering.

Innleveringsfrist: fredag 6. april 2018 kl 23:59.

Merk at denne tidsfristen er HARD, oppgaver levert etter fristen vurderes med karakteren "F", alts? stryk.

Det forutsettes at studenten har lest forskrift om studier og eksamener ved Universitetet i Oslo for karaktergivende oppgaver.