Linklaget Feildeteksjon/feilretting - pålitelig overføring Foreleser: Kjell Åge Bringsrud E-mail: kjellb 2/17/2004 1
Feildeteksjon/feilretting Oppgaver: 1. Finne feil 2. Rette feil To alternativer til å rette feil: A. Ha nok informasjon til å rette opp feil i de mottatte dataene B. Be om at dataene (rammen) blir sendt en gang til (C. Gi blanke, det er ikke så farlig å miste litt data) Generelt prinsipp i informatikken: Oppdag feilen så fort som mulig etter at den har oppstått! 2/17/2004 2
Feil-deteksjon Bit-feil i rammer behov for mekanismer som oppdager bit-feil Teknikker som ofte benyttes i datanett Cyclic Redundency Check (CRC) svært utbredt Paritet - to-dimensjonal paritet BISYNC ved ASCII overføring Sjekksum flere Internett-protokoller 2/17/2004 3
Paritet (tverrsum) Ett paritetsbit: F.eks. 7 bit data, sendes som 8 bit Like paritet dvs. et like antall enere i resultatet 0110001 sendes som 01100011 Odde paritet dvs. et odde antall enere i resultatet Odde paritet: 0110001 sendes som 01100010 Generelt: Jo mer data til redundans, jo flere feil oppdages. 2/17/2004 4
To-dimensjonal paritet Rad paritet Kolonne paritet Oppdager alle 1,2 og 3 bit feil og de fleste 4 bit feil I eksemplet: 14 bit redundant informasjon, og 42 bit melding ramme paritets byte 0 1 0 1 0 0 1 1 1 1 0 1 0 0 1 0 1 0 1 1 1 1 0 1 0 0 0 1 1 1 0 1 0 1 1 0 1 0 0 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 0 0 paritets biter 2/17/2004 5
Internett sjekksum algoritme Se på en melding som en sekvens av 16-biters heltall Senderen adderer disse heltallene sammen ved bruk av 16-bit aritmetikk Dette 16-bit tallet er sjekksummen Mottaker utfører samme beregning og sammenligner resultatet med den mottatte sjekksum Får mottaker feil resultat er det bitfeil enten i dataene eller i sjekksummen Benyttes ende til ende i Internett transportlaget 2/17/2004 6
CRC: Cyclic Redundancy Check Generalisering av paritet: Kodeord Data (med hode) Sjekk/CRC Like paritet: Kodeordet delt på 2 skal ikke gi rest CRC: Kodeordet delt på et tall, G, skal ikke gi rest Dette tallet vi deler på kaller vi Generatorpolynomet Deling foregår med modulo-2 regning, dvs ikke mente eller låning. 2/17/2004 7
Cyclic Redundency Check Kodeord Data (med hode) m biter Sjekk/CRC r biter CRC: Kodeordet delt på et Generatortall skal ikke gi rest Hvordan finner vi Sjekk/CRC? Jo, slik: 1. Generatortallet kaller vi G. G er på r+1 biter. 2. Lag et stort tall av Data med r 0-biter bak Divider dette store tallet på G Bruk modulo-2 regning (XOR, dvs. ikke noe mente) 3. Resten av divisjonen er alltid på r eller færre biter! Denne resten blir Sjekk/CRC Da vil Kodeordet være delelig på G (med 0 i rest) Data (med hode) 000 00 m biter r biter 2/17/2004 8
Desimal analogi til CRC-utregning Kodeord Data (med hode) Sjekk/CRC 82532109 0000 Anta G er 3497 825321090000 : 3497 = 236008318 med rest 1954 82532109-1954 = 825321088046 82532108 8046 825321088046 : 3497 = 236008318 nøyaktig (mente i subtraksjonen ødlegger dataene våre) 2/17/2004 9
Virkelig CRC-utregning Kodeord Data (med hode) 1101011011 Sjekk 0000 Anta G er 10011 11010110110000 : 10011 = 1100001010 med rest 1110 11010110110000-1110 = 11010110111110 1101011011 1110 11010110111110 : 10011= 1100001010 nøyaktig (og subtraksjonen ødela ikke dataene våre) 2/17/2004 10
CRC baserer seg på polynomer CRC-algoritmen ser på binærtall som polynomer. F.eks. betraktes 1 0 0 1 1 som polynomet x + x + 1 = x + x + x = 1* x + 0 * x + 0 * x + 1* x + 1* x 4 4 1 0 4 3 2 1 0 Og 1 1 0 0 0 1 som polynomet x + x + 1 = x + x + x 5 4 5 4 0 NB: Hvis polynomet er av grad r, har binærtallet r+1 biter 2/17/2004 11
Cyclic Redundency Check Regneeksemplet (sender): 10011010000 : 1101 = 11111001 1101 1001 1101 1000 1101 1011 1101 1100 1101 1000 1101 101 rest 2/17/2004 12
Cyclic Redundency Check Regneeksemplet (mottaker): 10011010101 : 1101 = 11111001 1101 1001 1101 1000 1101 1011 1101 1100 1101 1101 1101 000 rest 2/17/2004 13
Vanlige CRC polynom CRC CRC-8 CRC-10 CRC-12 CRC-16 CRC-CCITT CRC-32 C(x) x 8 +x 2 +x 1 +1 =100000111 x 10 +x 9 +x 5 +x 4 +x 1 +1 x 12 +x 11 +x 3 +x 2 +x 1 +1 =1100000001111 x 16 +x 15 +x 2 +1 =11000000000000101 x 16 +x 12 +x 5 +1 =10001000000100001 x 32 +x 26 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 + x 8 +x 7 +x 5 +x 4 +x 2 +x+1 2/17/2004 14
Egenskaper CRC-16 Alle enkle og doble bitfeil Alle feil i et odde antall bit Alle kaskadefeil av lengde mindre enn 17 99,997 % av alle 17 biters kaskader 99,998 % av alle 18 biters kaskader 2/17/2004 15
Hva bør beskyttes av CRC? Hele rammen Hele hodet ikke data Deler av hodet Vikigst: mottakeradresse og pakkelengde Kast en pakke så fort som mulig i det en CRCfeil oppdages! 2/17/2004 16
Feilretting Når skal vi rette feil? Mottakeradresse, pakkelengde mm. i hodet må eventuelt rettes med en gang. Data kan rettes med en gang eller vente Avveiing: Rette med en gang: Tar tid, ønsker vi at alle noder i nettet skal bruke tid på dette? Vente: Da kan det hende at feilen blir verre slik at det ikke er mulig å rette den lenger. 2/17/2004 17
Feilretting uten retransmisjon Kalles Forward Error Correction To-dimensjonal paritet og Hammingkoder kan benyttes Kan også sende alle pakker to ganger og sammenlikne 2/17/2004 18
Feil-korrigerende koder Bruk av Hamming-kode for å korrigere burst feil. 2/17/2004 19
Pålitelig overføring Pakker med feil CRC kastes Fint om vi kan rette opp feilen Hvis feilen ikke kan rettes opp, og vi trenger pakken, da må den sendes en gang til! Også her er det en avveiing: Ende-til ende eller mellom noder? (Problemkomplekset med doblet/triplet (mm.) funksjonalitet) 2/17/2004 20
Pålitelig overføring Når omsending av pakker er nødvendig: To fundamentale mekanismer kvitteringer (engelsk: acknowledgements, ack) tidsfrister (timeouts) vha. vekkeklokke (timer) Husk at også kvitteringer kan bli borte Ønsker vi at pakkene skal komme frem i riktig rekkefølge? 2/17/2004 21
Stop-and-Wait (stopp og vent) Sender A 2. ACK Mottaker B 1. Pakke Mottaker sender ack tilbake når en ramme er mottatt, og først når sender mottar ack, sendes ny ramme. På denne måten blir ikke mottaker oversvømmet av pakker, og avsender vet at alle pakker er kommet trygt fram. Men hva hvis pakker blir borte? 2/17/2004 22
Stop-and-Wait (stopp og vent) Grunnleggende algoritme: send én ramme og vent på kvittering (ACK ramme) dersom ACK ikke mottatt innen gitt tidsfrist, send rammen på nytt. tidsfrist ramme ACK tidsfrist ramme ramme tidsfrist ACK 2/17/2004 23
Stop-and-Wait Problem 1 med grunnleggende algoritme: Men kanskje det var ACK som ble borte Vi må kunne sende den samme rammen på nytt, selv om den allerede er kommet riktig frem ramme ACK ramme tidsfrist tidsfrist ACK 2/17/2004 24
Stop-and-Wait Problem 2 med grunnleggende algoritme: Kanskje vi sendte rammen om igjen for tidlig Vi må godta at ACK kommer for sent ramme ACK ramme tidsfrist tidsfrist ACK 2/17/2004 25
Stop-and-Wait ramme Må sende rammen på nytt og på nytt helt til ACK kommer tilbake Hvordan vet mottaker at det er den samme rammen som sendes på nytt? tidsfrist tidsfrist tidsfrist ramme ACK ramme ACK ramme ACK 2/17/2004 26
Løsning: sekvensnummer A ACK (send meg k+1) k+1 k+1 k+1 Mottaker B k+1 k k k k k Ramme nr. k Det er nok med en en-bit teller (0 og 1) k, k+1 regnes da ut modulo 2. (En buffers Sliding window protokoll) 2/17/2004 27
Sekvensnummer som 0 og 1 0 og 1 som sekvensnummere En bit er nok når vi sender én ramme av gangen og venter på kvittering ACK 1: Send ramme med odde sekvensnummer ACK 0: Send ramme med like sekvensnummer Altså: ramme 0, 1, 2, 3, 4, 5, sendes som ramme 0, 1, 0, 1, 0, 1, Går dette bra? Hva betyr det at det går bra? 2/17/2004 28
0-1 sekvensnummer Egsenskaper til korrekt løsning? Mottaker leverer aldri samme ramme to eller flere ganger til laget over (nettlaget) Ingen rammer går tapt (forutsatt at alle meldinger før eller siden kommer frem når de resendes tilstrekkelig antall ganger) Rammene leveres i samme rekkefølge hos mottager som de sendes i av senderen (forutsatt at en ramme leveres straks den er korrekt mottat og ikke mottatt før) 2/17/2004 29
0-1 sekvensnummer Analyse av sender - like ramme (0) sendes ut - ignorerer (gamle) ACK 0 - resender like ramme (0) I det ACK 1 kommer: - odde ramme (1) sendes ut - ignorerer (gamle) ACK 1 -resenderodderamme(1) I det ACK 0 kommer: - like ramme (0) sendes ut - ignorerer (gamle) ACK 0 - resender like ramme (0) I det ACK 1 kommer: osv. Vanskelig? tidsfrist tidsfrist tidsfrist ramme 0 ramme 0 ACK 1 ramme 0 ACK 1 ramme 0 ramme 1 ACK 1 ACK 0 ramme 0 levér ramme 0 ignorér ramme 0 ignorér ramme 0 levér ramme 1 2/17/2004 30
Stop-and-Wait Grunnleggende svakhet: utnytter linjekapasiteten dårlig Eksempel: Avsender senderen kan bare ha én utestående ramme til enhver tid 1.5Mbps link x 45ms RTT = 67.5Kb (8KB) dvs. 8KB data kan være underveis på linjen anta rammestørrelse 1KB stop-and-wait bruker ca. 1/8 av linjekapasiteten (om ingen feil) Mål: senderen må kunne sende opp til 8 rammer før den må vente på en ACK moralen er: fyll opp røret Mottaker 2/17/2004 31
Fyll opp røret Utnytte linjen bedre. Sender flere pakker rett etter hverandre: A Pakker B Pakker Putte ACK/NAK på ryggen til meldinger som går den andre veien ( piggyback ) 2/17/2004 32
Hvis vi ikke fyller opp røret Lange ledninger. Det tar tid før pakken kommer frem og ACK kommer tilbake. Utnyttelsen av linken kan regnes ut: Bruk av ledningen (pakkebruk): pakkelengde * sendehastighet Forsinkelse tur/retur (RTT): avstand * utbredelseshastighet * 2 + pakkebruk + ACKpakkebruk ++ Eksempel: 1500m fiber, 1/2 * 3*10 8 m/s gir 10000 ns hver vei 53 byte pakke, 1G bit/sec, 424 bit gir 424 ns. (samme i ACK) Bruksdel= pakkebruk/rtt = 424/(10000*2 +424+424++) 2% A Sender Pakke 2/17/2004 33 B Mottaker
Glidende vindu Idé: Tillat senderen å sende flere rammer før den mottar ACK for derved å holde røret fullt. Det må være en øvre grense på antall rammer som kan være utestående (som det ikke er mottat ACK for). sender mottaker Eksempel: maks. 5 utestående rammer 2/17/2004 34
Glidende vindu Flere bufre hos sender og flere bufre hos mottaker, mange pakker med forskjellige nummer og mange ack/nack med forskjellige nummer under veis hele tiden. ACK/NACK Pakker 2/17/2004 35
Glidende vindu Sendt men ikke fått ack, må kanskje sendes på nytt (vil bli resendt om ack aldri mottas) x Disse tre er motatt og kvittert (ack sendt) (men kan ikke sendes videre før x motatt) Pakker ack/nak x Ikke motatt 2/17/2004 36
Glidende vindu: sender Tilordner sekvensnummer til hver ramme (SeqNum) Vedlikeholder tre tilstandsvariable send window size (SWS) last acknowledgment received (LAR) last frame sent (LFS) Vedlikeholder invariant: LFS - LAR SWS Rammer som er bekreftet LAR Rammer som venter på å bli bekreftet N N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10N+11 N+12N+13N+14 SWS 2/17/2004 37 LFS Rammer som ikke er sendt SWS=8 flyt stoppet Når ACK mottas, økes LAR, og derved kan ny ramme sendes slik at LFS økes. Buffer for opptil SWS rammer, dvs SWS rammer i røret samtidig
Glidende vindu: mottaker Vedlikeholder tre tilstandsvariable (fig 2.23 side 107 har feil navn) receive window size (RWS) largest acceptable frame (LAF) last frame received (LFR) (with all smaller frames also received) Vedlikeholder invariant: LAF - LFR RWS Rammer som er mottat Rammer som kan mottas (muligens ute av orden) N N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10N+11 N+12N+13N+14 LFR RWS LAF 2/17/2004 38
Glidende vindu: mottaker Kumulativ kvittering ( go back n protokoll), dvs. vi ack-er ikke nye pakker hvis det er hull i sekvensen av mottatte pakker if LFR < MottatRamme.SeqNum < LAF then ta-imot-pakken-og-legg-den-på-plass; beregn-nye-grenser (MottatRamme.SeqNum); // se neste lysark else kast pakken; send ACK (LFR + 1) Rammer som er mottat Rammer som kan mottas (muligens ute av orden) N N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10N+11 N+12N+13N+14 LFR RWS LAF 2/17/2004 39
Glidende vindu: mottaker Invariant: LFR + 1 er første pakke som ikke er mottatt bergen-nye grenser(seqno) if seqno = LFR + 1 { beregn ny LFR og LAF: for (i= LFR + 1; ramme i er mottatt; i++) { } ; LFR = i-1; LAF = LFR + RWS; } første som ikke er mottatt N N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10N+11 N+12N+13N+14 SeqNum 2/17/2004 LFR LAF 40
Glidende vindu: mottaker Varianter til go back n protokoll Negativ kvittering (NAK) mottaker sender NAK på rammer som savnes Selektiv kvittering (SAK) mottaker sender ACK på nøyaktig de rammer som mottas disse behøver da ikke re-sendes Både SAK og NAK øker kompleksiteten til implementasjonen, men kan potensielt bedre utnyttelsen av linjen 2/17/2004 41
Glidende vindu: endelige sekvensnummer I praksis representeres sekvensnummer med et endelig antall biter. n biters sekvensnummer => intervall sekv. nr. = (0..2 n -1) I HDLC: n = 3, dvs. sekvensnummerintervall (0..7) sekvensnummer må gjenbrukes 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 Problem skille mellom ulike inkarnasjoner av samme numre Minimum krav: sekvensnummerintervallet må være større enn maks. antall utestående rammer 2/17/2004 42
Glidende vindu: endelige sekvensnummer SWS MaxSeqNum+1 er ikke tilstrekkelig anta 3 biters SeqNum felt (0..7) SWS=RWS=8 senderen transmitterer rammene 0..6 mottas uten feil, men ACK går tapt senderens tidsfrist utløper, rammene 0..6 sendes på nytt mottaker forventer 7,0..5, men mottar andre inkarnasjon av 0..5 SWS,RWS (MaxSeqNum+1)/2 er riktig regel 6 5 7 0 Hindrer overlapp mellom 1 4 3 2 nedre kant av sendervinduet og øvre kant av mottakervinduet. 2/17/2004 43
Glidende vindu: endelige sekvensnummer Eksempel: SWS, RWS = 4 LAR 7 0 6 1 5 2 4 3 LFS LAR 7 0 6 1 5 2 4 3 LFS send rammer 0..3 ACK 4 send rammer 0..3 7 0 6 1 5 2 4 3 7 0 6 1 5 2 4 3 NFE NFE LFA LFA Hva bør mottaker nå gjøre? 2/17/2004 44
Oppsummering Pålitelig overføring av rammer krever metoder for 1. Feildeteksjon 2. Feilkorrigering Metoder for feil-deteksjon Cyclic Redundency Check (CRC) Paritet - to-dimensjonal paritet Sjekksum Metoder for feilkorrigering Forward-error-correction (benyttes relativt lite i datanett) Retransmisjon (stop-and-wait, glidende vindu) 2/17/2004 45