Von Klaus Eppele*

Unbestritten gilt ATM (Asynchronous Transfer Mode) als die Netztechnik der Zunkunft. Dennoch wird sich heute kein Unternehmen finden, das sein Netzwerk sofort komplett darauf umstellt. ATM wird also in den naechsten Jahren mit herkoemmlichen Netztechnologien, den sogenannten Legacy LANs, kooperieren muessen. Deshalb sind Migrationswege gefragt, die zum einen bestehende Investitionen schuetzen, zum anderen aber die Vorteile von ATM ins Netzwerk bringen.

Die notwendigen Hardwarebausteine fuer die Emulation verbindungsloser Strukturen werden heute bereits am Markt angeboten - zum Beispiel in Form von kombinierten Cell- beziehungsweise Frame-Switches, die es erlauben, Ethernet-, Token- Ring- und FDDI-Netze mit ATM zu kombinieren. Was bisher noch fehlte, war die Sicherheit, dass die auf den bestehenden Rechnern installierte Software auch ohne Aenderung in ATM-Netze uebernommen werden kann.

Warum aber LAN-Emulation? Die Netze von heute arbeiten ueblicherweise verbindungslos. Will man mit einem Partner kommunizieren, ist keine Verbindung aufzubauen. Die Sendedaten werden lediglich zusammen mit der Zieladresse auf das verbindungslos arbeitende Shared-Medium-Netzwerk gegeben. In korrekt installierten Netzen besteht dann die Sicherheit, dass die Daten beim richtigen Empfaenger ankommen.

Bei ATM ist das Verfahren anders. Hier wird fuer jeden Sendewunsch eine dedizierte Verbindung aufgebaut. Sollen herkoemmliche Netze mit ATM kombiniert werden, ist dafuer Sorge zu tragen, dass gewohnte Mechanismen, wie zum Beispiel die Verwendung von Broad- und Multicasts, auf ATM-Strukturen abgebildet werden. Endgeraete, die via ATM kommunizieren moechten, muessen automatisch eine Verbindung ueber ATM erhalten. Ausserdem ist zu beachten, dass die vorhandenen Protokoll-Stacks und Applikationen auf den Endgeraeten auch mit ATM weiter genutzt werden koennen, ohne auch nur die kleinste Veraenderung an der installierten Hard- oder Software vornehmen zu muessen.

Nur unter diesen Voraussetzungen ist eine preiswerte Migration zu ATM moeglich. Sie kann mit der Installation von ATM im Backbone beginnen. Vorhandene Endgeraete werden ueber dedizierte Leitungen und leistungsfaehige Cell- beziehungsweise Frame-Switches an den ATM-Backbone angeschlossen. Endgeraete koennen dadurch sofort von den ATM-Vorteilen wie hohe Bandbreiten, Skalierbarkeit hinsichtlich der Netzwerkzugaenge und Backbone-Kapazitaet sowie Multimedia-Faehigkeit aufgrund von Isochronitaet und Zeittransparenz profitieren, ohne dass deren Soft- oder Hardware ausgetauscht werden muesste.

Verschiedene Ansaetze zur Loesung der geschilderten Problematik wurden bereits definiert. So schlaegt die International Telecommunications Union (ITU) beispielsweise in ihrer Spezifikation I.364 fuer den WAN-Bereich vor, die gewuenschten Aufgaben sogenannten Connectionless-Servern zu uebertragen. Auch hat sich bereits die Internet Engineering Task Force (IETF) Gedanken darueber gemacht, wie man das klassische IP ueber ATM transportieren kann, indem man eine neue MAC-Ebene (Media Access Control) fuer ATM definiert (RFC 1577 = Request for Comment), oder wie man durch "Encapsulation methods for carrying network interconnection traffic over AAL 5" verschiedene Protokolle ueber virtuelle ATM-Verbindungen multiplext (RFC 1483).

Waehrend der ITU-Ansatz fuer den lokalen Bereich nicht brauchbar ist, da die ATM-Vorteile Skalierbarkeit und Zeittransparenz verlorengehen und die IETF-Ansaetze nur Teilloesungen liefern, erhalten wir mit der LAN-Emulation des ATM-Forums eine weitgehend umfassende Loesung. Alle Protokolle, ob routbar oder nicht, werden von der LAN-Emulation unterstuetzt. Es wird definiert, wie Ethernet- oder Token-Ring-Stationen mit ATM-Pendants und wie Stationen gleicher Netzzugangstechnik untereinander ueber ATM kommunizieren koennen (Ethernet mit Ethernet oder Token Ring mit Token Ring).

Die LAN-Emulation definiert jedoch nicht, wie Ethernet- mit Token- Ring-Stationen Daten ueber ATM austauschen. Zur Loesung dieser Aufgabe ist weiterhin Bridging- und Routing-Funktionalitaet gefragt - mit dem bekannten Problem, dass aufgrund des Store-and-forward- Verfahrens keine zeittransparente Kommunikation moeglich ist. Ausserdem ist die Behandlung von FDDI-Frames nicht festgelegt. Sie muessen zuerst in Ethernet- oder Token-Ring-Frames gewandelt werden, bevor sie per LAN-Emulation bedient werden koennen (vgl. Abbildung 1).

Die LAN-Emulation wird als Client-Server-Modell definiert und besteht aus den zwei Komponenten LAN-Emulation-Client (LEC) und LAN-Emulation-Service. Die LEC-Funktionalitaet wird entweder in Hardware oder als Teil der Treibersoftware implementiert. Sie befindet sich entweder direkt im ATM-Adapter des Endgeraets oder im LAN/ATM-Switch, von wo aus sie alle Stationen der angeschlossenen Legacy-LANs bedient. Der LEC hat mehrere Funktionen; die wichtigste ist jedoch die Zuordnung von Ziel-MAC- zu Ziel-ATM- Adresse, also die Adressaufloesung.

Der LAN-Emulation-Service zerfaellt in drei Server-Bestandteile:

- den LAN-Emulation-Konfigurations-Server (LECS),

- den LAN-Emulation-Server (LES) und

- den Broadcast- and Unknown-Server (BUS).

Das ATM-Forum hat sich nicht festgelegt, wo die LAN-Emulation- Service-Funktionen zu implementieren sind. Alle drei Funktionen koennen als eine zusammengehoerige Applikation in einem ATM-Switch integriert sein, aber auch verteilt ueber das Netzwerk implementiert werden, so dass der LES vielleicht in einem ATM- Backbone-Switch sitzt, waehrend sich der LECS in einem Server befindet und der BUS in einem lokalen Switch residiert (vgl. Abbildung 2).

Die LAN-Emulation ist ein Service der OSI-Ebene 2 und damit unabhaengig von hoeheren Protokollen. Somit kann sie nicht nur routbare Protokolle wie TCP/IP, IPX, Decnet etc., sondern auch nicht routbare Protokolle wie Netbios, LAT oder SNA bedienen.

Die Server haben die Aufgaben, sowohl Unicasts (Point-to-Point) als auch Broad- und Multicasts (Point-to-Multipoint) zu vermitteln und den LECs bei der Ermittlung der ATM-Zieladressen behilflich zu sein.

Dabei ist der LES die Kommando- und Kontrollzentrale jedes emulierten LANs. Er ist dafuer verantwortlich, MAC-Adressen zu registrieren und aufzuloesen. Der BUS ist zustaendig fuer die Uebertragung aller Broad- und Multicasts. Der LECS wiederum richtet Konfigurationsinfos ueber das ATM-Netzwerk ein und liefert auf Wunsch die LES-Adresse an einen Client, der an einem emulierten LAN teilhaben will.

Die LECs kommunizieren auf zwei Arten mit den Servern. Administrative Aufgaben wie das Auffinden der Adresse eines anderen Clients werden ueber Kontrollverbindungen ausgefuehrt; fuer die Datenuebertragung gibt es gesonderte Datenverbindungen. Die wichtigste Kontrollverbindung wird vom Client zum LES aufgebaut, wenn er einem emulierten LAN beitreten will. Es handelt sich hierbei um eine bidirektionale Verbindung (Point-to-Point), die sich optional um eine unidirektionale Verbindung (Point-to- Multipoint) vom LES zum Client ergaenzen laesst. Datenverbindungen sind bidirektionale virtuelle Kanaele zwischen Clients (Point-to- Point), zwischen Clients und BUS (Point-to-Point) sowie zwischen BUS und Clients (ueblicherweise Point-to-Multipoint). Die Verbindungen lassen sich alle als Permanent Virtual Circuit (PVC), als Switched Virtual Circuit (SVC) oder als Mischung aus beidem realisieren.

Der BUS ist zustaendig fuer das Versenden aller Broad- und Multicasts. Er kann aber waehrend der Zeiten, in denen Client und LES noch mit der Adressaufloesung beschaeftigt sind, auch zum Versenden von Unicasts genutzt werden. Der Client hat somit die Moeglichkeit, schon waehrend der Phase des Verbindungsaufbaus Daten zu senden. Noch bevor alle Handshakes abgehandelt sind und die Datenverbindung steht, ist der Client in der Lage, seine Daten als Unicasts an den BUS zu geben, der diese an jede Station des emulierten LANs broadcastet (vgl. Abbildung 3).

Die Funktionsweise der LAN-Emulation laesst sich in fuenf Schritten erklaeren:

- Initialisierung: Damit ein Client Daten versenden darf, muss er zuerst Mitglied eines emulierten LANs werden. Dazu benoetigt er die Adresse des zustaendigen LES. Die Spezifikation sieht hierfuer mehrere Vorgehensweisen vor. Zuerst versucht der Client, per SNMP ueber das Interim Local Management Interface die Adresse des Configuration Server (LECS) aus einer Tabelle im Switch zu bekommen. Er baut dann kurzzeitig eine Kontrollverbindung zum LECS auf, um die Adresse des LES zu erhalten. Wenn der LECS nicht erreichbar ist, wird in der Switch-Tabelle nach einem anderen LECS oder gleich nach einem eingetragenen LES gesucht.

Hat der Client hiermit keinen Erfolg, verbindet er sich mittels einer sogenannten Well-known ATM address mit dem fuer jedes ATM- Netz gemaess L-UNI spezifizierten LECS. Eine andere Option sieht eine permanente virtuelle Verbindung zum BUS ueber einen "Well- known virtual path identifier/virtual channel identifier (VPI/VCI - 0/17 PVC)" vor. Der Client kann aber auch versuchen, eine frueher konfigurierte Verbindung zu einem LES zu finden oder eine vordefinierte permanente Verbindung zwischen Client und LECS zu nutzen.

- Konfiguration: Der Client teilt dem LECS seine MAC-Adresse, seine ATM-Adresse, den gewuenschten LAN-Typ (zum Beispiel Ethernet) sowie die Maximum Frame Size (MFS) mit und erhaelt im Gegenzug die gewuenschte LES-Adresse sowie die Bestaetigung des LAN-Typs und der Frame-Groesse.

- Eintritt: Nach der Konfiguration baut der LEC eine bidirektionale Kontrollverbindung zum LES auf und sendet ein "Join Request", das seine ATM-Adresse, seinen LAN-Typ, die maximale Frame-Groesse und gegebenenfalls eine Proxy-Indication beinhaltet. Letztere wird dann benoetigt, wenn es sich bei dem Clienten um einen Konzentrator handelt, an den mehrere Endgeraete angeschlossen sind. Weiterhin teilt der LEC mittels Multicast-Adressen mit, welchen Gruppen er angehoert und ob er Daten mit nichtregistrierten Zieladressen erhalten moechte.

Der LES sendet nun entweder ueber die bestehende bidirektionale Kontrollverbindung des LECs oder ueber eine eigene unidirektionale Kontrollverbindung zum LEC ein "Join Response" zurueck, das den Clienten zum emulierten LAN zulaesst oder abweist. Wird der Client abgewiesen, nimmt er den Join Request zurueck, bricht die bidirektionale Verbindung ab und versucht sein Glueck von neuem.

- Registrierung und BUS-Initialisierung: Der Client erkundigt sich beim LES nach der ATM-Adresse zum Versenden von MAC-Broadcasts und erhaelt die BUS-ATM-Adresse. Er baut dann eine unidirektionale Verbindung zum BUS auf, dieser ordnet den Clienten wiederum seiner Point-to-Multipoint-Verbindung zu.

- Datentransfer: Zu diesem Zeitpunkt beginnt der eigentliche Datentransfer zu einem anderen Partner im emulierten LAN. Wenn der LEC Daten verschicken will, prueft er zuerst, ob er die zur MAC- Zieladresse korrespondierende ATM-Zieladresse bereits kennt und ob schon eine virtuelle Verbindung zum Ziel besteht. Dies wird dann der Fall sein, wenn es sich um Verbindungen handelt, die oft genutzt werden, oder wenn haeufig Zeittransparenz benoetigt wird. Ansonsten wird eine Verbindung per Signalisierung nach UNI 3.1 (User Network Interface) aufgebaut.

Kennt der Client die ATM-Zieladresse nicht, sendet er ein LEARP (LAN Emulation Address Resolution Protocol) an den LES. Der ist entweder so intelligent, dass er den LEARP selbst beantworten kann, oder er gibt diesen auf seinen Kontrollverbindungen an alle bekannten Clients weiter.

Waehrend dieser Zeit kann der Client bereits seine Daten ueber den BUS aussenden. Sobald der LES die ATM-Zieladresse liefert, baut der Client eine direkte Datenverbindung zur Zielstation auf und sendet darueber die restlichen Daten. Um sicherzustellen, dass bei solchen Umschaltvorgaengen Unicasts nicht doppelt verschickt, aber auch nicht verloren werden, definiert die LAN-Emulation das sogenannte Flushing.

Vor dem Umschalten auf eine neue Verbindung wird auf der gerade genutzten eine Flush-Nachricht verschickt, die durch einen reservierten Inhalt im LE-Frame-Header gekennzeichnet ist. Der Empfaenger sendet diesen Flush entweder auf einer Kontroll- oder einer Datenverbindung zurueck und gibt somit bekannt, dass er alle Daten vor Aussenden des Flushs erhalten hat. Erst jetzt darf der Sender auf der neuen Verbindung weitere Daten aussenden. Wenn alle Daten uebertragen sind, wird die Verbindung nach einem vorgegebenen Zeitintervall abgebaut.

Falls der LES die gewuenschte Zieladresse nicht findet, gibt der Client die komplette Nachricht an den BUS weiter, der sie wiederum an die uebrigen Clients schickt. In analoger Weise handelt der Client dann, wenn er am ersten Bit der MAC-Adresse erkennt, dass es sich um ein Broad- oder Multicast handelt.

Fazit: Mittels LAN-Emulation sind herkoemmliche Netze via ATM zu verbinden, ohne dass Aenderungen an den vorhandenen Applikationen vorgenommen werden muessten. Die LAN-Emulation-Clients, die im ATM- Adapter oder in den LAN/ATM-Switches installiert sind, stellen diesen Anwendungen die gewohnte MAC-Ebene zur Verfuegung und sorgen damit fuer deren Entkopplung vom konkreten Uebertragungsverfahren.

Damit sich ATM aber optimal nutzen laesst, sind im Laufe der Zeit neue, ATM-spezifische APIs (Application Programming Interfaces) zu definieren, um die Protokolle der Leistungsfaehigkeit von ATM anzupassen. ATM-Adapter der zweiten Generation sollten dann in der Lage sein, herkoemmliche und ATM-konforme Applikationen gleichzeitig zu bedienen.

Die LAN-Emulation ermoeglicht es aber ferner auch, unabhaengig von der physikalischen Netzwerkstruktur, beliebige Endgeraete zu logischen virtuellen Netzen zu vereinen. Sind einzelne Endgeraete als Subnetze vom uebrigen Netz zu trennen, muessen diese nicht laenger physikalisch kombiniert werden.

* Diplominformatiker Klaus Eppele ist Vertriebs- und Marketing- Leiter der HiLAN GmbH in Karlsruhe