fehler in rechnernetzen die sicherungsschicht ifb speyer daniel jonietz 2007
TRANSCRIPT
Fehler in Rechnernetzen — die Sicherungsschicht
IFB Speyer
Daniel Jonietz
2007
dj2
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– ...
dj3
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.
dj4
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!
dj5
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
dj6
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
Bitfehler
dj8
Motivation
dj9
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
dj10
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
dj11
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
dj12
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
dj13
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) !!!
dj14
Zyklische Redundanzcodes (CRC)
dj15
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
dj16
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
dj17
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
dj18
Polynom-Beispiele
CRC-16– (16,15,2,0)
Ethernet– (32,26,23,22,16,12,11,10,8,7,5,4,2,1,0)
Quittungsbetrieb
dj20
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
dj21
Wie kommt es zu Verlust?
Pakete werden verworfen Rechner ist nicht erreichbar / ausgeschaltet /
Leitung physikalisch unterbrochen ...
dj22
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.
dj23
Quittierung des Duplikats?
Ja! Positiv, sonst: wird erneut gesendet!
dj24
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!
dj25
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!
dj26
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.
dj27
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?
dj28
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.
dj29
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.
dj30
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!
dj31
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
dj32
Folgerung aus Quittungsbetrieb
Sender– Muss auch empfangen können
Empfänger– Muss auch senden können
dj33
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
dj34
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
dj35
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
Flußkontrolle
dj37
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)
dj38
Varianten der Flußkontrolle
Feedback-based Flow Control Leaky-Bucket-Algorithmus
dj39
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
dj40
Leaky-Bucket
dj41
TCP
dj42
Literatur
http://www.barghorn-online.de/ss2007/datenkomm/chap2/2-data-link_lay.html
http://de.wikipedia.org/wiki/Transmission_Control_Protocol