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.