ECN. Explicit Congestion Notification ECN

Transkript

1 Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN ECN Explicit Congestion Notification Jedes auf dem Internet Protocol (IP) basierende Netz und insbesondere ein IP-Weitverkehrsnetz wie das Internet verfügt über eine bestimmte Menge von Ressourcen (Speicher in Knoten, Übertragungskapazität von Leitungen), die durch die einzelnen aktiven Verbindungen dynamisch verbraucht werden. Sind derartige Ressourcen knapp, können Engpässe im Netz entstehen, sodass man von einer Netzüberlastung, engl. Network Congestion, spricht. Negative Auswirkungen sind, dass einerseits die übertragenen IP-Pakete verloren gehen können und man andererseits mit großen Verzögerungen der IP-Pakete im Netz rechnen muss. Daher ist ein Protokoll nötig, das Überlastungen in IP-Weitverkehrsnetzen zunächst signalisiert und dann vermeidet. Als ein solches Protokoll ist Explicit Congestion Notification (ECN) anzusehen. Das allgemeine Konzept von ECN wurde von der Internet Engineering Task Force (IETF) 1 im Dokument RFC spezifiziert. Mithilfe von ECN werden die Überlastsituationen in IP-Netzen den Rechnern signalisiert, die gerade ihre IP-Pakete ins Netz senden. Dazu werden bestimmte Angaben sowohl im TCP 3 - als auch im IP- Header in den zu sendenden IP-Paketen eingetragen. Daher ist ECN ein Protokoll, das im OSI 4 -Referenzmodell den Schichten (Layers) 3 und 4 zugeordnet werden kann. Nach ECN kann ein Router im IP- Netz, über den eine TCP-Verbindung verläuft, einem Rechner am Ende der TCP-Verbindung signalisieren, dass eine Überlastsituation aufgetreten ist, sodass die Menge der zu sendenden Daten reduziert werden soll. Als Verfahren, nach dem ein Rechner vorgeht, um eine Überlastsituation zu vermeiden, wird oft RED (Random Early Detection/Discard) verwendet aktualisiert durch RFC 4301 und RFC Transmission Control Protocol 4 Open Systems Interconnection 1

2 Struktur eines IP-Netzknotens Die zu übertragenden IP-Pakete im Netz müssen in der Regel vor der Übertragungsleitung auf das Aussenden warten. Daher müssen sie temporär in einem Router bzw. Switch als Netzknoten zwischengespeichert werden. Hierfür werden im Speicher entsprechende Warteschlangen (Queues) organisiert, sodass man auch vom Queueing in IP-Netzen und vom Queue Management (QM) spricht. Darunter versteht man unterschiedliche Verfahren, die bestimmen, wie die Warteschlangen der zu sendenden IP-Pakete organisiert und bedient werden. Anmerkung: Queue Management tritt nicht nur in IP-Netzen auf, sondern auch in anderen Netzen mit Paketvermittlung. Queue Management wird auch in Rechnerbetriebssystemen implementiert, wo die einzelnen Aufgaben (Tasks) auf den Prozessor warten müssen. Zur Darstellung der Überlastprobleme zeigt Bild die vereinfachte Struktur eines Knotens in einem IP-(Weitverkehrs-)Netz. Im IP-Netzknoten (Switch, Router) findet Queue Management immer vor Ausgangsleitungen statt. Bild : Allgemeine Struktur eines IP-Netzknotens AUS: Ausgangsleitung E: Empfänger EIN: Eingangsleitung F: Forwarding (Switching, Routing) QM: Queue Management S: Sender Die in einem IP-Netzknoten empfangenen IP-Pakete werden einem Modul übergeben, das sie zu einer Ausgangsleitung weiterleitet. Dieses Modul wird im Allgemeinen als Forwarder bezeichnet und realisiert in einem Switch das Switching bzw. in einem Router das Routing. Diese beiden Funktionen Routing und Switching beste- 2

3 hen in der Weiterleitung von empfangenen IP-Paketen an die in ihnen enthaltenen Ziel-IP-Adressen. Was verursacht eine Netzüberlastung? Da jeder Knoten im IP-Netz über eine begrenzte Speicherkapazität für die Zwischenspeicherung (Pufferung) von IP-Paketen verfügt, hat jedes IP-Netz speziell ein IP-Weitverkehrsnetz eine bestimmte Aufnahmekapazität. Damit kann sich nur eine begrenzte Anzahl von IP-Paketen im Netz zu einem bestimmten Zeitpunkt befinden. Wird diese Anzahl überschritten, entstehen für den Netzbenutzer folgende negative Auswirkungen: Die Aufnahmepuffer im Netz (in Knoten) sind voll, was dazu führt, dass die im Netz eintreffenden IP-Pakete verworfen werden müssen. Vor den Übertragungsleitungen bilden sich lange Warteschlangen von IP-Paketen, was große Verweilzeiten der IP-Pakete im Netz verursacht. Dadurch entstehen große Verzögerungen der zu übertragenden IP-Pakete. Es müssen somit Maßnahmen ergriffen werden, um diese negativen Auswirkungen der Überlastung des IP-Netzes zu vermeiden. Diese Maßnahmen führen zur Überlastkontrolle (Congestion Control). Darunter werden alle Vorkehrungen verstanden, die verhindern sollen, dass das IP-Netz überlastet wird. Um derartige Vorkehrungen in IP-Netzen zu treffen, kann ECN eingesetzt werden. Die wichtigsten Kriterien für die Beurteilung der Congestion von Netzen sind: Durchsatz Verweilzeit der IP-Pakete im Netz (Verzögerung) Unter dem Durchsatz (Throughput) eines Netzes versteht man den Anteil des Datenverkehrs, den das Netz akzeptiert. Den Verlauf des Durchsatzes in Abhängigkeit vom gesamten Datenverkehr zeigt Bild Ist der Datenverkehr im Netz klein (geringe Belastung), so nimmt das Netz alle ankommenden IP-Pakete vollständig auf. Bei einer geringen Belastung des Netzes sind normalerweise keine Vorkehrungen gegen Überlastung erforderlich. Dagegen müssen bei einer 3

4 hohen Netzbelastung bestimmte Maßnahmen ergriffen werden, um die Überlastung zu vermeiden. Diese Maßnahmen führen zur Einschränkung der Datenmenge, die ins Netz gesendet wird. Bild : Auswirkung der Netzbelastung auf den Durchsatz Ist der Datenverkehr im Netz so stark, dass das Netz als überlastet zu bezeichnen ist, müssen andere Aktionen eingeleitet werden, mit denen die bestehende Überlastung beseitigt werden kann. Wie aus Bild ersichtlich ist, nimmt der Durchsatz in der Überlastsituation mit zunehmendem Datenverkehr sehr stark ab. Bild veranschaulicht, welche Auswirkungen die Netzbelastung auf die Verzögerung (Latency, Delay) von Daten im Netz hat. In einer Überlastsituation muss mit großen Verzögerungen für die Datenübertragung im Netz gerechnet werden. Bild : Auswirkungen der Netzbelastung auf die Verzögerung der IP-Pakete im Netz 4

5 Die wichtigste Maßnahme für die Vermeidung von Überlastungen besteht in der Reduzierung der Datenströme, die ins Netz fließen. Dies kann durch eine entsprechende Regelung der Flusskontrolle (Flow Control) beim Transportprotokoll TCP mithilfe von ECN realisiert werden. Wo ist der Einsatz von ECN sinnvoll? Da die heutigen IP-Netze nach dem Datagramm-Prinzip funktionieren, d.h. die einzelnen IP-Pakete auf einer TCP-Verbindung zwischen zwei Endsystemen in der Regel über verschiedene Netzwege zwischen ihnen übertragen werden, stellt sich nun die Frage: Wo können die Überlastsituationen in IP-Netzen entstehen? Bild soll die Antwort auf diese Frage geben. Die Überlastsituationen entstehen vor allem dort, wo zwei große Netze über eine Standleitung bzw. ein Transitnetz, in dem die Bandbreite in Leitungen nicht ausreicht, miteinander verbunden sind. Also entstehen Überlastsituationen in IP-Netzen in der Regel dort, wo gewisse Engpässe bereits existieren. Bild : Beispiele für Engpässe in IP-Netzen; als Engpass gilt: a) physikalische Standleitung, b) VPN als virtuelle Verbindung R: Router VPN: Virtual Private Network Wie in Bild ersichtlich ist, kann ECN zwischen einem Client und einem Server dazu benutzt werden, die Rate der ins Netz zu sendenden IP-Pakete beim Server zu reduzieren, falls die Übermittlungsstrecke zwischen den beiden Routern überlastet sein sollte. 5

6 In diesem Fall müssen die Router in der Lage sein, eine Überlastsituation zu erkennen und sie mithilfe von ECN dem Server oder dem Client zu melden. Dies erfordert bestimmte ECN-Angaben in IP- Paketen. Daher wurden zwei kleine Erweiterungen sowohl im IP- Header als auch im TCP-Header für die Eintragung von ECN- Angaben vorgenommen, um u.a. Überlastsituationen zu signalisieren. Grundlegende Idee der Überlastvermeidung mit ECN Das allgemeine Prinzip der Überlastkontrolle mithilfe von ECN während einer bestehenden TCP-Verbindung illustriert Bild Hier wurde angenommen, dass die TCP-Verbindung über einen Router verläuft, der überlastet ist. Bild : Idee der Überlastvermeidung mit ECN In Bild sind folgende Schritte zu unterscheiden: 1. Rechner A hat ein IP-Paket abgeschickt. Im IP-Header dieses Pakets wird signalisiert Angabe a, dass beide Kommunikationspartner also die beiden Rechner A und B die Überlastkontrolle nach ECN unterstützen, d.h. beide sind ECN-fähig. 2. Das IP-Paket hat der Router empfangen, der zurzeit überlastet ist, und will nun diesen Zustand den Rechnern A und B anzeigen. Dazu macht er eine entsprechende Eintragung im IP-Header. Genauer gesagt, er markiert Angabe b dieses IP-Paket als CE-Paket (Congestion Experienced), 6

7 um damit seinen Überlastzustand den Rechnern A und B anzuzeigen. 3. Rechner B hat nun das IP-Paket empfangen. Um die in diesem IP-Paket empfangenen Daten zu bestätigen, sendet er ein entsprechendes IP-Paket an Rechner A, in dem er ihm signalisiert, dass das Netz überlastet ist. Dazu macht er die Angabe c im TCP-Header. Dieses IP-Paket kann muss aber nicht über den überlasteten Router übertragen werden. Anmerkung: Beim Aufbau einer TCP-Verbindung vereinbaren die beiden Rechner den Parameter Window (W). Der Wert von Window gibt dem Quellrechner an, wie viel an Daten er senden darf, ohne auf eine Quittung vom Zielrechner warten zu müssen. Daher bestimmt Window die maximale Menge von in eine Richtung übertragenen Daten auf einer TCP-Verbindung, die sich zu einem Zeitpunkt im Netz befinden dürfen. 4. Nach dem Empfang des Pakets mit der Anzeige, dass das Netz überlastet ist, halbiert Rechner A die Window-Größe und signalisiert dies dem Zielrechner B im nächsten an ihn geschickten IP-Paket. Dafür macht er die Angabe d im TCP-Header. Hat Rechner B das Paket empfangen, haben sich die beiden Rechner darauf verständigt, dass die Window-Größe auf der zwischen ihnen bestehenden TCP- Verbindung reduziert wurde. Rechner A muss daraufhin seinen ins Netz gesendeten Datenstrom bewusst drosseln, z.b. nach dem im RFC 5681 spezifizierten Verfahren Slow start and congestion avoidance algorithm. Dies führt dazu, dass die Datenrate des Rechners A sofort sinkt und der Router die Möglichkeit hat, die Belastung seines Puffers zu reduzieren. Empfängt der Rechner über eine bestimmte Zeitdauer kein IP-Paket mit der Anzeige Netz überlastet, vergrößert er die Window-Größe wieder auf den alten Wert. In Bild wurden die ECN-Angaben im IP- bzw. TCP-Paket kurz als a, b, c und d bezeichnet. Im Weiteren wird gezeigt, um welche Angaben es sich handelt und wie sie gemacht werden können. 7

8 ECN-Angaben im IP-Header Um den Routern die Möglichkeit zu verschaffen, ihre Überlastung den Endsystemen zu signalisieren, werden bestimmte ECN-Angaben im IP-Header gemacht. Bild illustriert dies. Bild : Platz für die ECN-Angaben im IP-Header CU: DS: DSCP: IHL: TOS: Currently Unused Differentiated Services (DiffServ) Differentiated Services Code Point Internet Header Length Type of Service Das 8-Bit-Feld TOS (Type of Service) im IP-Header wurde bereits im RFC 0791 vorgesehen, um Prioritäten an die IP-Pakete vergeben zu können. Zuerst bestand aber dafür kein Bedarf. Als der Bedarf kam, wurde dieses Feld im RFC 6184 jedoch umdefiniert und enthält nun ein 6-Bit-Feld DSCP (Differentiated Services Code Point) und zwei weitere Bits. Der DSCP-Wert dient dazu, die Priorität des Pakets festzulegen. Die zwei weiteren Bits werden dagegen von ECN genutzt. Man bezeichnet diese 2 Bit auch als ECN-Feld. Wie die Bits x und y im ECN-Feld belegt und interpretiert werden, illustriert Bild Sind die beiden Bits x und y auf 0 gesetzt, so signalisiert dies, dass ECN nicht unterstützt wird. Mit ECT 01 und ECT 10 können zwei Stufen der Netzüberbelastung angezeigt werden. Durch Setzen der beiden Bits x und y auf 1 kann ein Router seine Überlastung den Endsystemen signalisieren. In diesem Fall spricht man vom CE-Paket. Wurde das ECN-Feld von einem 8

9 Router auf 11 gesetzt, so gilt das IP-Paket bereits als CE-Paket und diese Eintragung im ECN-Feld wird von nachfolgenden Routern nicht mehr modifiziert. Bild : Eintragungen im ECN-Feld im IP-Header CE: ECT: Congestion Experienced ECN-Capable Transport ECN-Angaben im TCP-Header Die ECN-Angaben zwischen den Endsystemen also zwischen den kommunizierenden Rechnern, d.h. zwischen den sog. TCP-Peers werden im TCP-Header eingetragen. Die TCP-Peers müssen einander anzeigen können, dass sie ECN-fähig sind. Ein Rechner, der ein IP-Paket empfangen hat, welches ein Router als CE-Paket markiert hat und in dem der Router seine Überlastung signalisiert, muss dies z.b. dem Quellrechner mitteilen, der die IP-Pakete zu ihm sendet. Der sendende Quellrechner muss somit darüber informiert werden, dass ein Router überlastet ist und er muss auch den empfangenden Zielrechner darüber informieren, dass er dessen Warnung d.h. dass ein Router überlastet ist wahrgenommen und seine Senderate bereits verringert hat. Wie Bild zeigt, werden hierfür die zwei sog. Flags ECE (ECN-Echo) und CWR (Congestion Window Reduced) im TCP-Header verwendet. Hier wird auch gezeigt, wo sich diese beiden Flags im TCP-Header befinden. Die Flags ECE und CWR haben folgende Bedeutung: ECE (ECN-Echo) Dieses Flag wird für zwei Zwecke verwendet. Einerseits ermöglicht es, anzuzeigen, dass ein Rechner ECN-fähig ist. Dies geschieht während des Aufbaus einer TCP-Verbindung mit der Überlastkontrolle (vgl. Bild ). Andererseits zeigt es an, 9

10 dass ein TCP-Segment in einem IP-Paket empfangen wurde, welches ein Router als CE-Paket markiert hat. CWR (Congestion Window Reduced) Dieses Flag wird vom sendenden Rechner also dem Quellrechner gesetzt und zeigt an, dass dieser ein TCP-Segment mit gesetztem ECE-Flag im TCP-Header empfangen hat und infolgedessen die Window-Größe und damit die Senderate bereits reduziert hat. Bild : ECN-Angaben im TCP-Header ACK: CF: CWR: DO: ECE: FIN: PSH: RST: SYN: URG: (Positive) Acknowledgement Control Flag Congestion Window Reduced Data Offset ECN-Echo Finish-Bit Push-Bit Reset-Bit Synchronize Urgent Pointer Wenn ein Router das ECN-Feld im IP-Header eines IP-Pakets auf 11 setzt, d.h., wenn er das Paket als CE-Paket markiert und damit signalisiert, dass er überlastet ist, weiß nur der Empfänger dieses CE- Pakets, dass die TCP-Verbindung überlastet ist der Absender des IP-Pakets weiß es jedoch noch nicht. Mit dem Flag ECE signalisiert dies der Empfänger dem ursprünglichen Absender. 10

11 Aufbau einer TCP-Verbindung mit der Überlastkontrolle Um die Überlast während einer TCP-Verbindung zu kontrollieren, müssen die beiden kommunizierenden Rechner sich darauf einigen. Bild illustriert, wie dies geschieht. Wie hier ersichtlich ist, erfolgt der Aufbau der TCP-Verbindung nach dem bekannten Prinzip, also dem 3-Way-Handshake-Verfahren, wie es beim TCP normalerweise der Fall ist. Bild : Aufbau einer TCP-Verbindung mit Überlastkontrolle ACK: CWR: ECE: SYN: (Positive) Acknowledgement Congestion Window Reduced ECN-Echo Synchronize Hier initiiert der Quellrechner A, der ECN-fähig ist, eine TCP- Verbindung zu Rechner B durch das Absenden eines SYN-Pakets, d.h. eines IP-Pakets, in dem das Flag SYN im TCP-Header auf 1 gesetzt wurde. In diesem SYN-Paket werden auch die beiden ECN- Flags d.h. ECE und CWR auf 1 gesetzt. Ein derartiges SYN- Paket wird ECN-setup-SYN-Paket genannt. Durch die Angaben ECE=1 und CWR=1 signalisiert der Quellrechner A dem Zielrechner B, dass er ECN-fähig ist. 11

12 Ist der Zielrechner B ebenso ECN-fähig, signalisiert er dies dem Quellrechner A durch Setzen des Flag ECE auf 1 und quittiert das ECN-setup-SYN-Paket mit dem Paket <SYN, ACK>, also mit dem Paket, in dem im TCP-Header SYN=1 und ACK=1 gesetzt werden. Da in diesem Paket ECE=1 ist, wird es als ECN-setup-SYN-ACK- Paket bezeichnet. Den Empfang des ECN-setup-SYN-ACK-Pakets bestätigt Rechner A mit dem ECN-setup-ACK-Paket, d.h. mit dem Paket, in dem die Flags ACK und ECE im TCP-Header gesetzt sind also ECE=1 und ACK=1. Damit wurde eine TCP-Verbindung zwischen den Rechnern A und B aufgebaut, welche die Möglichkeit bietet, der Überlastung des Netzes entgegenzuwirken. Entdeckung eines ECN-unfähigen Rechners Bisher wurde vorausgesetzt, dass die beiden kommunizierenden Rechner ECN-fähig sind. In der Praxis aber ist das nicht immer der Fall. Daher muss der Rechner, der eine TCP-Verbindung mit der Überlastkontrolle initiiert, erkennen können, ob sein Partnerrechner ECN-unfähig ist. Dazu wird das ECN-setup-SYN-Paket mit ECE=1 und CWR=1 gesendet. Damit sagt der Rechner, welcher die TCP- Verbindung initiiert, dass er ECN-fähig ist. Die beiden Flags ECE und CWR werden aus folgendem Grund auf 1 gesetzt: Die Rechner, die ein TCP-Paket bestätigen, kopiert in der Regel einfach den Inhalt von 6 Bit, die vorher reserviert worden sind und keine Bedeutung hatten, in die ihnen entsprechenden Bits im TCP-Header des TCP-Pakets um, das als Bestätigung von empfangenen Daten bzw. als Antwort dient. Bild illustriert dies. Für die Fortsetzung siehe: Fachkompendium Protokolle und Dienste der Informationstechnologie, WEKA-Verlag, ISBN: und-dienste-der-informationstechnologieonline_10203_10053_10635_-3_10061_10010_