Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Fehler in Rechnernetzen die Sicherungsschicht IFB Speyer Daniel Jonietz 2007.

Ähnliche Präsentationen


Präsentation zum Thema: "Fehler in Rechnernetzen die Sicherungsschicht IFB Speyer Daniel Jonietz 2007."—  Präsentation transkript:

1 Fehler in Rechnernetzen die Sicherungsschicht IFB Speyer Daniel Jonietz 2007

2 dj 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 –...

3 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.

4 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!

5 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

6 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

7 Bitfehler

8 dj 8 Motivation

9 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

10 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

11 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

12 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

13 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) !!!

14 dj 14 Zyklische Redundanzcodes (CRC)

15 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

16 dj 16 CRC - Leistungsfähigkeit Beispiel CRC-CCITT G=x 16 +x 12 +x 5 +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

17 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

18 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)

19 Quittungsbetrieb

20 dj 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

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

22 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.

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

24 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!

25 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!

26 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.

27 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?

28 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.

29 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.

30 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!

31 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

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

33 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

34 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

35 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

36 Flußkontrolle

37 dj 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)

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

39 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

40 dj 40 Leaky-Bucket

41 dj 41 TCP

42 dj 42 Literatur ss2007/datenkomm/chap2/2-data-link_lay.html wiki/Transmission_Control_Protocol


Herunterladen ppt "Fehler in Rechnernetzen die Sicherungsschicht IFB Speyer Daniel Jonietz 2007."

Ähnliche Präsentationen


Google-Anzeigen