INF3190 - V?r 2017


 

INF3190 - Hjemmeeksamen 1 - V?r 2017
Routing


 

Formelt

Denne oppgaven er karaktergivende og skal l?ses individuelt. Karakteren som gis teller omlag 20 % p? sluttkarakteren. Oppgaven blir vurdert etter 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 ? bruke ping fra MIP adressen 10  til MIP adressen 100.

 

Oppgave

M?let med denne oppgaven er ? implementere en rutingdaemon som tilbyr ruting-funksjonalitet 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 kommunisere med hverandre med hjelp fra mellomsystemene (intermediate systems). Systemer som bare tar imot pakker og sender dem videre p? vei til mottakeren skal virkes om rutere. Alle noder m? v?re i stand til ? jobbe samtidig b?de som endesystem og som ruter. Rutingmekanismen som skal implementeres er Distance Vector Routing (DVR) with Split Horizon (distansvektor ruting med delt horisont).

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

 

Spesifikke krav til implementasjonen

Du m? implementere en rutingdaemon. Hver host kj?rer en slik rutingdaemon, og tilbyr ruting funksjonalitet ved ? kommunisere med MIP daemonen p? samme host. Grensesnittet til MIP daemonen mot applikasjonen m? ikke forandres fra hjemmeeksamen.  Hver node skal bare st?tte en applikasjon til enhver tid, fordi MIP daemonen implementerer nettverkslaget. Nettverkslaget utf?rer ikke multipleksing og de-multipleksing for flere applikasjoner, dette er oppgaven til transportlaget. Til tross for denne begrensningen m? MIP daemonen skille mellom pakker som rutingdaemonen bruker for ? kommunisere med andre rutingdaemoner og pakke fra og til applikasjonen.

MIP daemonen m? forandres litt. Den m? kunne f? adressen til den riktige nabonoden fra rutingdaemonen slik at det blir mulig ? kommunisere mellom endesystemer som ikke er koblet til det samme Ethernet-nettverket. Dette betyr at ping serveren og ping klienten 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 nettverkslags-hop unna.

Rutingdaemonen m? svare p? foresp?rsler om ruter fra MIP daemonen for ? gi MIP daemonen muligheten til ? utf?re videresending av pakker (den mottar en destinasjonsadresse fra MIP daemonen og returnerer adressen til den riktige nabonoden). P? den andre siden m? rutingdaemonen bruke MIP daemonen for ? kommunisere med rutingdaemoner p? andre noder, noe som trenges for ? oppdatere rutingtabellene i rutingdaemonen. For ? skille mellom kommunikasjon ang?ende forwarding eller ruting m? det brukes to forskjellige sockets mellom rutingdaemonen og MIP daemonen.

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

Hvis MIP daemonen videresender en pakke i sin rolle som ruter, s? skal TTL-feltet i pakken reduseres med 1. Hvis TTLen n?r -1, m? MIP daemonen droppe pakken og ikke videresende den. Dette er n?dvendig for ? unng? at pakker g?r i evig l?kke i tilfelle av feil i rutingtabellene.

Det gis bonuspoeng for en l?sning da verken MIP-ARP-oppslag for en pakke eller ruting-oppslag for videresending av en pakke blokkerer videresending av andre pakker som ankommer senere (dvs. hvis oppslagene skjer asynkront).

 

Du skal levere f?lgende:

  1. Et designdokument som inneholder:

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

    • En forklaring p? 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.

    • En dokumentasjon av hvordan programmet skal startes evt. avsluttes.

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

    • Eventuelle andre s?regenheter.

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

    • Hva funksjonen gj?r

    • Hva inn og ut parametre betyr og brukes til

    • Hvilke globale variable funksjonen endrer

    • Hva funksjonen returnerer

Om poengfordelingen:

 

Spesifikke krav til koden

Koden din skal kompileres og vil bli testet med denne virtuelle maskinen.

 

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? sende en mail til orakel med addressen inf3190-orakel [at] ifi.uio.no

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

 

Besvarelse

Designdokumentet skal skrives vha. et egnet verkt?y, f.eks. LaTeX, OpenOffice, Word, osv. Dokumentet skal inneholde besvarelsen og 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 trenger ikke n?dvendigvis v?re s? stort, men m? inneholde tilstrekkelig informasjon til ? oppfylle kravet som beskrevet under avsnittet oppgave. Det som er viktig er ? kunne dokumentere forst?else for de emnene 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 en 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 ? laste ned arkivet du leverte inn, extracte det og unders?ke 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: Torsdag 30. march 2017 kl 23:59:59

Merk at denne tidsfirsten 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.