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