Fehler in Rechnernetzen — die Sicherungsschicht IFB Speyer Daniel Jonietz 2007

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

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

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

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

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

Bitfehler

Motivation dj

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

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

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

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

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

Zyklische Redundanzcodes (CRC) dj

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

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

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

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

Quittungsbetrieb

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flußkontrolle

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

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

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

Leaky-Bucket dj

TCP dj

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