Fehler in Rechnernetzen — die Sicherungsschicht

Präsentation zum Thema: "Fehler in Rechnernetzen — die Sicherungsschicht"—  Präsentation transkript:

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 Dienst Rahmen unabhängig, Empfang nicht bestätigt verbindungsloser, bestätigter Dienst Rahmen unabhängig, Empfang bestätigt verbindungsorientierter, bestätigter Dienst Rahmen sind nummeriert, in richtiger Reihenfolge, jeder Rahmen bestätigt. Verbindungsauf- und abbau nötig! dj

5 Rahmenbildung Feste Rahmenlänge Flagbytes / Flagbits
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 vorliegt Paritä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 Empfänger
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 ( =33) Was taugt dieses Verfahren? ( =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 Ethernet (16,15,2,0)
(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 fehlt Sender 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 Halbduplex (Voll-)Duplex
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 Lösung:
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 ss2007/datenkomm/chap2/2-data-link_lay.html wiki/Transmission_Control_Protocol dj