Die ersten Implementierungen, die auf der Basis offener Spezifikationen laufen, sind die ATM-LAN-Emulation (ATM-LANE) in der Version 1.0 sowie Classical IP over ATM (RFC 1577). Als zukünftige Erweiterungen zeichnen sich Vereinbarungen für virtuelle LANs (VLANs) mit LANE sowie das Multiprotokoll-Routing (Multiprotocol over ATM = MPOA, Private Network to Network Interface = PNNI, Integrated PNNI=IPNNI) ab.
Bei der ATM-LANE verhält sich das ATM-Netzwerk wie ein oder mehrere LANs, es emuliert ein LAN. Die aktuelle Forumsversion 1.0 spezifiziert einen reinen MAC-Dienst für Ethernet und Token Ring. Als Vorteil der LANE lassen sich Protokolltransparenz sowie in der einfachen Form ein relativ unkompliziertes Zusammenspiel mit existierenden Standard-LAN-Umgebungen nennen. Allerdings beschränkt sich die Definition aufgrund der reinen Brückenfunktionen nur auf Ethernet und Token Ring. Außerdem lassen sich die ATM-Dienste Quality of Services (QOS) nicht nutzen.
Classical IP over ATM beschreibt mit RFC 1577 LAN-Umgebungen, in denen das LAN als physikalisches Subnetz durch ATM ersetzt wird. Adress-Resolution-Protocol-(ARP-)Anfragen an unbekannte IP-Zieladressen beantwortet ein ARP-Server. Classical IP over ATM arbeitet prinzipiell ähnlich wie LANE, Vorteile liegen jedoch im Einsatz eines ARP-Servers sowie einer größeren Maximum Transfer Unit (MTU).
Während bei LANE ein IP-ARP-Request als MAC-Broadcast in das gesamte emulierte LAN weitergeleitet wird (an alle LANE-Clients und die über sie angebundenen LANs), wird er laut Spezifikation RFC 1577 an einen ARP-Server gesendet, der die Anfrage beantwortet. Die MTU ist größer als bei LANE, da auf IP-Ebene eine Fragmentierung möglich ist. In Installationen mit Classical IP over ATM ist jedoch zur Verbindung verschiedener Subnetze nach wie vor ein Router erforderlich. Im ungünstigsten Fall bedeuet dies, daß ein Paket einmal quer durchs ATM-Netz an den Router weitergeleitet, dort umgesetzt und zurück durch das ATM-Netz an das entsprechende Subnetz geschleust wird.
Eine weitere Spezifikationslücke besteht für IP-Broadcasts und Multicasts. Hier ist noch ein dem Broadcast and Unknown Server (BUS) der LANE ähnliches Instrument zu vereinbaren. Aktuelle Verbesserungsansätze gegen die genannten Nachteile sind das Next Hop Routing Protocol (NHRP) und die Multicast Address Resolution (Mars).
MPOA soll verschiedene routbare LAN-Protokolle (zum Beispiel IP, IPX, Appletalk, Decnet) bedienen und "virtualisiert" logische Subnetze so, daß sie nicht mehr physikalisch zusammenhängend definiert werden müssen. Das Routing erfolgt nach dem "Ein-Hop"-Prinzip, für die Paketweiterleitung in ein anderes Zielsubnetz wird also kein zwischengeschalteter Router mehr benötigt. MPOA definiert statt dessen einen "virtuellen Router" mit zentralistischer Architektur: Sogenannte Edge-Devices (oder auch Multilayer-Switches) verbinden traditionelle LANs mit dem ATM-Netz und stellen die "Netz-Interfaces" des virtuellen Routers dar. Hosts mit direkter ATM-Anbindung sind wie ein "Host Link" an den virtuellen Router angebunden, wobei der ATM-Adapter des Rechners als Netzinterface des virtuellen Routers fungiert (siehe Abbildung rechts).
Die virtuelle Router-CPU besteht aus einem oder mehreren zentralen Route-Servern. Das ATM-Netz realisiert die Bus-Struktur zur Verbindung der Router-Interfaces untereinander und mit der CPU. Für den Pakettransport bauen die Edge-Devices einen Cache auf, in dem Ebene-3-Adressen einzelner Hosts auf MAC-Adressen und ATM-Adressen gemappt werden. Für die Interaktion des Route-Servers mit den Edge-Devices muß ein neues Protokoll definiert werden - ein schwieriges und sehr umfangreiches Unterfangen für das ATM-Forum.
Ein Vorteil von MPOA ist die ATM-gerechte Behandlung von Broadcasts und Multicasts zum Verbindungsaufbau. Diese Nachrichten werden nicht mehr an alle ATM-Ausgangspunkte versendet, sondern gerichtet weitergeleitet werden. Ein weiterer Vorteil ist die Skalierbarkeit: Die Anzahl eingesetzter Route-Server und Switches beziehungsweise Edge-Devices kann völlig unabhängig voneinander ausgebaut werden. Nachteilig ist der entstehende Overhead am Edge Device: MPOA setzt nach dem aktuellen Diskussionsstand aus Kompatibilitätsgründen mindestens auf LAN Emulation auf, unter Umständen wird zusätzlich noch IPNNI genutzt. Somit müssen eventuell weitere Treiber verwendet werden, deren erste Versionen als langsam gelten.
Ein weiterer Ansatz, der oft als MPOA-Alternative bezeichnet wird, ist die reine Nutzung von IPNNI und PNNI. Ersteres ist ein Protokoll, um Pakete der OSI-Ebene 3 durch ein ATM-Netz durchzuschalten. Es ähnelt dem TCP/IP-Verfahren Open Shortes Path First (OSPF). Um den optimalen Weg auf ATM-Ebene zu finden, benutzt es das PNNI.
Genauer betrachtet, sind IPNNI und MPOA jedoch komplementär: Ohne das integrierte PNNI könnte in MPOA-Umgebungen nur ein einziger Route-Server benutzt werden. Die Spezifikation für den Betrieb verschiedener Protokolle in ATM-Netzen definiert nämlich nicht , wie diese Geräte untereinander kommunizieren. IPNNI liefert also die notwendige Skalierbarkeit für MPOA. Im Gegenzug benötigt IPNNI soviel Speicherplatz und CPU-Kapazität, daß es auf einzelnen Endgeräten oder kleinen Edge-Devices (ohne PNNI-Implementierung) nicht einsetzbar ist. Diese verwenden darum nur einen Route-Server und das MPOA-Verfahren. IPNNI wäre auch nicht in der Lage, einzelne Hosts mit ATM-Interface zu unterstützen, da es ein reines Routing-Protokoll ist.
Die Anforderungen, die ATM an die Systemhardware stellt, sind sehr hoch. Tests in einer Workstation-Umgebung an der Technischen Universität in Dresden haben gezeigt, daß der erzielbare Durchsatz von der konfigurierten Puffergröße und Paketlänge abhängt. Verfügt der Zwischenspeicher über ein Polster von 64 KB, erreichte der Durchsatz einen Wert von bis zu 135 Mbit/s. Reduziert sich der Puffer auf 8 KB, sinkt die Übertragungsrate auf 40 Mbit/s. Generell gilt: Je größer die Paketlänge ist, desto höher wird der Nutzdatendurchsatz.
Für DOS-Rechner gibt es keine Treiber
Client-Server-Umgebungen mit ATM-LANE benötigen mindestens 24 bis 32 MB an Hauptspeicherkapazität in den Endgeräten. Für DOS und Windows 3.11 gibt es am Markt keine beziehungsweise nur wenige LANE-Treiber. Ein etwas besseres Angebot liefert der Markt für Netware oder Windows NT. Classical IP (RFC 1577) ist nicht für alle Adapterkarten durchgehend implementiert. Dabei sind die meisten Lösungen für Ethernet und nur wenige für Token Ring konzipiert.
Als Server kommt nur noch ein Pentium-PC mit 133-Megahertz-CPU, PCI-Bus und mindestens 32 MB, besser 64 MB Hauptspeicher in Frage. Allerdings ist der aggregierte Durchsatz eines Servers im Tests ausgesprochen dürftig: Der Server liefert beim File-Transfer unter dem Windows NT Advanced Server und der Ethernet-LAN-Emulation lediglich einen Durchsatz von 30 Mbit/s. Für diese Resultate gibt es zwei Gründe: Erstens kontrolliert bei ATM das Endgerät die Verbindung (über AAL) und muß daher entsprechend mehr Software-Aktionen ausführen. Zweitens ist die Treibersoftware in den heutigen frühen Versionen noch nicht optimiert.
Die Fachwelt ist sich inzwischen weitgehend darüber einig, daß ATM nur mit sogenannten nativen Anwendungen effizient betrieben werden kann, die direkt auf den definierten ATM-Ebenen aufsetzen. Etablierte Protokoll-Stacks wie TCP/IP, Netware oder NT Advanced Server sind aufgrund der eingebauten Kontroll- und Quittungsmechanismen zu langsam und können außerdem die von ATM angebotenen Dienste nicht nutzen.
In Anbetracht der Komplexität der eingesetzten Softwaremodule im Verhältnis zur erreichbaren Performance stellt sich die Frage nach Alternativen. Bei einer Reihe von Anwendern und großen Herstellern wird ATM nicht mehr als die ausschließliche Hochgeschwindigkeitstechnik betrachtet. "Wir setzen es ein, aber ich bin nicht überzeugt, daß ATM das letzte Wort der Switching-Technologie ist", schränkt etwa Vint Cerf, Vice-President bei MCI Communications Corp., ein. "Künftig setzten wir auf eine Kombination von ATM und Frame Switching", zeigt sich auch Andy Ludwick, Noch-President und -CEO von Bay, gegenüber ATM distanziert.
Auch die IBM verschließt sich nicht dem Switched- und Fast-Ethernet-Markt. Ein Beleg dafür ist die enge Kooperation mit Xylan, das in ebendiesem Geschäft groß geworden ist. Rick Mc Gee, verantwortlich für die Strategie der Network Hardware Division bei Big Blue, spannt den Bogen sogar noch weiter: "Wir unterstützen auch Gigabit Ehternet, wenn sich hier ein Markt ergibt, obwohl wir ATM für die bessere Technologie halten."
Die Migration von 10Base-T über 100Base-T und in zwei bis drei Jahren nach Gigabit Ethernet scheint bestechend, da stets dasselbe Frame-Format verwendet wird. Kein unbedeutendes Argument dürfte auch sein, daß das Know-how zum Betrieb dieser Netze nur schrittweise erweitert werden muß. Auch Switched FDDI bei großen Geländen in Kombination mit Ethernet-Varianten benötigt keine weiteren Softwaremodule, die Overhead darstellen würden. Daß die Verfechter von Switched LANs nicht schlafen, zeigen Initiativen, die etwa die Flußkontrolle bei Ethernet-Switches zur Minimierung von Paketverlust vereinbaren. Aber auch die Definition von VLANs in der Spezifikation IEEE 802.1q für die bessere Skalierbarkeit und das Resource Reservation Protocol (RSVP) sind gute Ansätze.
Sicherlich ist ATM für die Integration verschiedener Datentypen besser geeignet als herkömmliche LAN-Verfahren und deren Weiterentwicklungen. Es ist auch per Definition besser skalierbar als Shared LANs. Doch die Diskussion vor rund acht Jahren über die Realzeiteignung von Ethernet in Fertigungsumgebungen zeigt, daß durch entsprechende Netzdimensionierung und -strukturierung sowie Bereithaltung von Überkapazitäten die erforderlichen Hochleistungen erreichbar sind. Gigabit Ethernet hat nun diesen Disput wieder belebt. Das ATM-Forum ist nun gefordert, ausstehende Spezifikationen für QoS, MPOA und IPNNI nicht nur am grünen Tisch zu verabschieden. Die Mitglieder sollten möglichst schnell leistungsfähige Implementierungen vorlegen. Gleiches gilt für native ATM-Applikationen. Beendet die ATM-Technologie nicht innerhalb der nächsten drei Jahre ihre schleppenden Startversuche und erreicht einen entscheidenden Durchbruch, der sich auch im Marktanteil niederschlägt, könnte sich das asynchrone Verfahren im LAN zur Marktnische und späteren Altlast entwickeln.
Angeklickt
Die Zukunftstechnologie ATM wird von Weiterentwicklungen herkömmlicher LAN-Protokolle in die Zange genommen. Das asynchrone Verfahren gilt als komplex und schwer zu implementieren, wogegen die Vorteile wie Bandbreite, Sprach- und Datenintegration sowie die speziellen Funktionen Quality of Services noch nicht genutzt werden. Im Gegenzug liefern Switched- oder Fast-Ethernet-Umgebungen mittlerweile Funktionen und Leistungen, die an die ATM-Kapazität heranreichen.
Schwere Last
Heutige ATM-Implementationen ächzen unter der Last des Software-Overhead. Für die ATM-LAN-Emulation (LANE) müssen etwa 30000 Lines of Code geladen und ausgeführt werden. Das Private Network to Network Interface (PNNI) bringt es sogar auf etwa 100000 Programmzeilen. Soll dann auch noch das Verfahren Multiprotocol over ATM (MPOA) genutzt werden, fallen nach heutigem Spezifikationsstand weitere 50000 Lines of Code an.
*Petra Borowka ist unabhängige Beraterin für Netzwerke in Aachen.