Werden ATM-Switches auf Workgroup-Level eingesetzt, so passiert dies selten auf der "echten" ATM-Ebene. Vielmehr wird in dieser Um- gebung meist die LAN-Emulation (LANE) verwendet. Der Grund: Die meisten LANs nutzen verbindungslose Protokolle wie Token-Passing bei Token-Ring-Netzen oder CDMA/CD bei Ethernet. Da ATM aber verbindungsorientiert arbeitet, sind eine Reihe von Anpassungen erforderlich. Diese Aufgabe übernimmt die LANE, und zwar so, daß an den Endgeräten und der darauf installierten Software einschließlich der Treiber keine Modifikationen erforderlich sind. Die wichtigste Aufgabe der LANE ist dabei die Übersetzung der MAC-Adressen auf die ATM-Adressen. Außerdem muß die LANE Dienste wie Broadcast oder Multicast bereitstellen, die ATM nicht originär anbietet, die in verbindungslosen LANs aber zum Standardumfang gehören. Die LANE-Software, die diese Dienste nachbildet, läuft auf den Switches, kann aber prinzipiell auf beliebigen ATM-Systemen realisiert werden. Die Performanz dieser Geräte ergibt sich somit aus der Leistungsfähigkeit der Hardware und der Qualität der Software-Implementierung.
Für die Tests auf der LANE-Ebene haben wir, abweichend von denen auf der ATM-Ebene, den ATM-Analyzer der Firma Radcom eingesetzt. Das Gerät kann sowohl die Signalisierung als auch die LANE simulieren. Je nach Konfiguration agiert es als virtuelles Endgerät und / oder als Switch, als LAN Emulation Client (LEC) oder als LAN Emulation Server (LES). Es eignet sich für die Durchführung von Streß- und Last-tests. Der Analyzer wurde so eingestellt, daß er 32 LAN Emulation Clients (LECs) simu- lierte. Die LANE-Dienste wurden in allen Tests von dem Switch zur Verfügung gestellt, an den der Analyzer jeweils angeschlossen war. Ziel der Tests ist es, die Implementierung der LAN-Emulations-Dienste auf ihre Stabilität und Performanz zu testen. Der Testzeitraum betrug für jede Messung 90 Sekunden.
Da waren´s nur noch fünf
Das Testfeld hat sich um ein Gerät verkleinert: Den Centillion 1400 von Bay Networks konnten wir in der Disziplin LAN-Emulation nicht untersuchen, weil er dafür ein Zusatzmodul benötigt, welches aber vom Hersteller nicht mitgeliefert wurde. Ohne dieses Modul ist der Switch zwar nicht "nackt" - er kann immerhin LANE-Verbindungen weiterleiten und läßt sich daher auch in Umgebungen mit LANE einsetzen. Allerdings ist dann sein Funktionsumfang eingeschränkt; zum Beispiel kann er für bestimmte Dienste nicht als Server auftreten.
Unser Test simuliert ein größeres ATM-Netz, in dem viele virtuelle LECs einer Interworking Unit (Ethernet-ATM-Switch) den Server beanspruchen. Die Clients bauen nach jeweils fünf Sekunden die LANE-Kontrollkanäle wieder ab und setzen dann erneut auf. So ensteht für die Switches eine erheblich höhere Last, als 32 reale LECs sie normalerweise erzeugen würden.
Dennoch können die Ergebnisse auch für kleinere Netze relevant sein, da die LAN-Emulations-Server (LES) etwa nach einem Stromausfall oder beim morgendlichen Arbeitsbeginn wesentlich höhere Anforderungen als im Normalbetrieb erfüllen müssen. In solchen Situationen gilt es, schnell genug zu reagieren, damit die LECs bei der Anmeldung im ELAN nicht in Timeouts laufen und dann ihre Anforderungen erneut senden. Dies würde erfahrungsgemäß dazu führen, daß das gesamte Netzverhalten instabil wird.
Über die Performanz der LE-Services hinaus testeten wir auch, ob die Übertragung in den Datenkanälen der LANE stabil ist. Dazu verschickt der Analyzer künstlich erzeugte IP-Pakete an aktive LECs. Daraus lassen sich zwei Informationen gewinnen: Erstens wird getestet, ob der Verbindungsaufbau der Datenverbindungen (Data Direct VCCs) stabil läuft. Zum zweiten können so Rückschlüsse auf die Leistungsfähigkeit des "Broadcast and Unknown Servers" (BUS) gezogen werden. Letzterer ist auf dem LES für die Übertragung von Daten zu LAN-Emulations-Clients zuständig, bevor diese miteinander einen direkten Datenkanal aufgebaut haben.
Bei den LANE-Simulationstests fallen im wesentlichen zwei Gruppen von Meßdaten an: Daten über Latenzzeiten und Daten über die Anzahl der erreichten Verbindungen beziehungsweise Anmeldungen. Die erste Gruppe zerfällt wiederum in verschiedene Teilwerte, die für die Beurteilung des Switch relevant sind:
- Call Establishment Time: Das ist die Zeit, die vergeht, bis eine signalisierte Verbindung "steht". Der Verbindungsaufbau erfordert den Austausch verschiedener Nachrichten: "SETUP", eventuell "CALL PROCEEDING", "CONNECT" und "CONNECT ACKNOWLEDGE". Das Verfahren erfolgt in der Manier eines "three way handshakes". Erst nach dem Austausch der letztgenannten ist eine Verbindung nutzbar.
- Call Release Time: Die Zeit, die für den Abbau einer signalisierten Verbindung benötigt wird. Auch bei einem geordneten Verbindungsabbau werden mehrere Nachrichten ausgetauscht: "RELEASE", "RELEASE COMPLETE".
- Die LE Config Time ist die Zeit, die für die Beantwortung einer Anfrage an den Konfigurationsserver der LAN-Emulation (LAN Emulation Configuration Server, LECS) benötigt wird. Der LECS verwaltet die ELANs, die im ATM-Netz aktiv sind. Dazu ordnet er deren Namen die Adressen ihrer LES zu. Ein LEC muß also von dem LECS die Adresse des LES erfragen, bevor er sich in einem ELAN anmelden kann. Nicht enthalten im Begriff der LE Config Time ist die Zeit, die benötigt wird, um den Kontrollkanal vom LEC zum LECS aufzubauen, da diese Zeit bereits in den Signalisierungsstatistiken enthalten ist.
- Unter LE Join Time ist die Zeit zu verstehen, die von der Anfrage eines LEC bis zur Anmeldung durch den Server vergeht. Diese Latenzzeit beschreibt nicht nur, wie lange der LES für die Prüfung der Join-Anfrage benötigt, sondern auch, wie lange er für den Aufbau eines weiteren Blatts der Punkt-zu-Mehrpunkt-Verbindung benötigt, über die er Adreßauflösungsanfragen (ARP Requests) an alle Clients schickt. Diese Verbindung etabliert der Server über einen Austausch von "JOIN REQEST" und "JOIN RESPONSE". Die LE Join Time enthält nicht die Zeit, die benötigt wird, um den Kontrollkanal vom LEC zum LES aufzubauen.
Bei allen Tests emulierte der Analyzer 32 virtuelle LECs. Um eine "produktive" Verbindung anzumelden, muß der Switch eine ganze Reihe von Virtual Channel Connections (VCCs) per Signalisierung aufbauen: Pro Anmeldung wird ein "Config-Direct-Kanal" zum LECS geschaltet. Zum LES geht ein "Control-Direct-VCC", vom LES zum Analyzer ein "Control-Distribute-VCC". Der BUS empfängt Daten über die Verbindung "Multicast Send" und gibt die Daten weiter über die VCC "Multicast Forward". Pro Anmeldung werden also aus der Sicht des Clients drei abgehende und zwei ankommende Verbindungen aufgebaut.
Bild 1 gibt die Anzahl der insgesamt aufgebauten LANE operationalen Datenverbindungen (Data-Direct-VCCs) zwischen den virtuellen LECs über den Switch wieder. Diese Größe ist für den Anwender von besonderem Interesse: Sie beschreibt, wie oft der Analyzer zwischen den jeweils aktiven LECs Datenverbindungen aufbauen und darüber auch real Daten übertragen konnte. Wie oft während des Testzeitraums sich die LECs beim LANE Service anmelden konnten, hängt nicht nur von der Meßdauer ab, sondern darüber hinaus von einer Reihe weiterer Faktoren:
- Parameter der Sicherungsschicht der Signalisierung: Nach unseren Beobachtungen beeinflussen diese Parameter die Anzahl der Verbindungen, die ein Switch aufbauen kann. Diese Sicherungsschicht ist als Service Specific Connection Oriented Protocol (SSCOP) bekannt. Gelegentlich wird sie auch als Signalling ATM Adaptation Layer (SAAL) bezeichnet.
- Anzahl der Ports: Ein genereller Nachteil unseres Testszenarios ist es, daß wir die LANE immer nur an einem Port getestet haben. In der Realität entspricht das der seltenen Situation, daß sich die gesamte Last der Signalisierungs- und LAN-Emulationsaktivität auf einen Punkt konzentriert. Das wäre zum Beispiel der Fall, wenn der Switch LANE-Dienste für ein größeres Netz anbietet, das an einen einzigen Port angeschlossen ist, und der Switch ansonsten wenig zu tun hat. Ein besseres Szenario - sprich eine gleichmäßige Belastung mehrerer Ports - war jedoch mit unseren Mitteln nicht zu testen. Diese Meßanordnung zeichnet nicht unbedingt ein vollständiges Bild von der Leistungsfähigkeit eines Switches. Es ist nicht auszuschließen, daß manche Testgeräte eine wesentlich bessere Leistung bringen, wenn die Signalisierungs- und LANE-Last auf mehrere Ports verteilt wird.
- Adreßregistrierung. Zu Beginn jedes Tests erfolgt zunächst eine Adreßregistrierung zwischen Switch und Endgerät (ILMI, Integrated Local Management Interface) Das kann je nach Performance des Switches bis zu einigen Sekunden erfordern. Die eigentlich produktive Datenübermittlung kann erst beginnen, nachdem alle 32 virtuellen Clients beim Switch angemeldet sind. Dieser Einfluß ist allerdings durchaus im Sinne des Tests, da eine langwierige ILMI-Registrierung auch in der Realität die Performanz reduziert.
- Testdauer: Die Parameter des Tests selbst beeinflussen natürlich ebenfalls die Zahl der Verbindungen, die maximal aktiv werden können. Bei 32 virtuellen Clients, die fünf Sekunden lang aktiv bleiben, können innerhalb der Meßdauer von 90 Sekunden 576 Join-Vorgänge ausgeführt werden. Die gemessenen Werte müssen zu dieser oberen Schranke ins Verhältnis gesetzt werden.
Bild 1 gibt einen Überblick über das Verhalten der einzelnen Testteilnehmer im "Betriebsfall LAN Emulation". Sieht man sich die einzelnen Testergebnisse an, so ergibt sich ein recht gemischtes Testfeld. Bei der Anzahl der operatio-nalen LANE-Verbindungen, die der Switch im Testzeitraum aufbauen konnte, läuft der bisherige Mittelfeldspieler Cabletron zur Top-Form auf - er schaffte 282 Connections. Den zweiten Platz belegt der 8265 von IBM mit 242 Verbindungen. Als letzter geht Olicoms Crossfire 9200 mit 124 Verbindungen durchs Ziel.
Ebenfalls wichtig für die Beurteilung der Leistungsfähigkeit sind die Latenzzeiten beim Aufbau von LANE-Verbindungen. Wenn hier ein Switch schwach auf der Brust ist, macht sich das vor allem in Situationen bemerkbar, in denen viele Verbindungen gleichzeitig aufgebaut werden sollen. (Bild 2). Auch in dieser Disziplin rangiert der Cabletron-Vertreter vorne: Den wichtigen Service "LAN Emulation Join" bedient er in durchschnittlich 0,147 Sekunden, dicht gefolgt von dem IBM-Switch mit 0,159 Sekunden. Die beiden liegen auch beim "Call Release" in Führung. Einen achtbaren dritten Platz erkämpfte sich der 3Com Corebuilder. Da sich dieser noch im Betastadium befindet, könnte hier noch Steigerungspotential liegen. Das Schlußlicht bildet in der Disziplin "LE Join" das Gerät von Fore Systems. Fairerweise sei angemerkt, daß der Hersteller für Einsatzfelder mit starkem LANE-Anteil (beispielsweise "ATM to the Desk") empfiehlt, die LANE-Services auf dedizierten Geräten laufen zu lassen.
In der Disziplin "Call Establishment Time" leistet sich dagegen Olicom mit dem Crossfire 9200 einen Ausreißer: Der Däne läßt sich durchschnittlich 0,8 Sekunden Zeit für den Aufbau der signalisierten Verbindungen - fast fünfmal so viel wie der schnellste Vertreter bei dieser Messung. Nur ein mattes Glimmen zeigt der Crossfire auch in den Einzelmessungen "Call Release" und "LE Join", hier liegt er jeweils an letzter Stelle.
Differenzierung notwendig
Als Fazit dieses umfangreichen Vergleichstests ergibt sich ein zu facettenreiches Bild für plakative Aussagen. Keiner der getesteten Switches wartet quer durch alle Disziplinen mit optimaler Performanz auf, genausowenig wie kein Gerät durchgängig nur schwache Leistungen vorlegt. Einen recht positiven Gesamteindruck hinterließ der IBM-Switch. Er geht beim Aufbau der ATM-Verbindungen zwar eher bedächtig zu Werke, bei allen anderen Messungen zeigte er jedoch sehr ordentliche Resultate.
Nach dem Motto "wo viel Licht ist, ist auch viel Schatten", lotet der ASX-200BX von Fore Systems alle Höhen und Tiefen aus: Während er unter dem Aspekt des schnellen Verbindungsaufbaus alle Konkurrenten hinter sich läßt, gibt er bei der LAN-Emulation doch eine recht schwache Vorstellung - wobei allerdings der Hersteller den Daseinszweck des Geräts ohnehin nicht in LANE-intensiven Anwendungen sieht. Vielleicht sollte unser Fazit in Abwandlung eines englischen Sprichworts daher lauten: "Es gibt keine schlechten Switches, es gibt nur unpassende Anwendungsfelder".