MPTCP. Multipath TCP MPTCP. Autor: Prof. Dr.-Ing. Anatol Badach

Transkript

1 MPTCP Multipath TCP Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN Mobile Endgeräte und tragbare Rechner wie Smartphones, Tablets und Laptops werden zwecks des Zugangs zum Internet immer häufiger mit zwei Interfaces ausgestattet. Insbesondere Smartphones und Tablets haben oft ein Interface für den Zugang über ein WLAN 1 und ein anderes für den Zugang über das Mobilfunknetz UMTS 2 bzw. über das Netz der nächsten Generation LTE 3. Server in Datacentern werden schon seit Langem über zwei Ethernet-Interfaces mit dem restlichen Netzwerk verbunden. Demzufolge sollte die Möglichkeit bestehen, dass alle mit mehreren Interfaces ausgestatteten sowohl mobilen Endgeräte/Rechner als auch stationären Rechner/Server Daten bei Bedarf gleichzeitig de facto parallel über alle ihre Interfaces senden und empfangen können. Um so etwas verwirklichen zu können, ist allerdings ein spezielles Transportprotokoll nötig, nach dem vor allem Rechner mit mehreren Interfaces Daten parallel über mehrere Datenpfade (sog. Paths) gleichzeitig übermitteln können. Das Protokoll Multipath TCP (MPTCP) soll dies, also Multipathing über Internet, ermöglichen. MPTCP beschreibt ein Konzept, nach dem das klassische verbindungsorientierte Transmission Control Protocol (TCP) um die Funktionalität Multipathing, d.h. um die Fähigkeit, Daten über parallele Paths transportieren zu können, erweitert wird. Zwei Rechner können mit MPTCP untereinander eine virtuelle MPTCP-Verbindung (MPTCP Connection) einrichten. Diese wird aus mehreren, über verschiedene Paths verlaufenden, als Subflows bezeichneten TCP- Subverbindungen gebildet. Dabei ist es von großer Bedeutung, dass die Anzahl paralleler Subflows einer Verkehrsbeziehung sich sogar während einer bestehenden MPTCP-Verbindung ändern kann, ein Subflow also dynamisch hinzugefügt oder entfernt werden kann. Durch diese Möglichkeiten lässt sich eine enorme Verbesserung der Effizienz von Kommunikation über das Internet erreichen, insbesondere beim Transport von Daten zwischen Webbrowsern und 1 Wireless Local Area Network 2 Universal Mobile Telecommunications System 3 Long Term Evolution 1

2 -servern, also bei verschiedenen Webanwendungen sowie bei anderen verbindungsorientierten Applikationen wie oder File Transfer. Da einzelne Subflows einer MPTCP-Verbindung jeweils zwischen zwei Sockets, d.h. zwischen Paaren (IP 4 -Adresse, Port), verlaufen, kann auch ein Rechner mit nur einem physikalischen Interface, z.b. mit nur einer Ethernet-Adapterkarte, de facto mit einer MAC 5 - Adresse und folglich auch mit einer IP-Adresse, MPTCP-fähig sein. Ein populärer Webserver mit nur einer IP-Adresse könnte demzufolge MPTCP-fähig sein, denn die einzelnen Subflows können bei einer IP-Adresse durch verschiedene Ports adressiert werden (vgl. Bild b). Falls eine virtuelle MPTCP-Verbindung zu einem Server führt, der mit nur einem z.b. 10GE 6 Interface ausgestattetet ist, aber die beiden Internetprotokolle IPv4 und IPv6 unterstützt, könnte eine MPTCP-Verbindung sogar aus einem Subflow mit IPv4 und einem Subflow mit IPv6 bestehen. Die eben erwähnten Möglichkeiten unterstreichen die große Bedeutung von MPTCP. Das Protokoll MPTCP wurde so konzipiert, dass es für die Anwendungen (u.a. Webbrowser, -Programme), welche das klassische Protokoll TCP nutzen, nicht sichtbar ist. Das bedeutet, sie merken nicht, dass sie, um den Aufbau einer TCP-Verbindung zu initiieren, statt auf das TCP auf MPTCP zugreifen. Die Transportschicht mit MPTCP wirkt bei ihnen, als ob es sich um eine Transportschicht mit TCP handelte. MPTCP ist abwärtskompatibel zu TCP, und zwar im folgenden Sinne: Ein Rechner mit MPTCP ist auch in der Lage, mit jedem anderen Rechner mit nur TCP Daten untereinander zu übermitteln; der Datenaustausch erfolgt in diesem Fall aber nur über eine klassische TCP-Verbindung und MPTCP verhält sich dann wie das normale TCP. MPTCP kann somit als eine Erweiterung von TCP um die Möglichkeit, Daten parallel über mehrere Paths zu transportieren, angesehen werden. 4 Internet Protocol 5 Media Access Control 6 10 Gigabit Ethernet 2

3 An der Entwicklung von MPTCP wird schon seit ca intensiv gearbeitet 7 und alle dies betreffenden Aktivitäten werden von der gleichnamigen Working Group 8 der Internet Engineering Task Force (IETF) koordiniert. Das Konzept und die Einsatzmöglichkeiten von MPTCP sind bereits in mehreren IETF-Dokumenten (Request for Comments, RFC) spezifiziert; dem Konzept von MPTCP widmet sich insbesondere RFC Unter der Adresse findet man ausführliche Informationen über die Implementierung von MPTCP insbesondere für Linux. Daneben existiert auch eine Weltkarte mit MPTCP-fähigen Rechnern unter Dieser Beitrag erläutert das Konzept von MPTCP und zeigt dessen Bedeutung sowie Einsatzmöglichkeiten. Dabei präsentiert er bildhaft, wie verschiedene, aus parallelen Paths bestehende MPTCP- Verbindungen auf- und abgebaut werden, und wie die Übermittlung von Daten über diese Verbindungen erfolgt. Wann ist MPTCP von Bedeutung? Vor der Besprechung der technischen Details von MPTCP soll an dieser Stelle noch eine wichtige Frage kurz beantwortet werden, und zwar die: In welchen Fällen bringt der Einsatz von MPTCP wesentliche Vorteile mit sich? Eine allgemeine Antwort auf diese Frage lautet: MPTCP bringt wesentliche Vorteile in Rechnern bzw. anderen, insbesondere mobilen Endeinrichtungen, die über mehrere Interfaces zur Datenkommunikation verfügen. Somit ist MPTCP von großer Bedeutung in mobilen Endeinrichtungen am Internet sowie in Servern in Datacentern (vgl. Bild und ). MPTCP in mobilen Endeinrichtungen Betrachtet man zuerst das Bild Es soll die Bedeutung von MPTCP in mobilen Endeinrichtungen, in sog. mobilen Clients 9, und in stationären Webservern am Internet zum Ausdruck bringen Das MPTCP wird u.a. in ios7 auf iphone und ipad von Apple eingesetzt, vgl. 3

4 Bild : MPTCP in mobilen Endeinrichtungen und Webservern mehrere Interfaces: a) nur im mobilen Client, b) im mobilen Client und im stationären Webserver 3G/4G: LTE: UMTS: WLAN: dritte/vierte Generation der Mobilfunknetze Long Term Evolution Universal Mobile Telecommunications System Wireless Local Area Network Wie bereits erwähnt, werden mobile Endeinrichtungen (z.b. Smartphones und Tablets) in der Regel mit zwei Interfaces für den Zugang zum Internet ausgestattet: mit einem WLAN-Interface für den Zugang über ein WLAN und mit einem 3G-/4G-Interface für den Zugang über ein Mobilfunknetz der dritten oder der vierten Generation. In solchen mobilen Endeinrichtungen ist MPTCP von beachtlicher Bedeutung. Anmerkung: Als 3G bezeichnet man die dritte Generation von Mobilfunknetzen und dementsprechend als 4G die vierte Generation. Zur 3G gehören die Netzstandards UMTS und HSPA 10. 4G stellt den Netzstandard LTE dar. Die einzelnen, in Bild gezeigten Situationen, in denen die Kommunikation mithilfe von MPTCP über zwei Paths verläuft, lassen sich kurz wie folgt charakterisieren: Fall a: mobiler Client mit zwei Interfaces und stationärer Server mit nur einem Interface Zuerst initiiert der mobile Client über ein WLAN also in der Regel über den kostengünstigeren Internetzugang eine normale TCP- Verbindung zum Server. Dabei zeigt der Client dem Server mittels der TCP-Option MP_CAPABLE an, dass er MPTCP-fähig ist (vgl. Bild und ). Der Server mit nur einem Interface teilt 10 High Speed Packet Access 4

5 dem Client ebenso mit, dass er MPTCP-fähig ist; MPTCP kann also zum Einsatz kommen. Die erste TCP-Verbindung über das WLAN wird als Subflow angesehen, d.h. als die TCP-Subverbindung einer MPTCP-Verbindung. Danach wird die zweite, vom Client initiierte und über das Mobilfunknetz (3G/4G) verlaufende TCP-Verbindung zum Server aufgebaut. Diese TCP-Verbindung stellt den zweiten Subflow dar. Die beiden Subflows werden nun entsprechend gebündelt und es entsteht auf diese Weise eine MPTCP-Verbindung zwischen Client und Server (vgl. Bild b). Hierbei kommen die zwei folgenden Möglichkeiten infrage: Load Balancing (paralleler Datentransport) Die transportierten Daten werden entsprechend auf beide Subflows verteilt; dies führt zur Erhöhung der Transportkapazität von Daten. Backup-Subflow Die Daten werden nur über ein WLAN transportiert und der über ein Mobilfunknetz G3/G4 verlaufende Subflow dient nur als Backup des anderen Subflow. Eine solche Lösung führt zur Reduzierung der für den Transport von Daten über ein Mobilfunknetz anfallenden Datentransportgebühren. Hat der Client den vom WLAN versorgten Bereich verlassen, geht die über WLAN verlaufende TCP-Verbindung verloren und die MPTCP-Verbindung reduziert sich de facto zu einer TCP- Verbindung. Daraus folgt: MPTCP trägt dazu bei, während der Mobilität eine effiziente, unterbrechungsfreie Datenkommunikation mit dem TCP zu garantieren. Fall b: mobiler Client und stationärer Server verfügen über zwei Interfaces In diesem Fall kann zwischen Client und Server eine aus zwei Subflows bestehende MPTCP-Verbindung aufgebaut werden, und zwar auf die gleiche Weise wie im Fall a (Bild a). Es sei aber angemerkt, dass der Client, bevor er eine TCP- Verbindung zum Server initiiert, in der Regel nur seinen Hostnamen kennt und aufgrund dessen beim Domain Name System (DNS) des IP-Netzes nur seine IP-Adresse abfragen kann und nicht die Anzahl der Internet-Interfaces. Beim Initiieren einer TCP-Verbindung weiß der Client also noch nicht, ob der Server über mehrere Interfaces verfügt. Der Server kann aber, so sieht MPTCP es vor, dem Client in 5

6 der TCP-Option ADD_ADDR mitteilen, dass er noch über eine weitere IP-Adresse und demzufolge auch über ein weiteres Interface verfügt. Dies kann sogar schon während des Aufbaus des ersten Subflow passieren (Bild ). Einsatz von MPTCP in Datacentern In der Regel werden Server in Datacentern über zwei Ethernet- Interfaces an sog. Access Switches angeschlossen für Näheres darüber s. Kap. 4 in [2]. Wie Bild illustriert, kann zwischen zwei Servern jeweils eine aus zumindest zwei Subflows bestehende MPTCP-Verbindung aufgebaut werden. Auf diese Weise lässt sich Multipathing in Datacentern verwirklichen, ohne komplexe Lösungen auf der Basis von TRILL oder SPB realisieren zu müssen. 11 Eine solche relativ einfache Multipathing-Lösung ist von Bedeutung, wenn einer dieser beiden Server dem anderen als Backup dienen soll. Bild : Einsatz von MPTCP in Datacentern AS: GS: Access Switch Aggregation Switch Aus Bild geht insbesondere hervor, dass man dank des Einsatzes von MPTCP in Servern innerhalb von Datacentern eine gleichmäßige Lastverteilung im Aggregation Layer erreichen kann. 11 Die Konzepte TRILL (Transparent Interconnection of Lots of Links) und SPB (Shortest Path Bridging) wurden u.a. mit dem Ziel entwickelt, Multipathing in Datacentern realisieren zu können. [9] 6

7 Subflow Policies Nachdem die Bedeutung von MPTCP in mobilen Endeinrichtungen und in Servern erläutert wurde (vgl. Bild und ), soll erörtert werden, welchen Zwecken eine aus mehreren Subflows bestehende MPTCP-Verbindung dienen soll bzw. wie man mehrere Subflows einer MPTCP-Verbindung nutzen könnte. In diesem Zusammenhang spricht man von Subflow Policies also von Subflow- Nutzungsstrategien. Beim Aufbau einer MPTCP-Verbindung kommen insbesondere folgende Nutzungsstrategien von Subflows in Betracht: Erhöhung des Durchsatzes (der Transportkapazität) In diesem Fall wird die zu transportierende Last entsprechend auf mehrere Subflows verteilt, d.h. Load Balancing wird realisiert. Diese Nutzungsstrategie ist für Datacenter von großer Bedeutung (Bild ). Erhöhung der Verfügbarkeit einer Verbindung Diese Strategie wird vor allem in mobilen Endeinrichtungen mit den zwei Interfaces WLAN und 3G/4G verfolgt (vgl. Bild ). Dies geschieht auf folgende Weise: Eine mobile Endeinrichtung baut zuerst den ersten Subflow zum Zielrechner über ein WLAN auf und dann einen zweiten Subflow über ein Mobilfunknetz (3G/4G). Der zweite Subflow dient aber nur als Backup für den ersten, über das WLAN verlaufenden Subflow. Diese Nutzungsform von Subflows wird zwischen den kommunizierenden Rechnern vereinbart. 12 Hat die mobile Endeinrichtung aber das WLAN verlassen, ist der erste Subflow nicht mehr verfügbar und erst dann kommt der zweite Subflow zum Einsatz. Demzufolge reduziert sich die MPTCP-Verbindung zur normalen TCP-Verbindung; aber die mobile Endeinrichtung hat weiterhin Internetzugang. Dank dieser Lösung können mobile Endeinrichtungen mit den zwei Interfaces WLAN und 3G/4G flächendeckend Internetzugang haben und dabei auch die Möglichkeit, ein WLAN zu nutzen, um die anfallenden Gebühren für den Datentransport zu senken. 12 Hierzu dient das Flag-Bit B in der TCP-Option MP-JOIN (Bild b). 7

8 Minderung der Überlast Diese Strategie kann insbesondere in Rechnern mit zwei Interfaces praktiziert werden. Normalerweise werden Daten nur über den ersten Subflow (also über den ersten Path) transportiert. Sollte der erste Subflow aber überlastet sein, dann wird der zweite Subflow zugeschaltet, um den ersten zu entlasten. Findet eine Überlastkontrolle nach der in RFC 3168 spezifizierten Explicit Congestion Notification (ECN) statt, dann ist diese Strategie einfach realisierbar. Das logische Modell der Rechnerkommunikation mit TCP Um ein logisches Modell der Rechnerkommunikation beim Einsatz von MPTCP anschaulich vermitteln zu können, soll zuerst die allgemeine logische Struktur eines Rechners erläutert und dabei das logische Modell der Rechnerkommunikation mit TCP darstellt werden. Als Einstieg sei ein Blick auf die in Bild gezeigte stark vereinfachte logische Struktur eines Rechners mit IPv4 am Internet empfohlen; ein ähnliches Modell gilt auch für IPv6. Im Folgenden wird auf das hier dargestellte Modell zurückgegriffen, um das Konzept von MPTCP bildhaft zu erklären. Bild : Logisches Modell der Rechnerkommunikation mit TCP beim Einsatz von IPv4 (Modell gilt auch für IPv6) ET: IP: MAC: EtherType (Angabe des Protokolls der Netzwerkschicht) Internet Protocol Media Access Control 8

9 MAC-T: MAC Trailer NIC: Network Interface Card/Controller R: Router TCP: Transmission Control Protocol TP-Nr: Transportprotokollnummer (Angabe Protocol im IP-Header) Im Internet werden zwischen IP-Adressen bekanntlich IP-Pakete übermittelt und man kann diesen Internet Service folglich als IP- Paketübermittlungsdienst ansehen. Jeder Rechner nimmt an diesem Dienst teil und enthält dafür eine Netzwerkadapterkarte und eine IP- Protokollinstanz. Der IP-Adresse eines Rechners kann an der Grenze zwischen der Netzwerkschicht (Network Layer) mit IP und der Transportschicht (Transport Layer) mit verschiedenen Transportprotokollen ein Speicherplatz also eine Art Kommunikationspuffer zugeordnet werden. Über diesen sind die Instanzen verschiedener Transportprotokolle mit der IP-Instanz logisch verbunden; Bild zeigt nur die TCP-Instanz. Eine IP-Adresse könnte also als virtuelle Steckdose mit mehreren Pins oberhalb der IP-Instanz, d.h. als virtuelle Steckdose am IP-Paketübermittlungsdienst, dargestellt werden. Ein Pin in dieser Steckdose repräsentiert die Angabe Protocol im IP- Header genauer gesagt die Nummer des Transportprotokolls; die Nummer von TCP ist 6. Über eine IP-Adresse als virtuelle Steckdose im Rechner können die Instanzen verschiedener Transportprotokolle an die IP-Instanz angebunden werden. Ein Rechner hat eine Netzwerkadapterkarte (NIC), über die er an das Netzwerk angeschlossen ist, und eine physikalische Adresse, die den Anschlusspunkt des Rechners am Netzwerk angibt. So enthält z.b. ein Rechner am LAN 13 eine LAN-Adapterkarte und diese besitzt eine physikalische Adresse, die sog. MAC-Adresse. Mit ihrer Hilfe wird der Rechner im Netzwerk innerhalb eines IP-Subnetzes eindeutig identifiziert. Die MAC-Adresse kann man auch als virtuelle Steckdose mit mehreren Pins oberhalb der Adapterkarte darstellen. Ein Pin in dieser Steckdose repräsentiert die im Header EtherType angegebe- 13 Local Area Network 9

10 ne Nummer des Protokolls der Netzwerkschicht, z.b. 0x0800 von IPv4 oder 0x86DD von IPv6. Logisch betrachtet können die Instanzen mehrerer Protokolle der Netzwerkschicht (z.b. IPv4, IPv6,...) über eine MAC-Adresse als virtuelle Steckdose an die Adapterkarte angebunden werden. Struktur der Transportschicht mit MPTCP Aus dem in Bild gezeigten logischen Modell der Rechnerkommunikation beim TCP-Einsatz soll jetzt ein vereinfachtes Modell der Rechnerkommunikation beim Einsatz von MPTCP abgeleitet und hierbei insbesondere die Struktur der Transportschicht MPTCP näher erläutert werden. Bild zeigt ein solches vereinfachtes Modell, in dem die Komponenten der beiden Rechner, mit denen der IP-Paketübermittlungsdienst in diesen erbracht wird, aber nicht gezeigt werden. Bild : Vereinfachtes Modell der Rechnerkommunikation mit MPTCP: a) Struktur der Transportschicht mit MPTCP, b) TCP- Verbindung aus der Sicht von Applikationen, c) MPTCP- Verbindung bilden zwei Subflows IP: IP-I: MPM: Internet Protocol IP-Instanz Multipath Management 10

11 MSP: SSP: TCP: Master Subport Slave Subport Transmission Control Protocol Logisch betrachtet wird die Transportschicht in Rechnern mit MPTCP auf zwei Teilschichten aufgeteilt, nämlich: auf eine Teilschicht Multipath Management (MPM), zu der die MPTCP- Instanzen gehören, und auf eine Teilschicht mit TCP-Instanzen, welche der herkömmlichen Transportschicht mit TCP entspricht. 14 An dieser Stelle ist ein Hinweis angebracht: MPTCP wurde so konzipiert, dass zwei kommunizierende Applikationen die Transportschicht als eine normale, klassische Transportschicht sehen und folglich glauben, zwischen ihnen verlaufe eine normale TCP- Verbindung. Dies ist dank der oberen Teilschicht MPM mit MPTCP-Instanzen möglich. Mithilfe von Bild soll nun die grundlegende Idee von MPTCP vorgestellt werden. Die beiden, hier gezeigten Rechner verfügen jeweils über zwei Interfaces und sind MPTCP-fähig. Somit kann zwischen diesen Rechnern eine über zwei Paths verlaufende MPTCP-Verbindung aufgebaut werden. Für diesen Fall wird angenommen, dass eine Applikation im Quellrechner A eine TCP- Verbindung zur gleichen Applikation im Zielrechner B initiiert und dass die erste TCP-Verbindung über den Path zwischen den IP- Adressen x 1 und y 1 in diesen Rechnern verläuft. Diese TCP- Verbindung wird dann als TCP-Subverbindung der MPTCP- Verbindung und als Subflow 1 angesehen. Danach wird die zweite TCP-Verbindung aufgebaut und diese stellt den Subflow 2 dar. Bild soll die Aufgabe der Teilschicht MPM näher veranschaulichen und bringt zum Ausdruck, dass die kommunizierenden Applikationen die zwischen ihnen bestehende, zwei Subflows (als TCP-Subverbindungen) enthaltende MPTCP-Verbindung als eine normale TCP-Verbindung zwischen Socket (x 1, i) im Rechner A und Socket (y 1, m) im Rechner B erleben (vgl. hierzu Bild b und a). vgl mptcp.pdf 11

12 Es sei hervorgehoben, dass man in diesem Zusammenhang von Socket, Master SubSocket und Slave SubSocket spricht 15 (vgl. Bild a und b). Diese Bezeichnungen basieren auf Folgendem: Normalerweise adressiert ein Socket einen Endpunkt einer Kommunikationsbeziehung, u.a. einer TCP-Verbindung. Dementsprechend adressiert ein SubSocket einen Endpunkt einer TCP- Subverbindung. Da bei MPTCP eine TCP-Subverbindung einen Subflow darstellt, repräsentiert ein SubSocket folglich einen Endpunkt eines Subflow; jeder Subflow verläuft also zwischen zwei SubSockets. Bei näherer Betrachtung der in Bild gezeigten MPTCP- Verbindung findet man zwei Subflows: Subflow 1 zwischen Master SubSockets (x 1, i) und (y 1, m), Subflow 2 zwischen Slave SubSockets (x 2, j) und (y 2, n). Die Subflows können fast als normale TCP-Verbindungen angesehen werden, und zwar aus folgendem Grund: Die zuerst aufgebaute TCP-Verbindung, also die zwischen den Sockets (x 1, i) und (y 1, m), stellt die erste TCP-Subverbindung des MPTCP dar, d.h. den Subflow 1. Die SubSockets des zuerst aufgebauten Subflow also des Subflow 1 nennt man Master SubSockets und als Slave SubSockets bezeichnet man die Endpunkte von weiteren, später aufgebauten Subflows. Zu Bild sei angemerkt, dass man die Ports in SubSockets Subports nennt und dementsprechend weiter: Master Subports in Master SubSockets und Slave Subports in Slave SubSockets. Die Aufgabe der Teilschicht MPM kurz zusammengefasst Anhand von Bild lässt sich die Aufgabe der Teilschicht MPM kurz wie folgt zusammenfassen: Eine Applikation im Quellrechner A initiiert, ohne zu wissen, dass MPTCP zum Einsatz kommt, eine TCP-Verbindung zu einer Applikation im Zielrechner 15 Die Begriffe Master SubSocket und Slave SubSocket wurden dem Beitrag Multipath TCP: From Theory to Practice entnommen, dieser ist abrufbar unter: 12

13 B. Für die initiierte TCP-Verbindung wird der Port i im Rechner A quasi oberhalb Schicht MPM bereitgestellt; dieser Port wird als Master Port bezeichnet. Danach verläuft die TCP-Verbindung im Rechner A über die IP-Instanz 1 mit der IP-Adresse x 1 und Interface 1. Demzufolge stellt der Socket (IP-Adresse x 1, Port i) den Anfang der im Rechner A initiierten TCP-Verbindung dar. Vom Quellrechner A wird nun an den Zielrechner B ein TCP-Paket <SYN> gesendet. In diesem TCP-Paket verweist der Quellrechner mit der Option MP_CAPABLE darauf, dass er MPTCP-fähig ist (vgl. Bild ). Für die ankommende TCP-Verbindung wird im Rechner B der Port m quasi oberhalb Schicht MPM bereitgestellt und ebenso als Master Port bezeichnet. Der Zielrechner B antwortet dem Quellrechner A mit dem TCP-Paket <SYN, ACK> und verweist mit der Option MP_CAPABLE darauf, dass auch er MPTCP-fähig ist. Auf diese Weise haben sich die verbundenen Rechner darüber verständigt, dass sie beide MPTCP-fähig sind. Nachdem die beiden Rechner den Aufbau der ersten TCP- Verbindung abgeschlossen haben und sich während des Aufbaus darüber verständigt haben, dass sie MPTCP-fähig sind, betrachten sie diese TCP-Verbindung als Subflow 1. Wie Bild a zeigt, enthalten die TCP-Instanzen in beiden Rechnern des Subflow 1 de facto Kopien des Master Port. Nachdem der Subflow 1 eingerichtet wurde, wird die zweite TCP-Verbindung aufgebaut und als Subflow 2 angenommen. Multipath-Kommunikation mit MPTCP aus logischer Sicht Nachdem die in Bild gezeigte Struktur der Transportschicht mit MPTCP bekannt ist, soll jetzt ein allgemeines Modell der Kommunikation mit MPTCP verdeutlichen, dass die kommunizierenden Applikationen letztlich eine TCP-Verbindung sehen, und nicht, dass ihnen eine aus zwei Subflows bestehende MPTCP-Verbindung bereitgestellt wird. Bild soll dies zum Ausdruck bringen und zudem beweisen, dass auch ein Rechner mit nur einem Interface MPTCP-fähig sein kann. Anmerkung: In Bild kann man die in Bild gezeigte Architektur der Rechnerkommunikation mit TCP erkennen und zwar in Form der folgenden Reihenfolge von Instanzen: 13

14 (Applikation, TCP, IP, NIC) <=Path=> (NIC, IP, TCP, Applikation) Bild : Multipath-Kommunikation mit MPTCP: a) beide Rechner mit zwei Interfaces sowie ein Rechner mit einem Interface und TCP über: b) IPv4 oder IPv6, c) IPv4 und IPv6 IP: MAC: MPM: MSP: NIC: SSP: Internet Protocol Media Access Control Multipath Management Master Subport Network Interface Card/Controller Slave Subport Die in Bild dargestellten drei Fälle a, b und c lassen sich wie folgt charakterisieren (vgl. Bild und ): Fall a: beide Rechner verfügen über zwei Interfaces Hier ist direkt ersichtlich, dass eine MPTCP-Verbindung ein Bündel von TCP-Subverbindungen (Subflows) darstellt. Es sei hervorgehoben, dass der blau markierte Port oberhalb der MPTCP- Instanz, den die Applikationen sehen, und der Master Subport 14

15 (MSP) im Subflow 1 die gleiche Nummer haben. 16 Deswegen wurden diese beiden Ports in der gleichen Farbe (blau) dargestellt. Fall b: ein Rechner mit nur einem Interface und TCP über IPv4 oder IPv6 Auch ein Rechner mit nur einem Interface demzufolge mit nur einer IP-Adresse und einer TCP-Instanz (vgl. Bild ) kann MPTCP-fähig sein. Hier kann man entweder das Internetprotokoll IPv4 oder IPv6 verwenden. Schaut man sich Bild genauer an, so stellt man fest, dass man die Kommunikationspuffer sendqueue und ofo-queue einzelner Subflows auch oberhalb einer TCP-Instanz entsprechend im Master Subport und Slave Subport unterbringen kann. Die beiden Subflows nutzen hier die Ressourcen (NIC, IP-Instanz und TCP-Instanz) im Rechner B gemeinsam. Fall c: ein Rechner mit nur einem Interface und TCP über IPv4 und IPv6 Auch ein Rechner mit nur einem Interface und mit den beiden Internetprotokollen IPv4 und IPv6 kann MPTCP-fähig sein. Ein Subflow kann das IPv4 und der andere das IPv6 nutzen. Theoretisch betrachtet können die beiden Protokolle IPv4 und IPv6 in einer MPTCP- Verbindung somit gleichzeitig zum Einsatz kommen. Das logische Modell der Rechnerkommunikation mit MPTCP Aus den bisherigen Ausführungen geht hervor, dass die grundlegende Idee von MPTCP in einer Bündelung mehrerer TCP- Verbindungen besteht; sie werden TCP-Subverbindungen bzw. Subflows genannt. Diese Idee führt, wie soeben auch in Bild und gezeigt wurde, zu einer aus zwei Unterschichten (Layers) bestehenden Struktur der Transportschicht (Transport Layer): Die erste Unterschicht bildet de facto TCP und die zweite realisiert MPTCP in der Tat die Funktion Multipath Management. Da TCP ein byte-orientiertes Protokoll ist, d.h. die übertragenen Daten werden bei TCP quasi byteweise nummeriert, muss der Fluss von Daten auf den beiden Unterschichten der Transportschicht 16 Der Grund dafür ist: Die zuerst aufgebaute, also erste TCP-Verbindung wird als TCP-Subverbindung 1 angesehen und Subflow 1 genannt. 15

16 kontrolliert werden. Dementsprechend ist bei MPTCP eine zweistufige Datenflusskontrolle vonnöten. Um diese erläutern zu können, wird ein geeignetes Modell der Rechnerkommunikation mit MPTCP benötigt. Bild zeigt ein solches Modell, das weitgehend aus den Bildern , und abgeleitet wurde. Bild : Modell der Rechnerkommunikation mit MPTCP im Hinblick auf die Datenflusskontrolle API: Application Programming Interface MPM: Multipath Management (MPTCP Layer) NIC: Network Interface Card/Controller ofo: out-of-order: Eine ofo-receive-queue repräsentiert einen Kommunikationspuffer, in dem Daten in einer noch unkorrekten Reihenfolge vorliegen können. SN: Sequence Number TPNr: Transportprotokollnummer (TCP-Nummer = 6) Das in Bild gezeigte Modell soll dazu dienen, die allgemeine Idee der zweistufigen Datenflusskontrolle bei MPTCP zu erläutern. Man stelle sich vor: Zwischen zwei Rechnern wurde eine aus zwei Subflows bestehende MPTCP-Verbindung aufgebaut. Ein Strom von Bytes wird jetzt über diese Verbindung übermittelt und dabei im Quellrechner, wie Bild illustriert, auf zwei Subströme von Datenblöcken mit der Länge von z.b. 500 Byte aufge- 16

17 teilt. Diese Datenblöcke werden auf ihrer lange Reise über zwei Paths so verschickt, dass sie abwechselnd auf beide Subflows (SFs) verteilt werden, also: der erste Datenblock auf SF1, der zweite auf SF2, der dritte auf SF1, der vierte auf SF2 usw. Bild : Illustration des Datentransports mit MPTCP Falls die Übermittlungszeit der Datenblöcke als End-to-End Delay bezeichnet auf einem Path viel größer als auf einem anderen ist, kann dies, wie Bild zum Ausdruck bringt, dazu führen, dass die Datenblöcke den Zielrechner nicht in der Reihenfolge erreichen, in der sie am Quellrechner abgeschickt wurden. Um eine solche Situation in den Griff zu bekommen, müssen die Datenblöcke, deren Reihenfolge eventuell unkorrekt ist, zuerst in einem Zwischenempfangspuffer abgespeichert, dann in der korrekten Reihenfolge in einen Endempfangspuffer verlegt, und erst dann von dort aus an eine Applikation übergeben werden. Damit man jede eventuell unkorrekte Reihenfolge der im Zielrechner empfangenen Datenblöcke korrigieren kann, sind auf dem Layer MPM zwei Empfangspuffer nötig (vgl. Bild ), nämlich ein Zwischenempfangspuffer mit der Warteschlange ofo-receivequeue von Datenblöcken in einer eventuell unkorrekten Reihenfolge und ein Endempfangspuffer mit der Warteschlange end-receivequeue von Datenblöcken in einer korrekten Reihenfolge. Bevor man 17

18 aber die Daten an eine Applikation übergibt, werden sie von der Warteschlange ofo-receive-queue in die end-receive-queue umgeschrieben (vgl. Bild und ). Zweistufige Datenflusskontrolle bei MPTCP Bei MPTCP werden genauso wie bei TCP Daten zwischen Applikationen in zwei kommunizierenden Rechnern als eine Folge von Bytes so übermittelt, dass sie zuerst zu Datenblöcken einer bestimmten Größe zusammengefasst und aus den Datenblöcken dann TCP- Dateneinheiten gebildet werden. Anschließend werden die Dateneinheiten in IP-Paketen eingekapselt auf ihre Reise über mehrere Paths einer MPTCP-Verbindung zum Ziel verschickt. Da die Datenblöcke in IP-Paketen über mehrere Paths und sogar auf einem Path über verschiedene Wege zum Ziel laufen können, muss bei MPTCP eine spezielle zweistufige Datenflusskontrolle realisiert werden. Diese ist teilweise aus Bild ersichtlich; Bild illustriert sie detaillierter. Bild : Illustration der Bedeutung von DSN und SSN DSN: Data Sequence Number (globale Datenfolgenummer) SF: Subflow SSNi: Subflow Sequence Number auf dem Subflow i (i = 1, 2) Da jeder Subflow de facto eine normale TCP-Verbindung darstellt, entspricht die SSN auf einem Subflow vollkommen der Se- 18

19 quence Number (SN) auf einer TCP-Verbindung. Demzufolge wird, wie Bild illustriert, die SSN anstelle der SN im TCP-Header eingetragen und gibt an, mit welcher Nummer die im betreffenden TCP-Paket übertragenen Datenbytes beginnen. Wie in Bild zum Ausdruck gebracht wurde, muss, um die Reihenfolge von Datenblöcken am Ziel in die richtige Reihenfolge zu bringen, die DSN als globale Nummer von Datenbytes auch in jedem TCP-Paket enthalten sein. Die Angabe DSN wird in der TCP- Option Data Sequence Signal (DSS) übermittelt (vgl. Bild ). Für die Fortsetzung siehe: Dreibändiges Loseblattwerk (Print und CD-Version) mit Update-Dienst: "Protokolle und Dienste der Informationstechnologie" Aktualisierungszyklus: 2 Monate WEKA Media, Kissing ISBN-13: , Bestell-Nr. OL9142J 19