Karten neu gemischt

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.