-
Virheiden havaitseminen ja virheestä toipuminen [13 p]
(Tarkastanut Liisa Marttinen)
- 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
- 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
-
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
- 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.
- 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
- 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
- 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!
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)
-
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
-
Miten TCP:ssä hoidetaan vuonvalvonta? (4 p)
Arvostelusta:
viesteissä puskurin tila 2p
ei lähetetä enempää kuin tiedetään mahtuvan 2p
- 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
- 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ä.