Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.03.1996 - 

Internetworking/

Emulation: Wie ein ATM-Netz in die Rolle des LANs schluepft

Wer in einem einzigen Satz erklaeren muss, was die ATM-LAN- Emulation (ATM-LE) leistet, koennte folgendes sagen: Das ATM- Netzwerk tut, als sei es ein LAN. Besser gesagt: es emuliert eines, und zwar eines, das per Brueckenfunktion an echte LANs angeschlossen ist, was sich gar nicht so einfach realisieren laesst, da LAN-Protokolle verbindungslos, ATM jedoch verbindungsorientiert arbeitet. Ausserdem sind standardisierte LANs Shared-Media- Verfahren, waehrend ATM auf Punkt-zu-Punkt-Kopplungen beruht. Mit der spezifizierten Brueckenfunktion lassen sich alle hoeheren Protokolle ueber ATM betreiben, routbare und nicht-routbare (Appletalk, APPN, Decnet, DLC, IP, IPX, LAT, LAVC, Netbios OSI etc.). Bei den routbaren Protokollen kann ein emuliertes LAN nur ein einzelnes logisches Subnetz abbilden.

Nun stellt sich die Frage: Wozu der ganze Aufwand? Antwort: der kurzfristige Vorteil ist betraechtlich. Alle normalen LAN- Endgeraete, die ueber einen ATM-Backbone miteinander "reden" sollen, koennen ohne weitere Aenderung wie zuvor betrieben werden und muessen nicht mit einem ATM-Interface sowie ATM-Software ausgeruestet werden. Da die erreichte Kopplung eine Brueckenkopplung ist, bleiben mit ATM-LE jedoch alle Probleme erhalten, die ein brueckengekoppeltes Netzwerk mit sich bringt.

LAN-Emulation erst Anfang 1995 spezifiziert

Der ATM-Dienst LAN-Emulation wurde vom ATM-Forum definiert, die Version 1.0 der Spezifikation fuer die ATM-LAN- Emulation im Februar 1995 ratifiziert. Sofort danach nahm das Technical Committee die Arbeit fuer Version 2.0 in Angriff, die Server- Server-Protokolle fuer die LAN-Emulation bestimmen soll, denn nur so koennen in einem Netzwerk verschiedene Multivendor-LAN- Emulation-Server kompatibel zusammengeschaltet werden. Version 2.0 wurde erst im Januar 1996 verabschiedet, Implementierungen liegen daher maximal fuer Version 1.0 vor (Bay Networks, Cisco und IBM vermutlich im Sommer 1996), nicht jedoch fuer Version 2.0.

Der LAN-Emulationsdienst ermoeglicht LAN-Endgeraeten, entweder ueber ein ATM-Netz miteinander zu kommunizieren oder mit Endgeraeten, die direkt an ATM angebunden sind. Endgeraete im Sinne der LAN- Emulation sind PCs, Workstations und Server, aber auch Hub- Systeme, Bruecken und Router. Grundsaetzlich koennte die LAN- Emulation als B-ISDN-Dienst gemaess ITU-T-Empfehlung I.211 die MAC-, Netzwerk- oder Transportebene emulieren. Die aktuelle Version 1.0 des ATM Forum spezifiziert jedoch nur einen reinen MAC-Dienst.

Ein emuliertes LAN (ELAN) besitzt folgende Charakteristika:

-Es ist ein verbindungsloser Dienst;

-unterstuetzt die Standard-LANs Ethernet v 2.0/IEEE 802.3 und IEEE 802.5 (FDDI bleibt aussen vor);

-bietet Broadcast/Multicast-Unterstuetzung;

-unterstuetzt NDIS (Microsoft, Intel, 3Com), ODI (Novell) und DLPI (Unix International) als adapterunabhaengige LLC-Interfaces fuer die hoeheren Schichten und

-ist vom physikalischen Endsystem-Standort unabhaengig.

Sollen FDDI-Pakete von einem LAN-ATM-Konverter ueber ATM-LE bedient werden, muessen sie erst in Ethernet- oder Token-Ring-Pakete umgeformt werden. Eine Loesung bietet die zusaetzliche Implementierung von FDDI-Ethernet-Translation im LE-Client. FDDI- Token-Ring-Translation ist theoretisch ebenfalls moeglich, eine Implementierung aufgrund der hoeheren Komplexitaet jedoch unattraktiv.

Ein moegliches ATM-Szenario mit verschiedenen Internetworking- Komponenten zeigt nebenstehende Abbildung. Der Server am FDDI-Ring laesst sich nur ueber den FDDI-Ethernet-Switch anbinden, da ATM-LE FDDI nicht direkt unterstuetzt. Analog koennen auch ueber die WAN- Interfaces des Routers nur Ethernet- oder Token-Ring-Frames per LE via ATM-Netz weitergeleitet werden.

In einem Netzwerk mit ATM-Backbone, der verschiedene LAN-Teilnetze miteinander verbindet, werden die Hauptaufgaben der LAN-Emulation deutlich:

-An den Uebergangspunkten zwischen LAN und ATM sind Koppelelemente zu installieren, die eine Umformung der LAN-Pakete in ATM vornehmen. Diese Komponenten werden als LAN-ATM-Konverter bezeichnet und sind in Hub-Einschubmodulen, LAN-Switches, Bruecken oder Routern mit Brueckenfunktionalitaet implementiert.

-An den Koppelpunkten zwischen LANs und ATM-Netzwerk muss eine Bekanntgabe der erreichbaren Stationen erfolgen. Dort laeuft eine Software, die LAN Emulations Client heisst (LEC) und die lokal erreichbaren Adressen bekanntgibt. LEC fuehrt eine Zuordnung der Stationsadressen (MAC-Adressen oder Route- Descriptoren im Token Ring) zu den ATM-Zugangspunkten, als den ATM-Adressen der Koppelelemente, durch.

-Die Zuordnung LAN-Zieladresse-ATM-Adresse wird durch den Aufbau entsprechender Tabellen in einem zentralen Server (LAN Emulation Server= LES) und durch die sogenannte Adress-Resolution erreicht.

-Wurde eine erfolgreiche Zuordnung LAN-Ziel-ATM-Zieladresse durchgefuehrt, laeuft der Datentransfer vom Quell-LAN ueber Konverter (LEC), ATM-Backbone, Konverter (LEC) ins Ziel-LAN. Der Kommunikationsablauf ist in Abbildung 2 dargestellt.

-Es muss einen Mechanismus geben, um Broad-/Multicasts so weiterzuleiten, dass sie alle Stationen erreichen, die zu dem emulierten LAN gehoeren. Hierfuer ist ein weiterer Server, der BUS (Broadcast and unknown Server), zustaendig.

Da ein ELAN eine Kennung respektive einen Namen erhalten kann, ist in einem Netzwerk die Implementierung verschiedener ELANs moeglich, ausserdem koennte ein Endgeraet an mehrere ELANs angebunden sein. Das Forum-Dokument V1.0 spezifiziert jedoch nur die Arbeitsweise eines einzelnen ELANs; es sagt nichts darueber aus, wie ELANs untereinander kom-munizieren koennen oder wie sie parallel in Endsystemen implementiert werden. Untereinander haben diese ELANs nach der Standardspezifikation keine Verbindung. Sie lassen sich nur durch externe Koppelelemente verbinden. Die Protokollebenen und Konvertierungen, die zwischen LAN- und ATM-Geraeten bei ATM-LE erforderlich sind, werden in Abbildung 3 gezeigt.

Ein ELAN funktioniert wie jede moderne Kommunikationssoftware ueber Client-Server-Mechanismen. Der LAN-Typ ist entweder IEEE 802.3/Ethernet v2.0 oder IEEE 802.5 (Token Ring). Es gibt folgende Komponenten:

-LAN Emulation Client (LEC),

-LAN Emulation Configuration Server (LECS),

-LAN Emulation Server (LES) sowie

-Broadcast and unknown Server (BUS).

Ein LE-Client ist hinsichtlich aller ueber ihn angeschlossenen LAN- Systeme fuer den Datentransfer und als Erstinstanz fuer die Adress- Resolution verantwortlich. Jeder LE-Client gehoert zu einem ATM- Endsystem und bedient seinerseits eine Reihe von Benutzern ueber ihre eindeutigen MAC-Adressen. Die LE-Client-Funktion kann in einem Endsystem implementiert sein oder in Koppelelementen (Hub- Systeme mit ATM-Uplink und ATM-LAN-Konverter, Bruecken, Routern mit Brueckenfunktionalitaet).

Ein ELAN implementiert genau einen LE-Service, der durch drei verschiedene Server geleistet wird: den LECS, den LES und den BUS. Der LE-Service kann in einem ATM-Endsystem oder einem ATM-Switch realisiert sein, auf einem physikalischen System oder auf mehrere verteilt. Die Synchronisierung bei Verteilung des LE-Services auf mehrere Maschinen wird jedoch im ATM-LE-Dokument nicht beschrieben und ist Sache der Implementierung.

Der LES ist dafuer verantwortlich, alle Adressen (MAC-Adressen und Route- Descriptoren fuer Token-Ring-Umgebungen), die ihm von LECS bekanntgegeben wurden, zu registrieren und bei Bedarf fuer die Adress-Resolution zu sorgen. Die LE-Server-Funktionen koennen in einem ATM-Koppelelement oder einem ATM-Endsystem implementiert sein. Die Spezifikation laesst auch zu, dass in einem physikalischen System gleichzeitig LE-Client und LE-Service implementiert werden, um Hardwarekosten zu sparen.

Der BUS bearbeitet allen Broadcast- und Multicast-Verkehr, den er von LECS uebermittelt bekommt, das heisst, er leitet diesen Verkehr an alle betroffenen LECs weiter. Die Multicast-Funktion des BUS soll mit der ITU-T-Empfehlung X.6 konsistent sein. Die ATM-Forum- Spezifikation unterstuetzt je ELAN genau einen BUS ueber das Luni- Interface. Implementiert ein Hersteller verteilte oder redundante BUS-Funktionalitaet, so laesst die Spezifikation dies zu, die Implementierung muss aber dafuer sorgen, dass der verteilte und/oder redundante BUS sich den LE-Clients gegenueber in allen Funktionen so verhaelt wie eine einzelne Komponente (Single BUS Server). Werden SVCs eingesetzt, muss der BUS selbst am Prozess der Adress- Resolution teilnehmen, indem er LE-ARPs auf die Broadcast-Adresse (FF-FF-FF-FF-FF-FF) mit seiner ATM-Adresse beantwortet.

Der LECS ermoeglicht die Anbindung einzelner LE-Clients an verschiedene ELANs. Die Anbindung erfolgt, indem der LECS einem LE-Client die ATM-Adresse des LAN Emulation Server bekanntgibt, der das ELAN bedient und an das der LEC angeschlossen werden will.

Die Eingliederung eines LEC und die nachfolgende Kommunikation lassen sich in vier Schritten zusammenfassen.

Initialisierung: Beim Hochfahren muss der LE-Client eine Verbindung zum LECS aufbauen, seine Parameter bekanntgeben und gegebenenfalls anpassen (CONFIGURE). Die verschiedenen Massnahmen, um den Configuration Server zu finden, sind in exakter Reihenfolge festgelegt:

1. Suche der LECS-Adresse ueber ILMI (Interim Local Management Interface): Als erstes wird das Management herangezogen (Interim Local Management Interface). Der LE-Client muss ein ILMI Get oder GetNext absetzen, um die ATM-Adresse des LECS zu erhalten. Scheitert der Versuch, eine UNI-Verbindung zu der erhaltenen Adresse aufzubauen, kann der LE-Client ein Get/GetNext absetzen, um eine weitere LECS-Adresse zu erhalten (was aus Redundanzgruenden wichtig ist, denn auch ein LECS faellt manchmal aus).

2. Schweigt sich das ILMI ueber LECS-Adressen aus oder ist keine Kontrollverbindung zu der erhaltenen ATM-Adresse moeglich, tritt das Konzept "Well-known address" in Kraft. Der LE-Client versucht jetzt, eine Verbindung zu der Adresse X'47007900000000000000000000-00A03E000001-00' (20 Byte, OSI- Format) aufzubauen. 00-A0-3E ist der ATM-Forum-OUI (Organizational Unit Identifier), 000001 wurde vom ATM Forum zusaetzlich festgelegt.

3. Scheitert auch dieser Versuch, gibt es eine letzte Alternative: der "Well-known PVC". Der LE-Client versucht, die Configuration- Direct-VCC-Verbindung ueber den PVC mit VPI=0,VCI=17 (Dezimalwerte) aufzubauen.

Nach dem CONFIGURE muss der LEC den LES um Erlaubnis fragen, ob er sich in dieses ELAN eingliedern darf (JOIN). Er baut eine Kontrollverbindung zum LES auf, registriert dort seine eigene Adresse und ueberprueft, ob der vom LES angebotene LAN-Dienst den eigenen Parametern (LAN-Typ, maximale Frame-Groesse, ELAN-Name) entspricht. Bei erfolgreichem JOIN erhaelt der LE-Client vom LE- Server zusammen mit der positiven JOIN Response eine netzweit eindeutige Kennung (LECID) zugewiesen.

Ausserdem ist eine dauerhafte Verbindung zum BUS erforderlich (BUS CONNECT). Hierfuer sendet der LE-Client einen LE-ARP an die Broadcast-Adresse FF-FF-FF-FF-FF-FF. Als Antwort baut der BUS eine Verbindung zum LEC auf. Bricht die BUS-Verbindung irreparabel ab, muss der LE-Client eine neue Initialisierung durchfuehren.

Registrierung: Die wichtigste Aufgabe des LES ist es, LE-ARP Requests als Anfragen zu bestimmten MAC-Adressen (Uni- casts) oder Route-Descriptoren (Token Ring) mit der ATM-Adresse desjenigen LE- Clients zu beantworten, der das gesuchte Ziel lokal angebunden hat. Das Registrierungsprotokoll definiert ein Verfahren, wie LE- Clients dem LES erreichbare MAC-Adressen oder Route-Descriptoren mitteilen. Ein LE-Client muss entweder alle lokalen Adressen/Descriptoren beim LES registrieren oder sich bei der Initialisierung in der JOIN-Phase als "Proxy" bekanntgeben. Der LES leitet LE-ARPs, die er nicht beantworten kann, an alle LE- Clients weiter, die als Proxy an das ELAN angebunden sind. Ein Proxy ist in der Regel eine Spanning-Tree-Bruecke mit einem ATM- Uplink und einem oder mehreren LAN-Segmenten.

Adress-Resolution: Will eine LAN-Station mit einer anderen ueber den ATM-Backbone kommunizieren, landet das Paket irgendwann beim LAN- ATM-Konverter mit LEC-Funktion, da das LAN ein Shared Medium ist. Kennt der LEC die ATM-Adresse, die in das Ziel-LAN koppelt, nicht, schickt er wie beim guten alten TCP einen LE-ARP Request mit der gesuchten MAC-Zieladresse, der vom LES mit der zugehoerigen ATM- Adresse beantwortet wird. Ueber diesen "ATM-Austrittspunkt" ist das Ziel-LAN beziehungsweise die gesuchte Zielstation erreichbar. Kennt der LES die gesuchte Adresse nicht, leitet er den LE-ARP Request an alle LE-Clients weiter, die Proxy sind. Kommt eine Antwort von einem Proxy zurueck, leitet der LE-Server sie an den LEC weiter, der den urspruenglichen Request geschickt hat. Alternativ dazu kann der LES nach Auswertung der LE-ARP Response auch selbst eine solche an den Client generieren.

Auf keinen Fall darf ein LE-Client an der Adress-Resolution teilnehmen, bevor das JOIN erfolgreich abgeschlossen ist. Dies koennte zu Datenverlust und inkonsistenter Netztopologie fuehren und ist daher von der Spezifikation strikt verboten.

Ein LE-Client fuehrt einen Cache fuer alle gelernten LAN- Zielstationen, in dem die aktiven Adressen (MAC-Adressen, Route- Descriptoren) zusammen mit der zugehoerigen ATM-Zieladresse (Ziel- LEC) gespeichert werden. Was tut ein LEC, dessen Cache voll ist, der aber noch ausstehende LE-ARP Requests hat? Kommt eine Antwort fuer einen offenen LE-ARP Request, muss der LE-Client Speicherplatz dafuer frei machen. Wie, dazu schweigt sich die Spezifikation aus (Moeglichkeiten: zum Beispiel Cache-Erweiterung oder durch Loeschen des aeltesten Eintrags). Nach Ablauf eines Aging Timers (Default=300 sec) wird eine gelernte Adresse geloescht, wenn sie in der Zwischenzeit nicht mehr gesehen wurde. Danach darf der Adresseintrag nicht mehr benutzt werden. Der LEC kann jedoch bei Ablauf des Timers einen LE-ARP Request generieren, um selbstinitiiert zu pruefen, ob die fragliche Adresse noch aktiv ist.

Datentransfer: Wenn alle Kontrollverbindungen stehen, Registrierung und Adress-Resolution abgeschlossen sind, kann der LEC sinnvoll arbeiten und das erste Datenpaket so ueber das ATM- Netz weiterleiten, wie es sich die Erfinder der ATM-LAN-Emulation gedacht haben. Am ersten Bit der MAC-Adresse erkennt er, ob das Frame ein Unicast oder Broadcast/Multicast ist. Entsprechend schickt er es auf die Datenverbindung zum Ziel-LEC oder an den BUS. Fuer Unicast-Verkehr wird zwischen den beiden beteiligten LE- Clients eine bidirektionale Punkt-zu-Punkt-Datenverbindung eingerichtet (Data Direct VCC). Solange diese Verbindung noch nicht besteht, kann ein LEC die Daten ueber den Multicast Send VCC an den BUS schicken, der sie dann mindestens an alle Proxy-Clients oder sogar an alle Clients weitergibt, wenn die Zieladresse nicht registriert ist. Auf diese Weise entsteht im ATM-Netz allerdings Mehrlast im ATM-Netz. Daher ist die Senderate zum BUS fuer Unicast- Verkehr begrenzt (Anzahl Frames = 1-10, Default=1; Sendeintervall = 1-60sec, Default=1).

Broadcast/Multicast-Verkehr wird immer ueber den BUS geleitet. In der Regel sendet ein LE-Client ueber eine Punkt-zu-Punkt-Verbindung an den BUS (Multicast Send VCC), der die Pakete ueber unidirektionale Punkt-zu-Multipunkt-Verbindungen zu allen Clients weiterleitet (Multicast Forward VCC). Der BUS kann auch den Multicast Send VCC benutzen, jedoch nicht beides parallel zu einem LE-Client, um Duplikate zu vermeiden. Normalerweise kann ein LE- Client ueber seine LECID im Paket-Header feststellen, ob ein Frame, das der BUS sendet, vom LE-Client selbst stammt. In diesem Fall wird er es ignorieren.

Pech haben dabei jedoch Spanning-Tree-Bruecken: Sie koennen Pakete nicht eindeutig filtern, da diese ja nicht ihre eigene Adresse enthalten, sondern die einer am LAN-Segment angebundenen Station. Auch bei selbstgenerierten Multicasts, zum Beispiel BPDU-Frames, kann das Paket auf dem Bruecken-Interface A generiert werden (MAC-A) und wird vom BUS an alle anderen Interfaces (MAC-B, MAC-C etc.) weitergereicht. Diese erkennen es nicht als eigengeneriertes Paket und leiten es auf alle anderen Bridge-Ports weiter. Die Spezifikation laesst hier offenbar Luecken.

Das Zoegern vieler auch grosser Anwender, ATM als proprietaere Loesung einzusetzen, ist verstaendlich und berechtigt, solange die bestehenden Probleme noch nicht durch stabile Spezifikationen und eine entsprechende Implementierung geloest sind:

-Der tatsaechliche Mix von Sprache und Daten, das heisst geringer konstanter Bandbreite mit zukuenftigen Mega-Bursts ist noch nicht erprobt.

-Da nur bei SONET/SDH eine feste Taktung zur Zelluebertragung gegeben ist, muessen bei E1/T1, E3/T3 und anderen asynchronen LAN- Uebertragungsarten Bits zur Synchronisation eingefuegt werden, was den Overhead weiter erhoeht.

-Die Signalisierungsprozedur ist nicht einheitlich, da Q.2931 und UNIv3.1 nicht identisch sind.

-Es gibt keinen international normierten Standard zur LAN- Emulation ueber ATM. Die Spezifikation v1.0 des ATM-Forums definiert nur eine absolute Grundfunktionalitaet und laesst eine Reihe von Interpretationsluecken offen.

-Bei ATM-LAN-Emulation muss ein LE-Client Tabellen mit den Adressen aller potentieller Kommunikationspartner fuehren - womit wieder der Status einer voellig flachen Kommunikationshierarchie erreicht ist, aus dem uns die Routing-Technik gluecklich herausgefuehrt hat; ganz abgesehen vom Speicherverbrauch (bei der ATM zugrundeliegenden Any-to-any-Philosophie).

-ATM-LE realisiert "nur" eine Brueckenkopplung, daher bleiben alle Probleme rein brueckengekoppelter Netze auch mit ATM-LE erhalten.

-Routing ueber ATM ist mit Ausnahme von "Classical IP over ARP" nach RFC 1577 (der nur die Aktionen innerhalb eines einzelnen logischen Subnetzes beschreibt) noch nicht spezifiziert, es gibt nur voellig proprietaere Loesungen.

Fazit: Ob die Effizienzsteigerung in der Praxis so hoch ist, dass sie den (selbst)gestellten Anforderungen gerecht wird, muss sich erst noch zeigen. Die Marktakzeptanz schon verfuegbarer Technologien wie FDDI oder in naher Zukunft 100-Mbit/s-Ethernet kann einer erfolgreichen ATM-Einfuehrung bei entsprechend attraktiven Preisen durchaus entgegenwirken. Die Vorteile von ATM liegen klar in der besseren Skalierbarkeit, der Dienstunabhaengigkeit und der Vereinheitlichung der Verfahren fuer LAN- und WAN-Kommunikation. Unternehmen, die planen, in ein ATM- Netzwerk zu investieren, kann die abgedruckte Checkliste einige Hinweise geben.

Checkliste fuer ATM

-Unterstuetzen die Hub-Systeme einen ATM-Uplink, der zu den eingesetzten ATM-Switches kompatibel ist?

-Bietet der Hub-Hersteller eigene Switch-Module fuer sein Hub- System an? Wie sieht es mit OEM-Modulen aus?

-Sind die geplanten Endgeraeteadapter zum Switch voll kompatibel? Unterstuetzen sie LAN-Emulation?

-Unterstuetzen die eingesetzten Router DXI oder UNIv3.0 oder UNIv3.1?

-Wird LAN-Emulation kompatibel zur aktuellen ATM-Forum- Spezifikation unterstuetzt?

-Unterstuetzen die eingesetzten LAN-ATM-Konverter zusaetzlich auch FDDI (Translation-Funktion)?

-Wird fuer alle geplanten ATM-Komponenten SNMP als Management- Protokoll benutzt?

-Gibt es Management-Anwendungen fuer alle geplanten ATM- Komponenten, die sich unter einer gemeinsamen Management-Plattform integrieren lassen? Werden die Komponenten in eine grafische Gesamtdarstellung des Netzwerks integriert?

-Welche Redundanzfunktionen unterstuetzen die ATM-Uplinks und ATM- Switches (Hot Swap, redundante Links, redundante Stromversorgung etc. etc.)?

Kurz & buendig

Ganzseitenuebertragung via ISDN heisst neuerdings das Motto bei der Neuen Pressegesellschaft in Ulm. Das schwaebische Verlagshaus dient gewissermassen als Paradebeispiel dafuer, wie mit Hilfe einer modernen ISDN-Router-Loesung nicht nur der eigene Produktionsprozess optimiert, sondern auch ein vorhandenes Inhouse-System eingebunden werden kann.

*Diplominformatikerin Petra Borowka ist unabhaengige Beraterin fuer Netzwerke in Aachen.