Linklaget Feildeteksjon/feilretting - pålitelig overføring Foreleser: Kjell Åge Bringsrud E-mail: kjellb Frank Eliassen/Stein Gjessing, Ifi, UiO 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 ! Frank Eliassen/Stein Gjessing, Ifi, UiO 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 Frank Eliassen/Stein Gjessing, Ifi, UiO 3 1 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. (RAID: Redundant Array of Inexpensive Disks) Frank Eliassen/Stein Gjessing, Ifi, UiO 4 To-dimensjonal paritet Rad paritet Kolonne paritet paritets biter Oppdager alle 1,2 og 3 bit feil og de fleste 4 bit feil I eksemplet: 14 bit redundant informasjon, og 42 bit melding 0101001 1101001 1011110 ramme 0001110 0110100 1011111 paritets 1 1 1 1 0 1 1 1 0 1 1 1 0 0 byte Frank Eliassen/Stein Gjessing, Ifi, UiO 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 Frank Eliassen/Stein Gjessing, Ifi, UiO 6 2 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. Frank Eliassen/Stein Gjessing, Ifi, UiO 7 Cyclic Redundency Check Kodeord Sjekk/CRC Data (med hode) m biter 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 Data (med hode) m biter 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 000…00 r biter Da vil Kodeordet være delelig på G (med 0 i rest) Frank Eliassen/Stein Gjessing, Ifi, UiO 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) Frank Eliassen/Stein Gjessing, Ifi, UiO 9 3 Virkelig CRC-utregning Kodeord Data (med hode) Sjekk 1101011011 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) Frank Eliassen/Stein Gjessing, Ifi, UiO 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 4 + x + 1 = x 4 + x1 + x 0 = 1* x 4 + 0 * x 3 + 0 * x 2 + 1* x1 + 1* x 0 Og 1 1 0 0 0 1 som polynomet x5 + x4 + 1 = x5 + x4 + x0 NB: Hvis polynomet er av grad r, har binærtallet r+1 biter Frank Eliassen/Stein Gjessing, Ifi, UiO 11 CRC: Matematikk og polynomer n Data (med hode) Melding/Kodeord r CRC Bitene i meldingen oppfattes egentlig som koeffesientene i et polynom, slik at meldingen kan sees på som et polynom Generatortallet, G, er koeffesientene i et polynom, CRC-polynomet Matematisk grunnlag: polynom aritmetikk modulo-2 Frank Eliassen/Stein Gjessing, Ifi, UiO 12 4 Cyclic Redundency Check Matematisk grunnlag for CRC Representer en n-bit melding som et n-1 grads polynom ⌧eksempel: Data=10011010 tilsvarer M(x) = x7+ x4 + x3 + x1 La k være graden til generator polynomet G(x) ⌧eksempel: G(x) = x3+ x2 + 1 (dvs. k = 3) Transmitter polynomet P(x) = M(x) + CRC slik at P(x) er delelig med G(x), og motta polynomet P(x) + E(x) ⌧E(x)=0 betyr ingen feil Mottaker dividerer (P(x) + E(x)) med G(x); resten vil være null i kun to tilfeller: ⌧E(x) var null (dvs. det var ingen feil), ⌧E(x) er nøyaktig delelig med G(x). Velg G(x) slik at det andre tilfellet opptrer veldig sjeldent Frank Eliassen/Stein Gjessing, Ifi, UiO 13 Cyclic Redundency Check Hvordan beregner vi CRC-feltet? multipliser M(x) by xk (legg på k nuller) ⌧i vårt eksempel får vi x10 + x7 + x6 + x4 (10011010000) divider resultet med G(x) ⌧(i vårt eksempel: 1101) 1001101000 : 1101 = 11111001 rest: 101 Send 10011010000 - 101 = 10011010101, siden dette må være nøyaktig delelig med C(x) Frank Eliassen/Stein Gjessing, Ifi, UiO 14 Cyclic Redundency Check Regneeksemplet (sender): 10011010000 : 1101 = 11111001 1101 1001 1101 1000 1101 1011 1101 1100 1101 1000 1101 Frank Eliassen/Stein Gjessing, 101 Ifi, rest UiO 15 5 Cyclic Redundency Check Regneeksemplet (mottaker): 10011010101 : 1101 = 11111001 1101 1001 1101 1000 1101 1011 1101 1100 1101 1101 1101 Frank Eliassen/Stein Gjessing, 000 Ifi, rest UiO 16 Velge CRC polynom Intuitivt krav: Hvis rammen forandrer seg (litt), må det være lite sannsynlig at divisjonen med CRC polynomet går opp På samme måte som det er regler for hvilke tall bl.a. 2 og 3 går opp i, er det regler om hvilke tall (forandring av den orginale meldingen) G går opp i, avhengig av G. Velg derfor G med omhu. Noen egenskaper ved CRC sjekk mhp. deteksjon av feil: Alle enkel-bit feil dersom xk and x0 termene har koeffesienter som ikke er null Alle dobbel-bit feil dersom C(x) har en faktor med minst tre termer. Etthvert odde antall feil dersom C(x) inneholder faktoren (x + 1). Enhver kaskadefeil (dvs. sekvens av etterfølgende bit-feil) med lengde mindre enn k biter. De fleste kaskadefeil større enn k biter kan også oppdages. Frank Eliassen/Stein Gjessing, Ifi, UiO 17 Vanlige CRC polynom CRC C(x) CRC-8 x8+x2+x1+1 CRC-10 CRC-12 x10+x9+x5+x4+x1+1 x12+x11+x3+x2+x1+1 CRC-16 x16+x15+x2+1 =100000111 =1100000001111 =11000000000000101 =10001000000100001 CRC-CCITT x16+x12+x5+1 x32+x26+x23+x22+x16+x12+x11+x10+ CRC-32 x8+x7+x5+x4+x2+x+1 Frank Eliassen/Stein Gjessing, Ifi, UiO 18 6 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 Frank Eliassen/Stein Gjessing, Ifi, UiO 19 Implementasjon CRC Implementasjon i maskinvare av CRC algoritmene kan gjøres enkelt og raskt vha. et shift register og XOR porter Dolphin (tidliger ND, Skullerud) implementerer i SCI en CRC-16 fra en 80 byte pakke i en hastighet av 500Mbyte/sek og med noen få nanosekunders forsinkelse. NB! CRC må da ligge bakerst i pakken Frank Eliassen/Stein Gjessing, Ifi, UiO 20 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 ! Frank Eliassen/Stein Gjessing, Ifi, UiO 21 7 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. Frank Eliassen/Stein Gjessing, Ifi, UiO 22 Feilretting uten retransmisjon Kalles ”Forward Error Correction” To-dimensjonal paritet og Hammingkoder kan benyttes Kan f.eks. sende alle pakker to ganger Frank Eliassen/Stein Gjessing, Ifi, UiO 23 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) Frank Eliassen/Stein Gjessing, Ifi, UiO 24 8 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? Frank Eliassen/Stein Gjessing, Ifi, UiO 25 Stop-and-Wait (stopp og vent) Sender Mottaker 2. ACK A 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? Frank Eliassen/Stein Gjessing, Ifi, UiO 26 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. ram ram tidsfrist me me tidsfrist ACK ram tidsfrist me ACK Frank Eliassen/Stein Gjessing, Ifi, UiO 27 9 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 ram tidsfrist ACK ram tidsfrist me me ACK Frank Eliassen/Stein Gjessing, Ifi, UiO 28 Stop-and-Wait Problem 2 med grunnleggende algoritme: Kanskje vi sendte rammen om igjen for tidlig Vi må godta at ACK kommer for sent ram tidsfrist tidsfrist me ACK ram me ACK Frank Eliassen/Stein Gjessing, Ifi, UiO 29 Stop-and-Wait ram 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? me tidsfrist ram tidsfrist me ACK ram tidsfrist Frank Eliassen/Stein Gjessing, Ifi, UiO me ACK ram me ACK 30 10 Løsning: sekvensnummer ACK (send meg k+1) k+1 k+1 Mottaker k+1 A 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) Frank Eliassen/Stein Gjessing, Ifi, UiO 31 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”? Frank Eliassen/Stein Gjessing, Ifi, UiO 32 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 mottat før) Frank Eliassen/Stein Gjessing, Ifi, UiO 33 11 0 - 1 sekvensnummerram 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 - resender odde ramme (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? me 0 tidsfrist tidsfrist tidsfrist Frank Eliassen/Stein Gjessing, Ifi, UiO ram me 0 K AC 1 levér ramme 0 ram me 0 K1 AC ram ramme 0 me 1 K1 AC K 0 C A ram me 0 ignorér ramme 0 ignorér ramme 0 levér ramme 1 34 Tilstandsmaskin for en-bit protokoll Ta imot ack 0 Ta imot pakke 0 Send pakke 0 Start Ta imot ack 0 Ta imot ack 1 Send ack 1 Ta imot pakke 0 Ta imot pakke 1 Start Ta imot ack 1 Ta imot pakke 1 Sender Send pakke 1 Frank Eliassen/Stein Gjessing, Ifi, UiO Send Mottaker ack 0 35 Petrinett: Generalisert tilstandsdiagram med parallelle aktiviteter Eksempel 1 Anne Et kyss Ole Frank Eliassen/Stein Gjessing, Ifi, UiO 36 12 Petrinett: Generalisert tilstandsdiagram med parallelle aktiviteter Eksempel 2 Vil gå tur Anne Gå tur sammen Vil gå tur Ole Frank Eliassen/Stein Gjessing, Ifi, UiO 37 Et bit protokoll ACK (send meg k+1 mod 2) A 1 k k+1 k+2 k+3 k+4 k+5 0 1 0 1 0 1 1 0 B 1 0 0 Sender Mottaker ACK (send meg k+2 mod 2) A k+1 k+2 k+3 k+4 k+5 0 Ramme nr. k 0 1 0 1 0 1 0 1 B 0 1 1 1 Ramme nr. k + 1 Frank Eliassen/Stein Gjessing, Ifi, UiO 38 Stop-and-Wait Det gjør ikke noe om mottaker gjentar en ACK, men det er ikke vanlig, dvs. at det er bare vanlig å sende ACK når en pakke ankommer. Ved mye pakketap kan det være gunstig å gjenta ACK selv om det ikke kommer en ny pakke. Hvorfor? ram tidsfrist me 0 ACK ram tidsfrist Frank Eliassen/Stein Gjessing, Ifi, UiO me 0 1 ACK ram tidsfrist 1 me 0 1 CK rA am ram me 0 me 1 0 C A K 39 13 Stop-and-Wait Grunnleggende svakhet: utnytter linjekapasiteten dårlig ⌧senderen kan bare ha én utestående ramme til enhver tid Eksempel: 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” Avsender Mottaker Frank Eliassen/Stein Gjessing, Ifi, UiO 40 Fyll opp røret Utnytte linjen bedre. Sender flere pakker rett etter hverandre: A B Pakker Pakker Putte ACK/NAK på ryggen til meldinger som går den andre veien (“piggyback”) Frank Eliassen/Stein Gjessing, Ifi, UiO 41 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*108 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 B Pakke Frank Eliassen/Stein Gjessing, Ifi, UiO Mottaker 42 14 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). mottaker sender Eksempel: maks. 5 utestående rammer Frank Eliassen/Stein Gjessing, Ifi, UiO 43 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 Frank Eliassen/Stein Gjessing, Ifi, UiO 44 Glidende vindu Sendt men ikke fått ack, må kanskje sendes på nytt Disse tre er motatt og kvittert (ack sendt) (vil bli resendt om ack aldri mottas) (men kan ikke sendes Ikke motatt videre før x motatt) ack/nak x x Pakker Frank Eliassen/Stein Gjessing, Ifi, UiO 45 15 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 venter på å bli bekreftet Rammer som er bekreftet N Rammer som ikke er sendt N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14 ≤ SWS LAR SWS=8 LFS Når ACK mottas, økes LAR, og derved kan ny ramme flyt stoppet sendes slik at LFS økes. Eliassen/Stein Gjessing, Ifi, Buffer for opptil SWSFrank rammer, dvs SWS rammer i “røret” samtidig UiO 46 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 N Rammer som kan mottas (muligens ute av orden) N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14 LFR ≤ RWS LAF Frank Eliassen/Stein Gjessing, Ifi, UiO 47 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); else kast pakken; send ACK (LFR + 1) Rammer som er mottat N // se neste lysark Rammer som kan mottas (muligens ute av orden) N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14 LFR ≤ RWS Frank Eliassen/Stein Gjessing, Ifi,LAF UiO 48 16 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+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8 N+9 N+10 N+11 N+12 N+13N+14 N LFR Frank Eliassen/SteinSeqNum Gjessing, Ifi, UiO LAF 49 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 Frank Eliassen/Stein Gjessing, Ifi, UiO 50 Glidende vindu: endelige sekvensnummer I praksis representeres sekvensnummer med et endelig antall biter. n biters sekvensnummer => intervall sekv. nr. = (0..2n-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 Frank Eliassen/Stein Gjessing, Ifi, UiO 51 17 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 0 7 1 6 2 5 Frank Eliassen/Stein Gjessing, Ifi, UiO 3 4 Hindrer overlapp mellom nedre kant av sendervinduet og øvre kant av mottakervinduet. 52 Glidende vindu: endelige sekvensnummer Eksempel: SWS, RWS = 4 NFE 7 LAR 0 7 6 1 5 2 send ra mmer 0. 3 4 1 2 5 3 7 0 send 4 3 er 0.. 3 NFE 3 LFS 2 5 ramm LFA 1 6 0 6 2 4 LFA 4 ACK LFS 4 1 5 .3 LAR 7 0 6 Hva bør mottaker nå gjøre? Frank Eliassen/Stein Gjessing, Ifi, UiO 53 Samtidige logiske kanaler Multiplekser flere logiske kanaler over en punkt-til-punkt link; kjører stop-and-wait på hver logiske kanal Vedlikeholder tre biter tilstand for hver kanal : boolsk variabel som angir om kanalen er opptatt sekvens nummer for rammer som sendes på denne logiske kanalen neste sekvens nummer som forventes på denne logiske kanalen ARPANET understøtter åtte logiske kanaler over hver jord link (16 over hver satellitt link) Frank Eliassen/Stein Gjessing, Ifi, UiO 54 18 Linklaget - flytkontroll Frank Eliassen/Stein Gjessing, Ifi, UiO 55 Glidende vindu og flytkontroll Flytkontroll hindrer en sender i å oversvømme en mottaker med rammer Glidende-vindu-protokoll oppfyller tre formål pålitelig overføring bevarer ordningen av rammene ved overføring (?) ⌧mer relevant for høyere lags protokoller en link-protokoller understøtter flytkontroll Frank Eliassen/Stein Gjessing, Ifi, UiO 56 Flytkontroll Normalt en feed-back (tilbakemelding) protokoll der mottaker informerer senderen om sin buffer-kapasitet Gjerne realisert som et tillegg til glidende vindu To vanlige tilnærminger: 1. sender stopper når spesiell NAK mottas 2. mottaker informerer senderen om hvor mange pakker/bytes den har plass til, og sender ikke mer data enn oppgitt inntil den får ny beskjed (kredittbasert flytkontroll) Frank Eliassen/Stein Gjessing, Ifi, UiO 57 19 Flytkontroll - NAK Tilnærming 1: Eksplisitt NAK (Not acknowledge) I SCI sender mottaker en ACK eller en NAK for hver eneste pakke NAK: Kan ikke ta imot mer Full inn-buffer Frank Eliassen/Stein Gjessing, Ifi, UiO 58 Flytkontroll - Kreditt-basert Tilnærming 2: Kreditter (jeg har til gode hos deg) Hetrogenous InterConnect (HIC) bruker dette Jeg har plass til 4 pakker Sender Mottaker Meldingen om at mottakeren har plass til mer kan sendes som en egen melding eller bakes inn i (“piggybacked” på) annen melding i motsatt retning. Mer om flykontroll seinere (ifb. nettverks- og transportprotokoller) Frank Eliassen/Stein Gjessing, Ifi, UiO 59 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) Flykontroll hindrer en sender i å oversvømme en mottaker glidende vindu basert feed-back (NAK) eller kreditt-basert (credit-message) Frank Eliassen/Stein Gjessing, Ifi, UiO 60 20
© Copyright 2024