Komplexität bremst die Performance
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.