Kurssikuulustelu 6.5.2008
Kirjoita jokaisen vastauspaperisi yläreunaan nimesi, opiskelijanumerosi tai syntymäaikasi ja allekirjoituksesi.

1. Virheiden havaitseminen ja virheestä toipuminen [13 p] (Tarkastanut Liisa Marttinen)
   1. Miten Internet-protokollat IP, UDP ja TCP pyrkivät havaitsemaan virheitä ja miten ne toimivat virheen havaitessaan? (8 p)
   
   Tässä haluttiin selvitystä tarkistussumman (Internet checksum) käytöstä IP-, UDP- ja TCP- protokollissa sekä siitä miten kukin näistä protokollista reagoi virheeseen. Kaikissa voidaan käyttää tarkistussumma. Sille on paikka kunkin protokollan otsakkeessa. Tarkistussumman avulla vain havaitaan virhe.
   UDP: käyttö valinnaista. Lasketaan koko segmentin yli. Jos käytössä, niin joko vain hylkää virheellisen segmentin tai sitten antaa sen eteenpäin varoituksen kera.
   IPv4: käytössä, mutta tarkistussumma lasketaan vain otsakkeelle. IP hylkää virheellisen paketin (ja ilmoittaa tästä ICMP-protokollalla).
   TCP: käytössä ja lasketaan koko segmentistä (+ pseudo-otsake). TCP hylkää virheelliset segmentit. TCPhavaitsee myös puuttuvan segmentin. TCP käyttää segmenttien numerointia, kuittauksia, uudelleenlähetysajastinta, jotta lähettäjä osaa lähettää virheellisen tai puuttuvan segmentin uudelleen.
   Arvostelusta.
   • 2 p UDP-selityksestä
     • 1 p optiona segmentin yli laskettu tarkistussumma
     • 1 p toiminta virhetilanteessa
   • 2 p IP-selityksestä
     • 1 p käyttää otsakkeesta laskettua tarkistussummaa
     • 1 p miten toimii virheen havaittuaan
   • 4 p TCP-selityksestä
     • 1 p segmentin yli laskettu tarkistussumma
     • 3 p miten toimii virhetilanteessa
   • +1-2 p jos on seikkaperäisemmin kertonut tarkistussumman laskemisesta
   Yleiset maininnat kuten TCP on luotettava ja UDP on epäluotettava voivat tuottaa 1/2 -1 p
   Yleisesti esiintyneitä virheitä:
   • korjataan virheellisiä bittejä
   • käytetään jotain muuta tarkistusta (pariteettibittejä, Hamming-koodia, CRC:tä) kuin internetin tarkistussummaa. Yllättävän moni ilmoitti käytettävän CRC-tarkistusta etenkin IP-kerroksella!
   • NAK-kuittauksen lähettäminen
   2. Käytössä on CRC-tarkistus ja virittäjäpolynomina (generator) on X^3 +X+1. Lähetettävä varsinainen data on 110101. Mitä saadaan CRC-tarkisteeksi ja mitä siis lähetetään linjalle? Miten vastaanottaja tietää, onko saapunut data virheellinen? (5 p)
   Virittäjä bitti muodossa = 1011 eli 1*X^3+ 0*X^2 + 1* X^1 + 1* X^0.
   Koska virittäjä on 4 bitin mittainen, niin CRC-tarkiste on 3 bitin mittainen (koska on jakojäännös on yhtä pienempi). Ennen jakoa on databittien perään siis laitettava 3 nollaa: 110101000.
   Tämä bittijono jaetaan sitten virittäjällä modolo2-jakolaskua käyttäen. Jaossa ollaan kiinnostuneita vain jakojäännöksestä.

   
       110101000
       1011 
       ----
        1100
        1011
        ----
         1111
         1011 
         ----
          1000
          1011
          ----
            1100
            1011
            ----
             111    jakojäännös 
   

   eli CRC-tarkiste, joka lisätään databittien perään. Linjalle lähetetään bitit 111010111.

   Vastaanottaja tarkistaa saadun bittijonon jakamalla sen virittäjällä. Jos jako menee tasan eikä mitään jakojäännöstä synny (= pelkkiä nollia), niin hyväksytään data virheettömänä,>muuten se katsotaan virheelliseksi.

   Arvostelusta:

   • 1p oikea virittäjä
   • 2 p lasku suoritetaan oikein ja lopputulos on oikea
     • -1 p jos unohdettu nollat
     • -1 p jotain virhettä laskussa ja tulos siksi väärin
   • 1 p jos osaa kertoa laskutoimituksen idean, vaikka ei osaakaan sitä suorittaa
   • 1 p osaa liittää tarkisteen datan perään
   • 1 p osaa kertoa miten vastaanottaja huomaa datan virheelliseksi

2. Lähiverkoista [17 p] (Tarkastanut Liisa Marttinen)
   Kuvan reititin (router) R2 vastaanottaa toiselta reitittimeltä R1 oman Ethernet-lähiverkkonsa koneelle A osoitetun paketin (datagrammin), joka sisältää HTTP-vastauksen koneen lähettämään HTTP-kyselyyn. Vastauksen lähettäjä on kone B jossain Internetissä. Reitittimen R2 oma lähiverkko koostuu kytkimillä (switch) ja keskittimillä (hub) yhdistetyistä lähiverkoista.

   Kuva verkosta

   1. Minkä eri protokollien otsakkeita ja dataa reitittimen R2 vastaanottama paketti sisältää? Piirrä kuva. (3 p)

   
           |-------------------|
           |  IP-otsake        |
           |-------------------|
           |  TCP-otsake       | 
           |-------------------|
           | HTTP-response:    |
           |   otsaketiedot +  |
           |   vastaustiedosto |    
           --------------------
   

   Jos on vielä laittanut tämän linkkitason kehykseen, niin siitä ei ole mennyt pisteitä, jos kehyksen sisällä on ylläolevat asiat.
   Reititin sinänsä käsittelee vain verkkokerroksen datagrammeja, mutta reitittimessa on myös linkkitason toiminnot ja protokolla.

   Arvostelusta:
   Jokaisesta oikeassa järjestyksessä olleesta ja oikean nimisestä otsakkeesta yksi piste.

   2. Minkä muotoisena reititin R2 lähettää paketin kytkimelle? Piirrä kuva, josta selviää erityisesti eri kerroksilla käytetyt osoitteet. (3 p)

   R2 lähettää saamansa paketin kytkimelle Ethernet-kehyksessä:

                             
                                 
           |-------------------|  Ethernet-otsake: 
           | MAC-kehys         |    Source: 1A-23-F6-CD-06-9B  (=R2)
           |                   |    Destin: 88-B2-2F-54-1A-0F   (=A) 
           |-------------------|    
           |                   |  IP-otsake:
           |  IP-otsake        |    Source: 222.11.6.7 (=B)     
           |                   |    Destin.: 22.35.41.3 (=A)  
           |-------------------|
           |  TCP-otsake       | TCP-otsake:
           |                   |   Source port: B:n portti 80
           |                   |   Destin. port: A:n portti abc
           |-------------------|
           | HTTP-response:    |
           |   otsaketiedot +  |
           |   vastaustiedosto |    
           --------------------
   

   Tässä tärkeitä ovat MAC- ja IP-osoitteet. Porttinumeroista ei niinkään ole väliä, niitähän ei edes tiedetä.
   IP-paketti on matkalla B:ltä A:lle. Sille reititin on 'tuntumaton'. Ethernet-kehys siirtyy R2:lta A:lle. Sille sekä kytkin että keskitin ovat 'tuntumattomia'.

   Arvostelusta:

   • 1 p Ethernet-kehyksessä
   • 1/2 p kukin osoite
   3. Miten aliverkkoja yhdistävä kytkin (switch) osaa ohjata saamansa kehyksen oikeaan aliverkkoon? (5 p)
   Tässä haluttiin selvitystä kytkintaulusta, sen sisällöstä ( MAC-osoite, sitä vastaava linkki ja elinaika), tietojen keräämisestä eli takaperin oppimisesta (backward learning, self-learning) (= kaikista kytkimen kautta kulkevista kehyksistä talteen lähettäjän MAC-osoite ja linkki, josta kehys tuli), kytkintaulun käytöstä ( = etsitään MAC-osoitetta vastaava linkki ja lähetetään kehys sinne) sekä toiminnasta tilanteessa, jossa tietoa ei löydykään taulusta (= tulvitetaan kehys kaikkialle). Jos kehyksen lähettäjä on saman linkin takana kuin vastaanottaja, kehystä ei välitetä mihinkään.

   Tässä tapauksessa A on juuri lähettänyt kyselyn B:lle, joten sen tiedot ovat varmaankin vielä kytkintaulussa.

   Arvostelusta:

   • 2 p kytkintaulun sisältö
   • 1-2 p kytkintaulun päivittäminen ('takaperin oppiminen')
   • 1-2 p kytkintaulun käyttö (ohjaus linkkiin tai tulvitus, jos ei löydy taulusta)

   Yleisiä virheitä:

   • kytkin lähettää kyselyn, johon etsitty kone vastaa
   • Kytkin käyttää ARP-taulua.
   • Kykin lähettää automaattisesti kaikkiin linkkeihin
   4. Miten keskitin toimii, kun se vastaanottaa kehyksen? (1 p)

   Keskitin vain toistaa saamansa bitit kaikkiin muihin linkkeihin paitsi siihen, mistä ne tulivat. (Tämä on siis fyysisen tason laite, joka ei tiedä mitään kehyksistä tai MAC-osoitteista.)

   Tämän asian olivat lähes kaikki osanneet!
   

   5. Missä vaiheessa ja miksi voidaan tarvita ARP-protokollaa? Miten sitä käytetään ja mitkä laitteet käyttävät? (5 p)

   Aina kun on muutettava IP-osoite MAC-osoitteeksi, voidaan tarvita ARP-protokollaa. Jos tietoa (= IP-osoitetta ja sitä vastaavaa MAC-osoitetta) ei löydy ARP-taulusta, osoitetta kysytään ARP -protokollaa käyttäen.
   Kyselijä lähettää lähiverkkoon yleislähetyksenä linkkikerroksen kehyksen, jonka sisällä on verkkokerroksen ARP-kysely “Kenellä on IP-osoite: a.b.c.d?” ja se kone, joka tunnistaa oman osoitteensa vastaa suoraan kyselijälle ja kertoo näin oman MAC-osoitteensa.

   Esimerkiksi, kun R2 haluaa selvittää A:n MAC-osoitteen, se lähettää ARP-kyselyn, johon A vastaa kertomalla oman MAC-osoitteensa:

          |---------------------------------|
          |  Ethernet-kehys:                |
          |                                 |
          | S:1A-23-F6-CD-06-9B (=R2)       |
          | D:FF-FF-FF-FF-FF-FF (kaikille)  |
          |                                 |
          |---------------------------------|
          |  ARP-paketti:                   |
          |                                 |
          | "Kenellä IP-osoite: 11.35.41.3?"|
          |                                 |          
          |---------------------------------|
   
    
   
          |---------------------------------|
          |  Ethernet-kehys:                |
          |                                 |
          | S:  88-B2-2F-54-1A-0F (= A)     |
          | D:  1A-23-F6-CD-06-9B (=R2)     |
          |                                 |
          |---------------------------------|
          |  ARP-paketti:                   |
          |                                 |
          | "IP-osoitetta 11.35.41.3 vastaa |
          |  MAC-osoite   88-B2-2F-54-1A-0F"|          
          |---------------------------------|
   

   (Näitä nyt ei tarvinnut piirtää! Näin tarkkaan tätä ei tässä tarvinnut selittää. Ja todellisessa ARP-paketissa on paljon muutakin tietoa.)

   Koska ARP-kysely toimii verkkokerroksella, niin sitä voivat käydä vain ne laitteet, joissa on verkkokerros eli reitittimet ja isäntäkoneet. Kuvan laitteista mm. A ja B sekä R1 ja R2.

   Arvostelusta:

   • 1 p: IP-osoite => MAC-osoite
   • 2-3 p: ARP-protokollan toiminta: kysely, vastaus, ARP-taulu, verkkokerroksen protokolla
   • 1-2 p: Mitkä laitteet käyttävät yleensä ja/tai tässä

   3. TCP:n ruuhkanhallinta ja vuonvalvonta [20 p] (Tarkastanut Sebastian Siikavirta)

   1. Mitä tarkoitetaan vuonvalvonnalla (flow control) ja ruuhkanvalvonnalla (congestion control)? Miksi niitä tarvitaan? (4 p)
      Arvostelusta:
      vuon: ettei lähettäjä nopeammin kuin vastaanottaja 2p
      ruuhka: verkossa ruuhkaa, reitittimet 2p

   2. Miten TCP:ssä hoidetaan vuonvalvonta? (4 p)
      Arvostelusta:
      viesteissä puskurin tila 2p
      ei lähetetä enempää kuin tiedetään mahtuvan 2p

   3. Esitä, miten TCP:n ruuhkanhallinta toimii tilanteessa, jossa halutaan lähettää 200 KBlinjalla, jonka kiertoviive on 100 ms. Kynnysarvo (threshold) on aluksi 32 KB ja yhdessä segmentissä voidaan lähettää korkeintaan 2 KB (= maximum segment size). Oletetaan, että lähetystä rajoittaa vain ruuhkaikkuna eikä mitään ongelmia esiinny, vaan segmentit ja niiden kuittaukset saapuvat ajoissa perille. (6 p)
      Arvostelusta:
      slowstart 2p
      threshold huomioitu, ruuhkanvälttely 2p
      laskettu ja laskut oikein 2p
      aloitus voi lähteä 1 tai 2 paketista(rfc2581), molemmat ok
      

   4. Entä jos 10. lähetetty segmentti saapuu virheellisenä perille, mitä tällöin tapahtuu? Kuinka lähettäminen tästä jatkuu? Onko tässä eroa sillä, käytetäänkö TCP:n versiota Tahoe vai Reno? Jos on, niin miten eroavat? (6 p)
      Arvostelusta:
      ilman ackeja: ruuhkaikkuna=1, slowstart, threshold puoliksi 4p
      reno 3:lla ackilla: nopea uudelleenlähetys, fast recovery 2p
      Eli yleisesti toiminnan selityksestä 4p ja 2p kun selittää renon tapauksessa jos kerkeää tulla 3 ackia.

   Outouksista ja virheistä miinuspisteitä.