Von: Kai-Oliver Detken
Für den Transport von TCP/IP-Daten über ATM-Infrastrukturen stehen derzeit zwei Verfahren zur Verfügung: "LAN Emulation" (LANE) und "Multiprotocol Over ATM" (MPOA). Eine ausführliche Darstellung der Funktionsweise dieser Techniken finden Sie auf Seite 85ff. Weil beide mit unterschiedlichen Szenarien im Hinterkopf entwickelt wurden, weist jede eigene Stärken und Schwächen auf. Vor allem zeigt sich, daß die Gesamtleistung des Netzes von sehr vielen Parametern abhängt. Entscheidender Einfluß kommt der Performance der ATM-Karten und der Endgeräte zu. Aber auch die Wahl der Paketgröße spielt eine bedeutende Rolle, weil sie eine Fragmentierung der Übertragung nach sich ziehen kann. Nicht zu vernachlässigen ist auch die Konfiguration der Empfangs- und Sendepuffer.
Bei der Bewertung der Meßszenarien sind einige Besonderheiten zu beachten. Wir haben sowohl LANE als auch MPOA berücksichtigt. Allerdings ist mit LANE kein Routing möglich; das Meßszenario sieht daher nur ein einzelnes "emuliertes LAN" (ELAN) vor. Das ist der optimale Fall, da die Daten nicht noch durch einen Router weitergeleitet werden müssen, der zusätzliche Latenzzeiten verursachen würde. MPOA dagegen unterstützt sowohl Forwarding als auch Routing. Die Messungen umfassen daher mehrere ELANs. Ein direkter Vergleich zwischen LANE und MPOA ist somit nicht ohne weiteres möglich, die Ergebnisse erlauben aber Rückschlüsse auf die Effektivität von MPOA. Um eine Verfälschung der Meßergebnisse zu vermeiden, haben wir die nicht getesteten Funktionen der Switches, wie Spanning Tree und dynamisches Routing, abgeschaltet.
Die Fragmentierung, wie sie durch "unhandliche" Paketgrößen entsteht, beeinflußt die Messungen erheblich. Um Performance und Latenzzeiten korrekt wiedergeben zu können, haben wir bei den Messungen unterschiedliche Paketgrößen vorgegeben. Typische Werte im IP-Bereich sind 100 Byte, 1500 Byte und 64 KByte. Bei Client/Server-Anwendungen fallen häufig kleine Datenpakete an; sie stellen somit die Netzbelastung im Regelfall dar. Pakete mit 1500 Byte passen genau in die maximale Rahmengröße eines Ethernet-Frames. Hierbei entsteht keine Fragmentierung, weshalb optimale Performance zu erwarten ist. Schließlich haben wir auch noch Pakete von 64 KByte getestet, weil das die maximale Paketgröße des Internet-Protokolls darstellt. Pakete dieser Größe müssen fragmentiert werden, die Latenzzeiten nehmen daher zu, und die Performance sinkt.
LAN-Emulation
Die LAN-Emulation wurde mit einem Szenario getestet, das ausschließlich aus Geräten von Bay Networks bestand; eine Auflistung der Geräte enthält der Kasten "Das Testfeld" auf Seite 110. Wir konfigurierten die Testgeräte so, daß der eine Switch des Typs Centillion 100 als "LAN Emulation Server" (LES) fungierte, während der andere als "LAN Emulation Client" (LEC) diente. Im Backbone leitete ein ATM-Switch vom Typ Centillion 1600 die Datenpakete weiter.
Um Verbindungen bei LANE automatisch aufzubauen, müssen LEC und LES miteinander kommunizieren. Der Datenaustausch erfolgt dabei über den Backbone-Switch sowie den Protokollanalysator, in diesem Fall ein Interwatch 95 000 von GN Nettest. Bild 1 zeigt den Meßaufbau. Mit dieser Anordnung führten wir folgende Tests durch:
Performance Ethernet-Ethernet, Performance ATM-ATM und BUS-Performance (BUS=Broadcast and Unknown Server).
Der BUS läßt nur die Unknown-Adressen durch. Letztere dienen der Zuteilung der Adressen; sie wurden auch für unsere Messungen verwendet. Den ARP-Request (ARP=Address Resolution Protocol) benutzten wir wegen der fehlenden Endgeräte nicht. Ein Problem bei den Benchmark-Tests ist die Aussendung eines Ping, der als anhaltender Broadcast gesendet wird, weil die MAC-Adresse nicht bekannt ist. Diese Pings verfälschen die Meßergebnisse. Ein alle paar Minuten in entgegengesetzter Richtung gesendetes Reply löst das Problem und teilt die Adresse mit. Dadurch läßt sich die Performance eines Links exakt nachstellen. Es kommt zu einer besseren Auslastung, weil kein ständiger Broadcast gesendet, sondern der wirkliche Verkehr gemessen wird.
Die Performance-Messungen auf der Ethernet-Seite erfolgten über einen einzigen Port mit einer vorgegebenen Auslastung von 100 Prozent. Dabei zeigte sich, daß der Durchsatz nach sehr kurzer Zeit auf 13 500 Frames/s steigt und sich dort hält. Das entspricht einer effektiven Auslastung mit Nutzdaten von 99,4 Prozent.
Anschließend testeten wir die Performance des BUS auf der ATM-Seite. Der maximale Durchsatz betrug dabei circa 53 000 Zellen/s, was einer Übertragungsrate von 22,47 MBit/s entspricht. Die Geräte wurden dabei in der Betriebsart Full Duplex bei voller Auslastung betrieben, der Switch erreichte also die theoretisch maximale Leistung.
Dieses Ergebnis ist von der Datenrate unabhängig. Es ließ sich immer nur für etwa eine Minute halten, danach mußte der Centillion 100 neu gestartet werden, um LANE wieder zu aktivieren. Bei voller Auslastung kommt es nämlich zu einem Abschneiden der Signalisierungspakete. Die Folge: Der Switch versagt seinen Dienst. Das ist natürlich eine negative Erscheinung. Allerdings dürfte es in der Praxis kaum zu einer solchen Überlastsituation kommen, denn der BUS muß nur die Unknown- und Broadcast-Pakete transportieren. Nach ihrem Aufbau wird die Verbindung direkt von LEC zu LEC weitergeschaltet. Dadurch läßt sich die maximale Nettodatenrate einer ATM-Verbindung erzielen. Burst-Verkehr kann somit aufgefangen werden. Dieser darf aber bei voller Auslastung nicht länger als etwa eine Minute andauern.
Wie sich zeigte, gehen die Bay-Komponenten mit der LAN-Emulation sehr effizient um. Weder die Konfiguration noch der Betrieb der ELANs bereiteten größere Probleme. Schwierigkeiten gab es allerdings nach mehrmaliger Wiederholung der Konfiguration, weil sich der LEC nicht einwandfrei wieder aufsetzen ließ.
Multiprotocol over ATM (MPOA)
Die MPOA-Messungen unterscheiden sich von den vorangegangenen Tests: Sie liefen auf Geräten von Newbridge Networks, die hauptsächlich dieses Verfahren unterstützen. Um die Routing-Funktionen einzubeziehen, konfigurierten wir verschiedene Subnetze.
Für den MPOA-Aufbau verwendeten wir die Vivid-Serie von Newbridge. Dabei setzten wir zwei Switches des Typs CS3000 für den Backbone ein, während wir für die Umsetzung von ATM auf Ethernet "Orange-Ridge"-Geräte heranzogen. Außerdem aktivierten wir die Funktion "Private Network to Network Interface" (PNNI), damit das Routing automatisch erfolgen konnte. Die Softwareversion 3.0 von Newbridge ist noch nicht mit der MPOA-Spezifikation des ATM-Forums kompatibel, ein Test der Interoperabilität war deshalb nicht möglich. Den Meßaufbau zeigt Bild 3. Mit dieser Anordnung läßt sich auch die Performance des "Route-Servers" ermitteln, der ähnliche Aufgaben wie der BUS besitzt. Der Test wurde in den gleichen Schritten wie bei der LAN-Emulation durchgeführt, um einen Vergleich zu ermöglichen.
Die Messung kam zu dem gleichen Ergebnis wie zuvor der LANE-Test. Auch hier war die maximale Performance natürlich nicht über die mögliche Datenrate hinaus zu steigern. Eine Variation der Paketgröße auf 100 Byte, 1000 Byte und 64 KByte brachte keine unterschiedlichen Ergebnisse. Das liegt an der verfügbaren Datenrate von lediglich zehn MBit/s, die die Switches nicht in Verlegenheit bringen konnte. Die Auslastung betrug effektiv 99,4 Prozent.
Die zweite MPOA-Messung führten wir wieder mit einer Auslastung von 100 Prozent durch. Bei diesem Test konfigurierten wir zwei Subnetze. So zwangen wird den Router, eine Auswahl des Übermittlungswegs vorzunehmen und den Datenverkehr anschließend über eine Shortcut-Verbindung direkt an den Switch weiterzuleiten. Nach einer bestimmten Zeitspanne mußte der Route-Server neu gestartet werden, weil er seinen Dienst versagte, ähnlich wie der BUS bei LANE. Als maximalen Durchsatz ermittelten wir 27 000 Zellen/s. Dies ergibt eine Datenrate von 11,45 MBit/s, also ungefähr die Hälfte der bei LANE gemessenen Bandbreite. Zu erklären ist dieses Phänomen dadurch, daß die Messungen hier nur unidirektional erfolgten. Die Performance ist ansonsten identisch mit der LANE-Messung.
Als nachteilig erwies sich die fehlende Standardkonformität in der vorliegenden Software Version 3.0. Außerdem war das Edge Device Orange Ridge mit nur einem ATM-Uplink ausgestattet, der keine redundanten Verbindungen zuließ. Auch die Managementsoftware hat nicht nur Schokoladenseiten: Sie läßt sich zwar sehr einfach bedienen, macht aber bei der Konfiguration Probleme. Außerdem läuft sie bislang nur auf einer teuren Sun-Workstation, wobei sie nicht einmal die neueste Solaris-Version 2.6.1 unterstützt. Eine Umsetzung auf Windows NT ist laut Hersteller nicht geplant.
Die Interoperabilität testeten wir mit den ATM-Switches von Olicom (Crossfire OC-9100) und Bay Networks (Centillion 100). Beide Olicom-Geräte sind reine ATM-Switches, die sowohl den LANE-Service (ohne LEC) wie auch "Classical IP" (Clip) unterstützen. Auf den beiden Centillion 100 läuft wiederum der "LAN Emulation Server" (LES) sowie der "LAN Emulation Client" (LEC). Die Messung bezieht sich auf die Kombination LES-BUS und "LAN Emulation Configuration Server" (LECS); der zweite Switch ist lediglich als LEC dazu geschaltet.
Switches erkennen einander nicht
Es bestünde theoretisch die Möglichkeit, beide Switches aus Gründen der Redundanz als LANE-Server zu betreiben. Das ist aber bislang noch nicht als Standard festgelegt und funktioniert dementsprechend nur als proprietäres Merkmal bei Bay Networks und Olicom. Beide Geräte bekommen jeweils ATM- und IP-Adressen. Diese sind für das ELAN sowie für die Ansteuerung der Geräte über die serielle Schnittstelle oder das 10Base-T-Interface separat zu vergeben. Ein ELAN-Name ist ebenfalls festzulegen, damit sich die Geräte alle im selben ELAN beziehungsweise VLAN befinden.
Für die Interoperabilitätstests konfigurierten wir zunächst die beiden Olicom-Switches. Für die Einstellungen steht das Management-Tool "Crossfire ATM Switch Manager" zur Verfügung. Nach der Inbetriebnahme erkannten sich die Switches gegenseitig ohne weiteres. Danach stellten wir auf die Switches der Centillion-100-Reihe von Bay Networks die gleichen Werte ein. Auch hier ergaben sich bei der PNNI-Konfiguration keine Probleme. Mit dem Managementtool Speedview lassen sich die Einstellungen schnell und effektiv eingeben. Allerdings erfordert Speedview bei jeder Änderung einen Reset des gesamten Switches. Die Handhabung ist aber ähnlich einfach wie bei den Olicom-Geräten.
Anschließend schalteten wir die beiden Switches zusammen. Dieser Test offenbarte Schwierigkeiten bei der weiteren Konfiguration von PNNI: Die Switches konnten sich nicht alle untereinander "sehen". Nur drei Switches in einer Peer Group ließen sich einwandfrei erkennen. Ein möglicher Grund könnte darin liegen, daß auf den Olicom-Switches neben PNNI auch das proprietäre Protokoll "Clearsession Network-Network Interface" (CNNI) lief. Jedenfalls verhindert dieses Phänomen ein dynamisches Routing zwischen allen Switches. Zwar brachten weitere zeitaufwendige Konfigurationen einen Erfolg, der Aufwand steigt aber an, wenn man Switches unterschiedlicher Hersteller in einem Netz zusammenschaltet.
End-to-End-Performance
Um den Durchsatz über eine Gesamtstrecke unter Einbezug sämtlicher relevanter Elemente zu testen, schalteten wir zwei Endgeräte in einer Punkt-zu-Punkt-Verbindung über einen ATM-Switch miteinander zusammen (Bild 5). Bei den Endsystemen handelt es sich um PCs unter Windows 95. Die ATM-Adapterkarten stammten von Fore Systems. Die physikalische Verbindung wurde, wie auch bei den anderen Messungen, über die STM-1-Schnittstelle realisiert. Somit stand eine Bruttoübertragungsrate von 155 MBit/s zur Verfügung. Als zentralen ATM-Switch setzten wir einen Crossfire OC-9100 von Olicom ein. Er verfügt über ein einzelnes ATM-Modul mit vier OC-3-Schnittstellen.
Als Übertragungsart wählten wir LANE. Auf beiden Endsystemen läuft außerdem das Programm "Netperf", welches auf dem einen Rechner als Client und auf dem anderen als Server fungiert. Es handelt sich dabei um eine Benchmark-Software von Hewlett-Packard, welche die Performance von Netzwerken mißt. Dabei liegt das Hauptaugenmerk auf dem Verhalten bei Burst-Verkehr und der Request/Response-Performance. Sende- und Empfangspuffer werden schrittweise von 16 KByte bis 64 KByte erhöht, um die unterschiedlichen Einflüsse zu erkennen. Das Nachrichtenpaket umfaßt dabei 1500 Byte; bei LANE ist das der Default-Wert für die "Maximum Transport Unit" (MTU). Die Messungen konzentrierten sich auf die Auswirkungen der unterschiedlichen Sende- und Empfangspuffer, weil diese den größten Einfluß ausüben und sich die daraus resultierenden Effekte am besten auswerten ließen. Es empfiehlt sich, bei dieser Anordnung nicht ausschließlich den Durchsatz im Auge zu behalten. Vielmehr sind auch dessen Schwankungen von Interesse.
Bild 6 zeigt die beschriebene Messung bei einer Paketgröße von 576 Byte und variierenden Sende- und Empfangspuffern von 15 bis 65 KByte. Diese Paketgröße stellt in der Internet-Umgebung ein normales Datagramm dar.
Weil bei LANE die Datenpaketgröße auf 1500 Byte festgelegt ist, kam es bei jedem dritten Datenpaket zu einer Fragmentierung. Das wirkte sich negativ auf die Performance aus; vor allem bei kleinen und sehr großen Puffern waren Einbrüche zu verzeichnen. Ein anderes Bild ergibt sich bei einer Paketgröße von 1500 Byte. Damit läßt sich ein höherer Durchsatz erzielen, wobei allerdings auch hier Schwankungen entstehen. Diese zeigen sich besonders stark bei einer Puffergröße von 55 KByte. Die besten Ergebnisse kommen bei 40 KByte und 65 KByte zustande.
Eine wesentlich bessere Performance läßt sich bei einer Paketgröße von 9180 Byte erzielen. Hier erreicht der Durchsatz Werte bis zu 27,3 MByte. Die Schwankungen halten sich in engeren Grenzen als bei den anderen Messungen. Bei der letzten Messung dieser Reihe wählten wir eine MTU-Size von 65 KByte. Bei dieser Einstellung ist die Wahl der richtigen Puffergröße besonders kritisch (Bild 7). In ungünstigen Fällen reduziert sich der Durchsatz auf weniger als 5 MBit/s.
In dieser Meßanordnung verwendeten wir Pentium-PCs, die zwar nicht die Performance aktueller PCs bieten, aber in den Unternehmen in großer Zahl anzutreffen sind. Einen Einfluß auf den Durchsatz üben auch einige TCP-Mechanismen aus, etwa Quittierungsverfahren, zu kleine Window-Sizes und Sequenznummernüberläufe. Zusätzlich ist natürlich die Performance der ATM-Karten ausschlaggebend. Mit den benutzten Karten von Fore Systems waren bei allen Tests keine höheren Datenraten als 32 MBit/s erreichbar. Das liegt zum einen an der relativ geringen Leistungsfähigkeit der Endgeräte, weiterhin an dem eingesetzten Betriebssystem Windows 95, welches große Performance-Reserven benötigt, und schließlich an den Adapterkarten selbst.
Fazit
LANE ist ein ausgereifter Standard, der bei den Komponenten von Bay Networks durch seine einfache Konfiguration und hohe Performance besticht. Die Durchsätze von LANE und MPOA sind durchaus vergleichbar, solange sich die kommunizierenden Clients im selben ELAN befinden. Sobald jedoch ein Router zwischen zwei ELANs geschaltet wird, nimmt die Leistung deutlich ab. In solchen Umgebungen ist der Einsatz von MPOA interessant und zweckmäßig. Auch wichtig: LANE unterstützt nur "Unspecified Bit Rate" (UBR). Somit ist es nicht möglich, eine Dienstqualität (Quality of Service, QoS) anzugeben. MPOA soll das zukünftig ändern.
Die MPOA-Implementierung von Newbridge ist bislang nicht mit dem Standard in Gestalt der MPOA-Version 1.0 des ATM-Forums konform. Das aktuelle Software-Release 3.0 von Newbridge unterstützt auch nur das "Next Hop Resolution Protocol" (NHRP) und LANE Version 1.0. Die nächste Ausgabe der Software soll das ändern. Die Newbridge-Software unterstützt QoS nur in reinen ATM-Umgebungen. Der MPOA-Router der Vivid-Serie routet den Verkehr allerdings sehr effizient über NHRP durch das Netz weiter.
MPOA-Lösungen sollten wegen dieser Schwächen nur in Umgebungen mit vielen Subnetzen und Routern eingesetzt werden. Die immer noch sehr populäre Ethernet-Technik am Rande des Netzes kann sonst die Vorteile wieder zunichte machen. Die Hersteller nehmen sich jetzt erst dieser neuen Technologie an, Inkompatibilitäten sind daher vorauszusehen. Die MPOA-Implementierung des ATM-Forums ist noch deutlich zu erweitern, um offene Fragen des Standards zu beseitigen.
Eine korrekte Konfiguration der Endgeräte und der Sende- und Empfangspuffer sowie von LANE und MTU-Size steigert den Durchsatz erheblich. Allerdings ist dafür ein sehr hoher Aufwand erforderlich. Das gilt nicht nur für Switches und Übertragungskanäle, sondern auch die Endgeräte mit ihren Betriebssystemen. Momentan führt diese Komplexität dazu, daß TCP über ATM relativ ineffizient arbeitet. (ch)