M ► MP

MP Multilink Point-to-Point Protocol Autor: Prof. Dr.-Ing. Anatol Badach

Auszug aus dem Werk:

Mit dem Ziel, Daten in Rechnernetzen über Punkt-zu-Punkt-Verbindungen (P2P-Verbindungen), engl. Point-to-Point Connections (P2P Connections), übermitteln zu können, wurde das Point-to-Point Protocol (PPP) entwickelt und in zahlreichen Standards der Internet Engineering Task Force (IETF), in sog. RFCs1, spezifiziert. Das Multilink Point-to-Point Protocol (MP) stellt eine Erweiterung des PPP dar und ermöglicht die Verwendung mehrerer paralleler Übertragungskanäle zur Übermittlung von Daten zwischen zwei festlegten Punkten. Das MP ist also ein Protokoll zur parallelen Übermittlung von Daten in Frames des Protokolls PPP zwischen zwei festgelegten Endpunkten (vgl. Bild 004764). Es sei hervorgehoben, dass für das „Multilink Point-to-Point Protocol“ mehrere Akronyme verwendet werden – wie MP, MLPPP, MLP oder MultiPPP. Die Akronyme MP und MLPPP kommen allerdings am häufigsten vor, wobei in den RFCs der IETF die Bezeichnung „PPP Multilink Protocol“ mit dem Akronym MP und MLPPP in den Produktbeschreibungen diverser Hersteller zu finden sind. Im Weiteren wird das Akronym MP verwendet.

Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3-82769142-2

Da in heutigen Rechnernetzen, also de facto im Internet und in Intranets, alle Informationsarten – also Daten, Audio/Sprache und Video – nach dem Internet Protocol (IP) in Form von sog. IPPaketen übermittelt werden, bezeichnet man diese Rechnernetze als IP-Netze. In ihnen kann das MP zur Übermittlung von IP-Paketen zwischen zwei Netzkomponenten über parallele Übertragungskanäle – im Allgemeinen als Data Links oder kurz Links bezeichnet – eingesetzt werden. Dies könnte man sich so vorstellen, als ob mithilfe des MP mehrere Data Links zu einem „dickeren“ Data Link mit einer größeren Übertragungskapazität (Bandbreite) gebündelt würden. Logisch betrachtet ermöglicht das MP die Bündelung (Bundling) von Data Links und somit die Bereitstellung von Bandbreite nach Bedarf (Bandwidth on Demand, BoD).

1

Requests for Comments, http://www.rfc-editor.org

1

M ► MP

Anmerkung: Als Data Link wird in diesem Kontext ein Übertragungskanal zur Übermittlung von Daten in Form von Frames verstanden, welcher sowohl physikalisch – z.B. über elektrische Leitungen, Glasfasern oder durch Funkübertragungen – als auch virtuell – z.B. in ATM2- oder MPLS3-Systemen – realisiert sein kann.

Das PPP wird oft in lokalen Netzwerken – nach dem Konzept des PPP over Ethernet (PPPoE)4 – zur Bereitstellung von P2PVerbindungen auf Basis von Gigabit Ethernets (GE) mit Bitraten von 1 und 10 GBit/s verwendet. Hierbei kann das MP zur Bündelung von GE-Leitungen eingesetzt werden. Auf diese Weise lassen sich beispielsweise in Datacentern gebündelte GE-Leitungen mit Bitraten von n × 1 oder n × 10 GBit/s – als skalierbares Gigabit Ethernet (Scalable Gigabit Ethernet) – einrichten. Systemlösungen solcher Art werden oft als MLPPP over PPPoE bezeichnet. Das Konzept des MP wurde erstmals im November 1994 seitens der IETF im RFC 1717 unter dem Titel „The PPP Multilink Protocol (MP)“ veröffentlicht. Das breite Spektrum von PPP-Anwendungen hat aber dazu geführt, dass das ursprüngliche Konzept des MP verbessert und erweitert wurde. Deshalb wurde RFC 1717 im August 1996 durch RFC 1990 ersetzt. Diese Spezifikation des MP ist noch heute verbindlich. Idee des MP Bild 004764 illustriert die Idee des MP.5 Wie hier ersichtlich ist, wird das MP zur Übermittlung eines Datenstroms in Form von Datenpaketen – beispielsweise von Paketen des IP oder anderer Protokolle der Netzwerkschicht – auf einer P2P-Verbindung über mehrere, parallele Data Links verwendet. Mit dem MP werden praktisch mehrere Data Links gebündelt (aggregiert). Man spricht hierbei von Link-Bündelung, engl. Link Bundling, Link Aggregation oder Link Trunking.

2 3 4

Asynchronous Transfer Mode Multiprotocol Label Switching RFC 2516

5

Bild 004764 zeigt die Datenübermittlung in nur eine Richtung. Die Datenübermittlung in Gegenrichtung verläuft nach dem gleichen Prinzip.

2

M ► MP

Bild 004764: Idee des MP: die Bündelung von Data Links Beim Einsatz des MP sind immer zwei sog. MP-Instanzen als Endpunkte einer P2P-Verbindung beteiligt. Zwischen ihnen wird eine aus mehreren Data Links bestehende Verbindung für die Übermittlung von Datenpaketen der Protokolle aus der Netzwerkschicht (d.h. aus dem Layer 3) aufgebaut. Weil diese P2P-Verbindung mehrere Data Links enthält, wird sie oft als Multilink-Bündel (Multilink Bundle) bezeichnet. Falls die Länge eines zu übermittelnden Datenpaketes den beim Verbindungsaufbau festgelegten Wert des Parameters Maximum Receive Unit (MRU) überschreitet, wird dieses Paket vor seiner Übermittlung auf der Sendeseite zuerst in mehrere Datenfragmente6 aufgeteilt. Diese werden dann um bestimmte Kontrollparameter des MP ergänzt. Auf diese Weise entstehen kleinere, autarke Datenpakete, die sog. MP-Pakete (vgl. Bild 004768). Sie werden in PPPFrames eingekapselt und beim Senden auf einzelne Data Links verteilt. Auf der Empfangsseite werden die MP-Pakete zuerst aus den PPP-Frames herausgenommen, zwischengespeichert und anschließend wird aus den in den MP-Paketen enthaltenen Datenfragmenten das ursprüngliche Datenpaket zurückgewonnen. MP-Pakete in PPP-Frames Das MP legt die Struktur von Dateneinheiten (MP-Paketen) fest, in denen Fragmente von Paketen eines Netzwerkprotokolls (d.h. Layer3-Datenfragmente) als Nutzlast (Payload) übermittelt werden kön-

6

Ein Datenfragment kann ein vollständiges IP-Paket oder nur einen Teil davon umfassen.

3

M ► MP

nen. Bild 004765 zeigt, wie MP-Pakete aufgebaut sind und wie sie zur Übermittlung in PPP-Dateneinheiten eingekapselt werden. Die PPP-Dateneinheiten werden noch vor ihrer Übermittlung in die Frames des bekannten Protokolls HDLC7 eingebettet. Da die Felder Address und Control im HDLC-Header auf Dauer festgelegte – und PPP-spezifische – Angaben enthalten, bezeichnet man sie als PPP/HDLC-Frames bzw. kurz als PPP-Frames.

Bild 004765: MP-Pakete und deren Übermittlung in PPP-Frames FCS: MP-H: PID:

Frame Checking Sequence MP-Header Protocol Identifier

Die Steuerkomponenten der HDLC-Frames – d.h. Header und Trailer – in PPP-Frames enthalten folgende Angaben: •

Flag: Mit Flags als Bitfolge 01111110 werden der Frame-

Beginn und das -Ende markiert. •

Address-Feld: Da die Adresse der Gegenseite bei der Daten-

übermittlung über einen Punk-zu-Punkt-Link nicht nötig ist, steht hier immer 0xFF (11111111). •

7

Control-Feld: Die Angabe 0x03 (00000011) verweist darauf, dass die PPP-Frames nicht nummeriert sind.

High Level Data Link Control

4

M ► MP

•

FCS-Feld: Dieses enthält eine – aus den Feldern Address, Control und aus der PPP-Dateneinheit beim Absenden des

PPP-Frames berechnete – Prüfsequenz, die man zur Entdeckung von Übertragungsfehlern in diesen Frame-Komponenten verwendet. Wie Bild 004765 zum Ausdruck bringt, verweist die Angabe 8 0x003D im Feld Protocol Identifier (PID) in der PPPDateneinheit darauf, dass diese ein MP-Paket als PPP-Nutzlast beinhaltet. Eine PPP-Dateneinheit dient somit als „Container“ für den Transport von MP-Paketen mit Datenfragmenten. Die maximale Länge des als PPP-Nutzlast transportierten MP-Pakets kann beim Aufbau einer Multilink-Verbindung als Parameter MRU festgelegt werden. Der Default-Wert von MRU beträgt 1500 Byte und entspricht somit der maximalen Länge der Nutzlast in Ethernet-Frames. Jedes MP-Paket besteht aus einen MP-Header und einem Datenfragment, wobei der MP-Header entweder 16 Bit oder 32 Bit lang sein kann. Demzufolge spricht man vom kurzen bzw. vom langen MP-Header. Der Unterschied zwischen ihnen besteht insbesondere in der Länge des Feldes Sequence Number (SN), denn die SN im kurzen MP-Header hat 12 Bit und die im langen MP-Header 24 Bit. Die Angaben im MP-Header haben folgende Bedeutung (vgl. Bild 004768): •

B (Beginning Fragment Bit): Mit B=1 wird das erste Fragment aus jedem Datenpaket eines Netzwerkprotokolls – beispielsweise des Protokolls IP – markiert. Somit ist nur im MP-Paket mit dem ersten Datenfragment B=1 und in allen MP-Paketen mit den darauf folgenden Fragmenten aus demselben Datenpaket B=0.

•

E (Ending Fragment Bit): Mit E=1 wird das letzte Fragment aus jedem Datenpaket markiert. Somit ist im MP-Paket mit dem letzten Datenfragment E=1 und in allen MP-Paketen mit den vorhergehenden Fragmenten aus demselben Datenpaket E=0.

8

Das Feld „PID“ enthält die Nummer des Protokolls, dessen Daten im PPPFrame enthalten sind. Für eine Auflistung von Protokollnummern siehe http://www.networksorcery.com/enp/protocol/ppp.htm

5

M ► MP

•

SN (Sequence Number): Mit SN werden die einzelnen Fragmente aus allen über ein Multilink-Bündel übermittelten Datenpaketen fortlaufend nummeriert.

Systemarchitektur des MP Das MP stellt eine Erweiterung von PPP dar – und muss somit mit der „PPP-Protokollfamilie“9 kooperieren. Wie dies erfolgt, lässt sich mithilfe der Systemarchitektur des MP erläutern. Bild 004766 illustriert diese, einen Fall darstellend, in dem die zu sendenden Datenpakete eines Layer-3-Protokolls wie IP und IPv6 weder komprimiert noch verschlüsselt werden. Die Komprimierung und die Verschlüsselung der zu übertragenden Datenpakete führt zu einer Erweiterung der Systemarchitektur des MP (vgl. Bild 004775 und Bild 004776).

Bild 004766: Systemarchitektur des MP: die Kooperation des MP mit den Protokollen LCP und NCP aus der PPP-Familie AuthProto: NCP: NP:

Authentifizierungsprotokoll, z.B. Challenge Handshake Authentication Protocol (CHAP) Network Control Protocol, z.B. IP Control Protocol (IPCP), IPv6 Control Protocol (IPv6CP) usw. Network Protocol, z.B. IP (IPv4), IPv6 usw.

9

PPP ist ein Rahmenwerk, das festlegt, wie die anderen Protokolle – beispielsweise Link Control Protocol (LCP) und Network Control Protocol (NCP) – quasi aus einer Familie kooperieren müssen; hierzu siehe: http://www.networksorcery.com/enp/topic/pppsuite.htm

6

M ► MP

LCP:

Link Control Protocol

Anmerkung: Bild 004766 zeigt die Systemarchitektur des MP bei einer Datenübermittlung in nur eine Richtung. Die Datenübermittlung in der Gegenrichtung verläuft nach den gleichen Prinzipien.

Wie aus Bild 004766 ersichtlich ist, fungiert das MP als Bindeglied zwischen den Instanzen eines Netzwerkprotokolls NP und seines Kontrollprotokolls NCP10 einerseits und den mit einzelnen Links verbundenen PPP-Instanzen andererseits. Vor der Datenübermittlung müssen die einzelnen Data Links oft entsprechend konfiguriert werden und eventuell müssen sich die über einen Data Link verbundenen PPP-Instanzen auch gegenseitig authentifizieren können. Bei PPP werden hierfür das Konfigurationsprotokoll LCP und ein Authentifizierungsprotokoll, wie z.B. das Challenge Handshake Authentication Protocol (CHAP), verwendet. Die Funktionen dieser Protokolle realisiert jede PPP-Instanz und demzufolge muss sie in sich sowohl deren Instanzen als auch die HDLC-Instanz enthalten (vgl. Bild 004765). Bild 004767 veranschaulicht dies. Aus der in Bild 004766 gezeigten Systemarchitektur des MP geht hervor, dass bei der Datenübermittlung die folgende Protokollhierarchie entsteht: NP Ö MP Ö PPP. Diese Hierarchie bestimmt die Art und Weise der Vorbereitung von zu versendenden Daten. Darauf wird jetzt eingegangen.

10

Bei PPP hat jedes Netzwerkprotokoll ein Konfigurationsprotokoll – das IP z.B. hat IPCP, damit seine Parameter vor der Datenübermittlung konfiguriert werden können.

7

M ► MP

Bild 004767: PPP-Instanzen: ihre Funktionen beim MP Vorbereitung von Daten für die Übermittlung Bild 004768 veranschaulicht, wie beim MP die Vorbereitung von Daten für ihre Übermittlung erfolgt – hier am Beispiel von IP bei der Protokollhierarchie IP Ö MP Ö PPP. Die Protokolle IP und MP können als Anwendungsprotokolle von PPP angesehen werden. Ihnen werden als eine Art Identifikation feste Nummern zugeordnet und zwar (hexadezimal geschrieben): 0x0021 dem IP und 0X003D dem MP.

Bild 004768: Vorbereitung einer Layer-3-Dateneinheit (L3Dateneinheit) zur Übermittlung – ohne Komprimierung und ohne Verschlüsselung Der zu übermittelnden L3-Dateneinheit – hier dem IP-Paket – wird die Nummer 0x0021 von IP bei PPP vorangestellt. Ist die Länge der L3-Dateneinheit größer als der beim Aufbau der MultilinkVerbindung festgelegte Parameter MRU, wird diese – in Bild 004768 das IP-Paket – auf mehrere Teile verteilt. Jedem Teil wird dann ein MP-Header vorangestellt und so entstehen aus diesen Teilen die sog. MP-Pakete, auch als Fragmente bezeichnet. Mit B=1 im 8

M ► MP

MP-Header wird das erste MP-Paket markiert und dementsprechend das letzte MP-Paket mit E=1. Ist eine L3-Dateneinheit „kurz“ und wird somit nicht aufgeteilt, bildet sie nur ein MP-Paket (Fragment) mit B=1 und E=1 im Header. Nach dem Aufbau einer Multilink-Verbindung werden die zu sendenden MP-Pakete aus allen L3-Dateneinheiten – mit 0 beginnend – fortlaufend mit der Angabe SN nummeriert. Auf jedem Data Link einer Multilink-Verbindung müssen die Werte von SN zunehmend sein (vgl. Bild 004772 und Bild 004773). Wie Bild 004768 zum Ausdruck bringt, wird jedes MP-Paket als Nutzlast in einem PPP-Frame übermittelt. Mit der Angabe 0x003D – die als Identifikation des MP dient – wird darauf verwiesen, dass ein MP-Paket als PPP-Nutzlast übermittelt wird. MP-spezifische LCP Configuration Options Die Besonderheiten einer Multilink-Verbindung werden durch einige Parameter spezifiziert. Diese können mithilfe MP-spezifischer LCP-Optionen zwischen den beiden Endpunkten der Verbindung ausgehandelt werden. Es handelt sich hierbei um folgende LCPOptionen11: •

Multilink Maximum Received Reconstructed Unit (MRRU) Diese LCP-Option wird zu zwei Zwecken verwendet: -

-

11

Mit der Angabe von MRRU in einer LCP-Nachricht Configure Request wird einerseits darauf verwiesen, dass eine Multilink-Verbindung initiiert werden soll – d.h. dass der Sender das MP realisiert – und andererseits wird mitgeteilt, wie lange Layer-3-Dateneinheiten aus den in MP-Paketen empfangenen Datenfragmenten am Ziel wiederhergestellt werden können. Der Wert von MRRU besagt folglich, welche maximale Länge eine gesendete Layer-3-Dateneinheit (z.B. ein IP-Paket) haben kann.12 Jedes System muss in der Lage sein, Dateneinheiten mit ei-

http://www.networksorcery.com/enp/protocol/lcp.htm

12

MRRU entspricht somit dem Parameter MTU (Maximum Transfer Unit) bei IP – also der maximalen Größe des IP-Pakets.

9

M ► MP

ner maximalen Länge von 1500 Byte wiederherzustellen, also der Maximallänge der Nutzlast in Ethernet-Frames. •

Multilink Short Sequence Number Header Format Mit dieser LCP-Option verweist man darauf, dass der kurze MPHeader – d.h. die kurze Sequence Number (SN) – verwendet werden soll (Bild 004765).

•

Endpoint Discriminator (ED) Jedes Ende in einem Multilink-Bündel kann eine als ED bezeichnete Identifikation besitzen. Ist das der Fall, so übernehmen alle zum Multilink-Bündel gehörenden Data Links an beiden Enden seine EDs. Auf diese Weise kann man einem MultilinkBündel mehrere Data Links zuordnen. Als ED kann z.B. eine IPAdresse oder eine MAC13-Adresse dienen.

Gestalten eines Multilink-Bündels Um die ihrem Bedarf entsprechende Übermittlungskapazität (Bandbreite) einer P2P-Verbindung zur Verfügung zu stellen, ermöglicht das Protokoll MP es, ein Multilink-Bündel dynamisch zu gestalten und zwar ein Multilink-Bündel einzurichten, einem MultilinkBündel einen Data Link hinzuzufügen und einen Data Link aus einem Multilink-Bündel zu entfernen. Das Hinzufügen eines Data Link zu einem Multilink-Bündel und das Entfernen eines Data Link aus einem Multilink-Bündel erfolgen so, dass dabei die bestehende Konfiguration des Netzwerkprotokolls oder dessen Verlauf nicht beeinflusst werden. Bild 004769 illustriert dies. Im hier gezeigten Beispiel sind folgende Phasen zu unterscheiden: A: Der erste Data Link zu einem Multilink-Bündel wird konfiguriert. B:

13

Das Netzwerkprotokoll – hier das Protokoll IP – wird konfiguriert. Somit entsteht ein „scheinbares“ Multilink-Bündel mit einem Data Link.

Media Access Control

10

M ► MP

C: Der zweite Data Link wird zu dem bereits bestehenden, scheinbaren Multilink-Bündel hinzugefügt, sodass ein MultilinkBündel mit zwei Data Links entsteht. Da es sich um eine bidirektionale Datenübermittlung zwischen den beiden Endpunkten X und Y handelt, muss jeder Endpunkt dem anderen Endpunkt im LCP-Paket Configure-Request seine Konfigurationsparameter übermitteln und dieser muss entweder mit dem LCP-Paket Configure-Ack bestätigen, dass er die Konfigurationsparameter akzeptiert, oder mit Configure-Nak mitteilen, dass er sie ablehnt. Demzufolge werden zwischen den beiden Endpunkten gegenseitig die LCP-Pakete Configure-Request und Configu14 re-Ack gesendet.

Bild 004769: Beispiel für das Gestalten eines Multilink-Bündels Conf-Req/Ack: Configure-Request/Acknowledgement

Die Phase A, d.h. die Konfiguration des ersten Data Link DL1, wird vom Endpunkt X durch das Absenden von Configure-Request

14

http://www.networksorcery.com/enp/protocol/lcp.htm

11

M ► MP

u.a. mit den Parametern MNX115, MRRUX und EDX initiiert (Schritt 1). Mit MRRUX wird einerseits darauf verwiesen, dass es sich um ein Multilink-Bündel handelt – somit muss das MP zum Einsatz kommen – und andererseits wird dem Endpunkt Y mitgeteilt, wie lang die von ihm in mehreren Datenfragmenten gesendeten Layer-3Dateneinheiten (z.B. IP-Pakete) sein dürfen, damit diese beim Endpunkt X aus mehreren in MP-Paketen übermittelten (vgl. Bild 004768) Datenfragmenten wiederhergestellt werden können. Mit EDX wird dem Endpunkt Y die Identifikation des Endpunktes X mitgeteilt, d.h. die Information, welche Identifikation jeder Data Link am Endpunkt X hat. Daraufhin – im Schritt 2 der Phase A – sendet der Endpunkt Y das LCP-Paket Configure-Request mit seinen Konfigurationsparametern MNY1, MRRUY, EDY und MRUY1. Mit MRUY1 teilt der Endpunkt Y dem Endpunkt X mit, in welcher maximalen Größe er die Datenfragmente in MP-Paketen auf dem Data Link DL1 empfangen kann (vgl. Bild 004768). Anschließend (im Schritt 3) bestätigt der Endpunkt Y dem Endpunkt X mit Configure-ACK, dass er seinerseits die von diesem im Configure-Request mitgeteilten Konfigurationsparameter MNX1, MRRUX und EDX registriert hat. Im abschließenden Schritt 4 der Phase A bestätigt der Endpunkt X dem Endpunkt Y mit Configure-ACK, dass auch er dessen Konfigurationsparameter MNY1, MRRUY und EDY registriert hat. Gleichzeitig gibt der Endpunkt Y dem Endpunkt X mit MRUY1 an, bis zu welcher Größe er die Datenfragmente auf dem Data Link DL1 empfangen kann. Hiermit wird die Konfiguration des ersten Data Link aus dem Multilink-Bündel, dessen Endpunkte mit EDX und EDY identifiziert werden, abgeschlossen. Daraufhin kann bei Bedarf eine Authentifizierung erfolgen. Um dieses Multilink-Bündel mit nur einem Data Link zu nutzen, muss noch das Netzwerkprotokoll konfiguriert werden. Wie Bild 004769 zeigt, erfolgt die Konfiguration des Netzwerkprotokolls – hier des IP – in der Phase B. Während dieser Phase teilen sich die

15

Magic Number (MN) ist ein Parameter des Protokolls PPP; MN bezieht sich nur auf einen Data Link und dient dazu festzustellen, ob ein Data Link schleifenfrei (loop-free) ist.

12

M ► MP

beiden Endpunkte in den Paketen Configure-Request und Configure-Ack des Protokolls IPCP (vgl. Bild 004766) gegenseitig ihre Parameter (IP-Adressen, IP-Adressen der DNS16-Server, ...) mit. Das Hinzufügen eines neuen Data Link zum Multilink-Bündel stellt de facto die Konfiguration eines Data Link mit den Parametern EDX, EDY sowie MRRUX und MRRUY des bereits bestehenden Bündels dar. Wie aus Bild 004769 ersichtlich ist, verläuft die Phase C (das Hinzufügen von DL2 zum bestehenden Multilink-Bündel mit DL1) nach dem gleichen Prinzip wie die Konfiguration des ersten Data Link DL1 während der Phase A. Wurde DL2 zum Multilink-Bündel hinzugefügt, kann – falls erforderlich – eine Authentifizierung über DL2 durchgeführt werden.

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: 978-3827691422, Bestell-Nr. OL9142J http://shop.weka.de/protokolle-und-dienste-der-informationstechnologieonline

16

Domain Name System

13