Fehler in Rechnernetzen — die Sicherungsschicht

1. Fehler in Rechnernetzen— die Sicherungsschicht IFB Speyer Daniel Jonietz 2007

2. Worum gehts? • Es können verschiedene Fehler auftreten: • Pakete werden bei Übertragung geändert • Pakete gehen komplett verloren • Pakete werden in einer zeitlich anderen Reihenfolge übertragen • Pakete werden dupliziert • Pakete werden zu schnell empfangen • ... dj

3. Also: • Aufgaben der Sicherungsschicht: • Daten in der richtigen Reihenfolge ausliefern • Daten fehlerfrei ausliefern • dabei den Empfänger nicht überfordern (Organisation des Datenflusses) • Dazu legt die Sicherungsschicht die Pakete in einen Rahmen (frame), bestehend aus Header, Payload (=Paket) und Trailer. dj

4. Dienste • Man unterscheidet drei verschiedene Dienste: • verbindungsloser, unbestätigter DienstRahmen unabhängig, Empfang nicht bestätigt • verbindungsloser, bestätigter DienstRahmen unabhängig, Empfang bestätigt • verbindungsorientierter, bestätigter DienstRahmen sind nummeriert, in richtiger Reihenfolge, jeder Rahmen bestätigt.Verbindungsauf- und abbau nötig! dj

5. Rahmenbildung • Feste Rahmenlänge • festgelegt oder durch Längenangabe im Header • Längenangabe fehlerhaft? • Flagbytes / Flagbits • Flags in Daten? Stuffing • Kodierungsverletzungen • benötigt doppelte Bandbreite dj

6. Paketänderungen • Was möchte man? • Mindestens: Feststellen, dass ein Fehler vorliegtParitätsbits, Prüfsummen, CRC • Schön wäre aber auch: Fehler reparieren  Hamming-Code, vgl. Skript WBL dj

7. Bitfehler

8. Motivation dj

9. Welche Bitfehler gibt es? • Einzelbitfehler • Ein Bit ist „gekippt“, d.h. falsch • Doppelbitfehler • Zwei aufeinanderfolgende Bits sind gekippt • Fehlerbündel • N aufeinanderfolgende Bits sind falsch dj

10. Wie stellt man Paketänderungen fest? • Grundsätzlicher Lösungsansatz: Einführen von Redundanz • Paritätsbit • Prüfsummen • Redundanzcodes • Hammingcodes • Rahmenformat muss geändert werden • neue Vereinbarung (Protokoll) nötig dj

11. Allgemeiner Ansatz • Sender • wendet Algorithmus auf zu sendende Daten an, dieser liefert die Prüfbits • versendet Nutzdaten und Prüfbits • Empfänger • trennt Daten und Prüfbits voneinander • wendet gleichen Algorithmus auf die Nutzdaten an • vergleicht gesendete Prüfbits mit den selbst ermittelten dj

12. Paritätsbits • Idee: Ein zusätzliches Bit gibt an, wie viele Bits 1 sind • Varianten: • Gerade Parität (Anzahl 1 gerade  Parität 0)das PB wird so gesetzt, dass Anzahl 1er gerade • Ungerade Parität (Anzahl 1 ungerade  Parität 0) • Erfolg: • Es werden nur „ungeradzahlige Bitkipper“ detektiert dj

13. Prüfsummen • Verschiedene Varianten • Z.B. einfache „Summe“ modulo 100: • Zwei Prüfstellen, der Einfachheit halber betrachten wir Dezimale • 06 23 04 33 (06+23+04=33) • Was taugt dieses Verfahren? • 08 20 05 33 (08+20+08=33) !!! dj

14. Zyklische Redundanzcodes (CRC) dj

15. CRC - Details • Bitfolgen werden als Polynome aufgefasst • Berechnungen erfolgen ohne Berücksichtigung möglicher Überträge • Sender und Empfänger einigen sich auf ein Generator-Polynom • Prüfbits = Rest der Division Daten / GP • Gibt normierte Polynome, z.B. CRC-4 dj

16. CRC - Leistungsfähigkeit • Beispiel CRC-CCITT G=x16+x12+x5+1 • Entdeckt alle Einzelbitfehler, alle Doppelbitfehler, alle Bitfehler mit ungerader Bitanzahl, alle Fehlerbündel bis zu 16 Bit Länge • Entdeckt 99,997% aller 17-Bit-Fehlerbündel • Entdeckt 99,998% aller Fehlerbündel mit 18 oder mehr Bits dj

17. Woher kommt das CRC-Polynom? • „Choosing a poly is somewhat of a black art“ (Ross N. Williams: “A painless guide to crc error detection algorithms”) • Viel Mathematik dj

18. Polynom-Beispiele • CRC-16 • (16,15,2,0) • Ethernet • (32,26,23,22,16,12,11,10,8,7,5,4,2,1,0) dj

19. Quittungsbetrieb

20. Erster Ansatz • Rahmen korrekt angekommen? • Sende positive Quittung (ACK) • Rahmen angekommen, Fehler erkannt? • Sende negative Quittung (NAK)Sender sendet Rahmen erneut • Rahmen nicht angekommen • wann weiß man das? • man führt Timer ein dj

21. Wie kommt es zu Verlust? • Pakete werden verworfen • Rechner ist nicht erreichbar / ausgeschaltet / Leitung physikalisch unterbrochen • ... dj

22. Ansatz mit Timern • Sender schickt Rahmen und startet Timer • Empfänger prüft und schickt ACK oder NAK • kommt ACK wird Timer bei Sender gelöscht • kommt NAK wird Timer bei Sender gelöscht und Sendeprozess beginnt erneut (inkl. neuem Timer) • läuft Timer ab, ohne dass ACK oder NAK ankamen: • entweder der Rahmen erneut geschickt, aber Probleme wenn Originalrahmen doch ankam oder ankommt: Duplikat erzeugt! • oder eine Problemmeldung an den Empfänger gesendet. dj

23. Quittierung des Duplikats? • Ja! Positiv, sonst: wird erneut gesendet! dj

24. Send and Wait • Wird so für jeden Rahmen verfahren, nennt man das Send and Wait-Protokoll (auch Stop and Wait) • Einen Rahmen senden, auf Quittung warten und entsprechend reagieren. • Nachteil: • Wenn Rahmen verloren geht, muss der Timer abgewartet werden, bevor weitere Daten gesendet werden können! dj

25. Wenn Duplikat auftritt • ACK ist verloren gegangen, Rahmen erneut gesendet: Empfänger kann das nicht erkennen. • Folgerung:Rahmen durchnummerieren. Duplikate haben die gleiche Nummer und können erkannt werden. • Frage:Wie viel „Platz“ reservieren wir für die Nummern? Anzahl der Rahmen ist kaum abzuschätzen! dj

26. Einfache Sequenznummer • Kann keine Verwechslung von Paket m und m+2 geben, sonder nur zwischen m und m+1 • Reicht also Pakete abwechselnd 0 und 1 anzuhängen. dj

27. Huckepack-Quittungen • Der Versand eines kompletten Rahmens nur für eine Quittung ist Verschwendung • Besser:Warte, bis selbst Daten zu versenden sind und versende die Quittung mit den Daten mit. • Nachteil:Wie lange soll gewartet werden, bis Daten vorliegen? dj

28. Schiebefenster-Protokolle • Sender und Empfänger verwalten, wie viele Rahmen sie versenden bzw. empfangen in „Fenstern“ • Fenstergröße=1 entspricht Send and Wait wie besprochen • Fenstergröße>1 führt i.A. zu besserer Auslastung. dj

29. gehe-n-zurück • Sender sendet kontinuierlich Daten • Empfänger quittiert (einzeln) • Angenommen Rahmen 2 geht verloren:ACK für Rahmen 2 fehltSender sendet trotzdem weiter bis Timeout für Rahmen 2, merkt dann, das etwas nicht stimmt und sendet alle Rahmen ab 2 erneut. dj

30. selektive Wiederholung • Sender sendet kontinuierlich Daten • Empfänger quittiert (einzeln) • Angenommen Rahmen 2 geht verloren:Empfänger merkt das bei Eintreffen des Rahmens 3 und sendet NACK für Rahmen 3. • Sender sendet Rahmen 2 erneut, fährt danach vor wie gehabt. • Sender und Empfänger müssen Puffer führen! dj

31. Paketverlust: Ursachen • Problem: Pakete können verloren gehen • Grenzfall: „lange“ Übertragungsdauer • Ursachen: • Empfänger verwirft Paket, weil er einen Fehler feststellt • Empfänger ist nicht in der Lage Paket zu empfangen • Netzwerk verliert das Paket, verwirft das Paket oder leitet es falsch weiter dj

32. Folgerung aus Quittungsbetrieb • Sender • Muss auch empfangen können • Empfänger • Muss auch senden können dj

33. Datenfluss • Simplex • A kann nur senden, B nur empfangen • Halbduplex • A und B können senden und empfangen, aber nie gleichzeitig • (Voll-)Duplex • A und B können senden und empfangen, sogar gleichzeitig dj

34. Geänderte Paket-Reihenfolge • Idee: Sequenznummern • Sender nummeriert die versendeten Pakete durch • Empfänger ist dann anhand der Nummern in der Lage, die Reihenfolge wieder herzustellen dj

35. Weitere Probleme … • Die Quittung geht (wiederholt) verloren • Z.B. wenn Empfänger grundsätzlich nicht senden kann • Sender würde endlos lange versuchen, das Paket zu übertragen • Lösung: • Hat der Sender N-mal versucht ein bestimmtes Paket zu senden gibt er auf. • Anderer Ansatz: Mittels 3-Wege-Handshake die Quittung bestätigen dj

36. Flußkontrolle

37. Wozu? • Der Sender darf nur so schnell senden, wie der Empfänger die Daten verarbeiten kann. • Wird absichtlich zu schnell gesendet, spricht man von flooding (fluten) dj

38. Varianten der Flußkontrolle • Feedback-based Flow Control • Leaky-Bucket-Algorithmus dj

39. Feedback-based Flow Control • Der Empfänger sendet nach jedem empfangenen Paket eine Bestätigung an den Sender, dass er wieder empfangsbereit ist • Entspricht etwa unserem vorgestellten Quittungsbetrieb dj

40. Leaky-Bucket dj

41. TCP dj

42. Literatur • http://www.barghorn-online.de/ss2007/datenkomm/chap2/2-data-link_lay.html • http://de.wikipedia.org/wiki/Transmission_Control_Protocol dj