ATM wird fuer Hochgeschwindigkeitsnetze als die Technik der Zukunft gehandelt. Viele Anwender koennen oder koennten ihr Netz jedoch auch mit einer der bereits vorhandenen, weniger ambitionierten Techniken aufgabengerecht einrichten. Frank Walther* gibt einen Ueberblick ueber die wichtigsten Verfahren und beschreibt, wie eine schrittweise Migration aussehen kann.
Eine Euphorie grassiert. Alle reden von Hochgeschwindigkeitsnetzen, alle wollen sie, wenige haben sie, und jeder Netzwerkverwalter weiss heutzutage, welche Technik fuer seinen Betrieb zukuenftig die richtige sein wird: ATM. Tatsaechlich stellt sich die Lage etwas differenzierter dar: Noch sind wir nicht in der heilen ATM-Welt angekommen, und noch gibt es andere interessante Techniken, die es zu beachten gilt.
Unbestreitbar steigt der Bedarf an Bandbreite und damit hoeherem Datendurchsatz. Hauptsaechlich der durchschlagende Erfolg von Windows seit Beginn der 90er Jahre sowie die Verlagerung von Datenbankapplikationen vom Host auf PC-gestuetzte Systeme hatten (und haben noch) zur Folge, dass immer mehr Daten ueber die Netzwerke geschickt werden. Zudem breiten sich neue Applikationen aus, allen voran Video-Conferencing, das viele (nicht alle) zeitraubende Gruppen-Meetings im Betrieb und auf Reisen in die Welt ueberfluessig machen kann.
Tatsache ist aber auch: Mit Bandbreiten wird verschwenderisch umgegangen. Und oft wird das "Aufbohren" vorhandener Netzwerke von zehn oder 16 Mbit/s auf 100 Mbit/s auch da empfohlen, wo das Grunduebel nicht im zu langsamen Netzwerk liegt, sondern in einer unsinnigen Applikationsarchitektur.
Wenn in einem Netz ein paar hundert PCs stehen, die alle am fruehen Morgen Windows von einigen wenigen Netware-Servern laden, ist doch klar, dass es in der Leitung einen Stau gibt. Wenn aber zugleich das Aufruesten der "Diskless Workstations" mit Festplatten (auf denen dann lokal Windows zu installieren waere) als zu teuer und arbeitsaufwendig abgelehnt wird (womoeglich noch unter Hinweis darauf, dass man den Anwendern nun nicht die missliebigen Freiheiten zurueckgeben wolle, die man ihnen mit den Diskless Workstations erfolgreich genommen hat), so ist das ein typischer Fall von "Bandbreitenluege".
Ein weiteres Beispiel ist der Unwillen, Geld und Aufwand in neue Software-Architekturen zu stecken. Was soll man davon halten, wenn in einem PC-Netz mit einigen hundert Rechnern noch mit Applikationen gearbeitet wird, die fuer Ein-Platz-Systeme oder kleine Netzwerke entwickelt wurden? Sicher: Es ist oft sehr schwierig oder gar unmoeglich, eine vorhandene Software durch eine andere, bessere zu ersetzen. Das aendert aber nichts daran, dass der Ruf nach mehr Bandbreite scheinheilig ist, wenn die Ursache langsamer Systemgeschwindigkeiten zu Unrecht im Netzwerk gesucht wird und nicht in der Applikation.
Anspruch konkurriert mit realer Bandbreitenluege
Ein letztes Exempel: Der Autor erlebte noch Anfang 1994 bei einem der groessten Handelskonzerne Deutschlands, dass ueber schnellere Netzwerktechnik nachgedacht wurde, waehrend sieben ueber Bruecken getrennte Token-Ring-Segmente jeweils den gesamten (!) Datenverkehr des Hauses zu uebertragen hatten... weil naemlich die Bruecken unsinnig eingestellt worden waren. Datensicherheit? Null. Bandbreitenverlust? Immens. Und das in einem Hause, das fuer sich in Anspruch nimmt, eines der modernsten (es hiess: "das modernste") Rechenzentren des Landes sein eigen zu nennen. Da war sie wieder: die Bandbreitenluege - oder doch zumindest ein massives Missverstaendnis.
Wer kennt sie nicht, die vielen Ethernet-Netzwerke mit TCP/IP, in denen wegen fehlgeplanter IP-Adressstrukturen zu viele Rechner in zu wenigen Segmenten stehen und in denen auch nachtraeglich kein vernuenftiges Subneting gelingen will? Anders ausgedrueckt: Es nutzt nicht immer, eine Autobahn mit einer dritten (Ueberhol-)Spur auszustatten, wenn nicht gleichzeitig der Andrang neuer Verkehrsteilnehmer begrenzt und der Kreuzungsverkehr verbessert wird.
Halten wir uns nicht mit Zweifeln auf! Akzeptieren wir den Wunsch nach "High-speed Networking"! Pluendern wir die Kasse und kaufen wir, was es an Hochgeschwindigkeitstechnik gibt! Und dann...? Es muss gefragt werden, unter welchen Umstaenden Datendurchsaetze von 100 Mbit/s und mehr einen wirtschaftlichen Nutzen erbringen.
Fuer die allermeisten Anwendungen reicht eine Bandbreite von 10 Mbit/s (Standard-Ethernet) oder 16 Mbit/s (Standard-Token-Ring) voellig aus: Im Idealfall kann im 10-Mbit/s-Ethernet je Sekunde etwa 1 MB an Daten aufgenommen werden. Damit stehen viele Rechner (Daten-Bus, Festplatte) immer noch an der Auslastungsgrenze. 100 Mbit/s bis zum Endgeraet scheinen also nur im Ausnahmefall noetig zu sein - bislang jedenfalls.
Wichtiger sind die schnellen Datenstrecken im sogenannten Backbone, dem Netzwerksegment, das die verschiedenen Abteilungsnetze verbindet und in dem die gemeinsamen Ressourcen(Grossrechner, Datenbank-Server etc.) angesiedelt sind. Wenn ein Sternkoppler mehrere Ethernet- und/oder Token-Ring- Segmente vereinigt, ist die Weitergabe der Daten auf das Backbone sicherlich mit 100 Mbit/s und mehr geboten. Hier ist der Nutzen unmittelbar gegeben.
Andererseits zeigt sich in vielen Faellen, dass ein Backbone mit 100 Mbit/s (oder mehr) nicht ausgelastet wird, da beispielsweise fuenf Ethernet-Straenge mit jeweils 10 Mbit/s eben immer weniger als 50 Mbit/s Datenlast auf den Backbone bringen. Da waere sie dann wieder, die Bandbreitenverschwendung.
In solchen Faellen waere es sinnvoll zu pruefen, ob nicht die Zahl der Segmente erhoeht werden koennte oder sollte; in dem beschriebenen Beispiel also auf zehn Ethernet-Segmente mit einer gemeinsamen Datenlast von maximal knapp unter 100 Mbit/s. Die Loesung hiesse im aeussersten Falle: Switching.
Beim Switching-Verfahren werden die Endgeraete ausnahmslos sternfoermig an einen oder mehrere Sternkoppler angeschlossen, der jedem Port die maximale Durchsatzrate garantiert, indem das Datenkabel zwischen Koppler und Endgeraet nur von diesem einen Endgeraet genutzt wird. Anders ausgedrueckt: Der Vorteil liegt darin, dass auf ein
"Shared Medium", ein von allen gemeinsam genutztes Medium, verzichtet wird.
Dieses Shared Medium ist der Systemnachteil von herkoemmlichem Ethernet und Token Ring: Das Medium muss alle anfallenden Datenpakete durch das gesamte Netzwerksegment leiten. Auf diese Weise wird Datenverkehr erzeugt, wo er nicht hingehoert: auf Kabelstrecken, die nicht unmittelbar Sender und Empfaenger verbinden. Eine solche Architektur stellt das "Collapsed Backbone" zur Verfuegung: Alle Endgeraete sind mit separaten Kabeln sternfoermig mit dem/den Sternkoppler(n) verbunden, deren interner Daten-Bus nunmehr das Backbone darstellt. Die Sternkoppler untereinander werden dann mit 100 Mbit/s Datendurchsatz verbunden.
Ein Datenpaket, das ueber das Switching von Sternkoppler zu Sternkoppler vom Absender zum Empfaenger weitergeleitet wird, durchlaeuft nur die unbedingt notwenigen Teilstrecken der Verkabelung; alle anderen Leitungen bleiben fuer weitere Uebertragungen frei. Etherswitches (Switches fuer Ethernet bei jeweils 10 Mbit/s auf den angeschlossenen Leitungen) gibt es bereits seit einigen Jahren.
Rascher arbeitet das vermutlich demnaechst voll standardisierte 100BaseVG Anylan (100 Mbit/s), das zunaechst nur als schnelleres Ethernet geplant wurde, nun aber auch dem Token-Ring-Verfahren mit einem 100-Mbit/s-Switching Zukunftsperspektive gibt: Sternkoppler der Anylan-Architektur verstehen sowohl Ethernet- als auch Token- Ring-Frames.
Unveraenderte Frames bei 100BaseVG Anylan
Bei 100BaseVG Anylan bleibt der Frame-Aufbau jeweils unveraendert; veraendert werden physikalische Signalisierung und Zugriffsverfahren (Demand Priority): Wer senden will, fragt beim Hub (dem Sternkoppler) an, ob Bandbreite frei ist. Der Hub gibt die Leitung frei, sobald er Vermittlungskapazitaet zur Verfuegung hat. Anfragen gleicher Prioritaet werden vom Hub nacheinander abgearbeitet; Anfragen hoeherer Prioritaet haben immer Vorrang. Damit sollen zeitkritische Netzwerkapplikationen bedient werden. Allerdings muss die Zahl bevorrechtigter Stationen kontrolliert und gegebenenfalls begrenzt werden.
Noch schneller arbeitet ATM
(Asynchronous Transfer Mode): Zunaechst mit 100 bis 155 Mbit/s; spaeter mit 622 Mbit/s. Dieses Verfahren fusst ebenfalls auf dem Switching-Konzept. Der entscheidende Unterschied zu den bisher genannten Techniken besteht darin, dass auf veraenderliche Frame- Laengen verzichtet wird. Statt dessen wird mit gleichbleibend langen Zellen (cells) operiert. Auf die interne Arbeitsweise von ATM soll hier nicht naeher eingegangen werden.
Eine starke Einschraenkung des Nutzens von Switching-Techniken muss jedoch beruecksichtigt werden: Wenn alle Datenstroeme auf nur einem Segment, zum Beispiel auf nur einem Server, zusammenlaufen, ergibt Switching wenig Sinn: Wozu erst den Datenverkehr separieren, um ihn schliesslich doch wieder in einem Nadeloehr zusammenzufuehren? Switching lohnt sich nur dann (und genau dann), wenn sich der Datenverkehr auf mehrere (besser: viele) Destinationen verteilt. Im besten Fall kann der Gesamt-Datendurchsatz auf ein Vielfaches dessen gesteigert werden, was bei den Teilsegmenten moeglich ist. Beispiel: Bei Ethernet mit 10 Mbit/s auf den Teilsegmenten kann ein Systemdurchsatz von insgesamt 20 bis ueber 100 Mbit/s erreicht werden. Der einzige erforderliche Schritt zur Realisierung ist das Auswechseln der alten Sternkoppler gegen Etherswitches.
Mit zwar 100 Mbit/s, aber ohne Switching arbeitet FDDI. Es ist die einzige, zur Zeit (fast) voll standardisierte LAN-Technik im Hochgeschwindigkeitsbereich; aber es traegt denselben Systemfehler in sich wie der herkoemmliche Token Ring: Das vorhandene Medium muss Frames ueberall hin verbreiten. Dieser Nachteil soll nun mit FDDI II ausgeglichen werden: Die ATM-Zellstruktur soll in einem FDDI- Rahmen nachgebildet werden, der mit acht Kilohertz (Sprach- )Frequenz den Ring umkreist und der in kleine Datenzellen unterteilt ist. Zwei Kommunikationspartner belegen eine oder mehrere Zellen, die fest in jedem FDDI-Rahmen reserviert sind. Auf diese Weise waere FDDI ebenfalls faehig, isochrone Applikationen zu unterstuetzen.
Ein solches FDDI II wiese eine verblueffende Aehnlichkeit zum Metropolitan Area Network (MAN) nach IEEE 802.6 auf, das zur Zeit bundesweit von der Telekom installiert und als Datex-M angeboten wird. Seine Uebertragungstechnik wird als DQDB (Distributed Queue Dual Bus) bezeichnet. Hierbei werden alle Stationen ueber einen Doppel-Bus miteinander verbunden; auf jedem der zwei Bus-Systeme sind - ebenfalls im Acht-Kilohertz-Takt - Rahmen unterwegs, die in Zellen eingeteilt sind, die wiederum fuer verschiedene Verbindungen reserviert sind oder werden koennen.
DQDB arbeitet ebenfalls mit 155 Mbit/s oder 622 Mbit/s. Die hoechste Zugangsgeschwindigkeit, die von der Telekom bei Datex-M angeboten wird, betraegt aber zur Zeit 34 Mbit/s.
Datex-M, das nach dem amerikanischen Vorbild auch als SMDS (Switched Multimegabit Data Service) bezeichnet wird, lohnt sich heute (noch) nicht fuer reine Punkt-zu-Punkt-Verbindungen und nicht auf kurze Entfernungen; bei der Kopplung mehrerer Standorte, die weit entfernt liegen, kann es jedoch Kosten sparen und zudem schneller arbeiten.
Bei Dateiuebertragungen zwischen zwei Anschluessen duerfte ISDN weiterhin die bevorzugte Wahl sein. Mit der Moeglichkeit des Invers-Multiplexing, bei dem mehrere B-Kanaele fuer dieselbe Uebertragung verwendet werden, stellt ISDN eine kostenguenstige und zugleich schnelle Moeglichkeit der Datenuebertragung im Weitverkehrsnetz bereit. Die Uebertragung von 1 MB in ein bis zwei Minuten bei vergleichsweise geringem Aufwand an Technik und Kosten stellt fuer sehr viele Anwendungen eine durchaus angemessene Loesung dar. Ausserdem ist ISDN eine vertraute, standardisierte Technik, deren LAN-Integration fast vollkommen ist.
Schnelle Netzwerke werden zunaechst im lokalen Backbone sowie auf den Weitverkehrsstrecken benoetigt, wenn ISDN nicht ausreicht oder sich nicht rechnet. Am Ende wird die Loesung vermutlich immer ATM heissen. Noch arbeitet ATM befriedigend erst im LAN; im WAN laeuft jetzt gerade der Betriebsversuch der Telekom in einer Pilotvernetzung von Koeln (Bonn), Berlin und Hamburg. Die ueberlegenen Faehigkeiten von ATM (isochrone Dienste, skalierbare Bandbreite) jedoch verkuemmern im Backbone-Einsatz, wo sie (bisher) kaum gebraucht werden. Zudem sind die ATM-Komponenten noch immens teuer. Ein aktuelles Angebot eines deutschen Herstellers sieht fuer die Vernetzung von fuenf Netware-Servern mit einem Backup-Server via ATM einen Preis oberhalb der 100 000-Mark-Grenze vor.
Erst wenn ATM preiswerter wird und entsprechende Applikationen vorhanden sind, entfaltet es seine Faehigkeiten, rechtfertigt es seine Kosten. Allerdings: Steht ATM erst einmal im WAN zur Verfuegung und ist der nahtlose Uebergang vom ATM-LAN zum ATM-WAN gesichert, fuehrt auf die Dauer kein Weg mehr daran vorbei.
Unterschiede zwischen Preis- und Glaubensfrage
Nach Auffassung des Autors sollten zunaechst bei gegebener Ethernet-Struktur soweit wie moeglich die Endgeraete ueber Etherswitches (10 Mbit/s) an die Hubs gefuehrt werden, die dann mit 100 Mbit/s im Backbone verbunden werden sollten. Ob es sich hierbei um FDDI oder 100BaseVG Anylan (oder das technisch unterlegene Fast Ethernet) handeln wird, ist letztlich eine Preis-, aber keine Glaubensfrage: Da beides spaeter vermutlich von ATM abgeloest werden wird, darf ruhig auf den Pfennig geachtet werden. Aehnliches gilt fuer Token Ring: Die einzelnen Ringe, die unter Umstaenden noch verkleinert weiter in kleinere Segmente zu unterteilen sind, werden ebenfalls an einen 100 Mbit/s-Backbone gekoppelt (vgl. zu einer solchen schrittweisen Migration die Abbildungen).
Fuer Ethernet und Token Ring gilt, dass 100BaseVG Anylan den Vorteil bietet, dass die Frames ohne "translation" oder "encapsulation" (wie bei FDDI) uebermittelt werden koennen. Die hauseigene Netzwerkabteilung muss nicht in eine vollstaendig neue Protokollstruktur einsteigen.
Entscheidend ist dagegen die Frage der Verkabelung. Schnelle Netze brauchen gute Kabel: Und da laeuft alles auf Lichtwellenleiter und verdrillte Zweidrahtleiter (Twisted Pair) der Kategorie 5 hinaus. (Ausnahmen bestaetigen die Regel: So arbeitet ATM zum Teil auch mit abweichenden Kabeln wie 75 Ohm Koax.)
Weiterhin ist die raeumliche Struktur entscheidend: Es muss sich um eine Sternverkabelung handeln. Denn nur dedizierte Verbindungen ermoeglichen hohen Datendurchsatz. An der Kabelfrage entscheidet sich die Zukunft eines LANs mehr als an allen anderen Schwierigkeiten.
Meine Empfehlung heisst: Wer Geld uebrig hat und nicht sparen muss, verlegt ueberall dort neue Kabel, wo die falschen Kabel liegen oder wo die richtigen in falscher Anordnung installiert sind (Ethernet- Bus, Token Ring) und steigt auf FDDI, 100BaseVG Anylan oder sogar schon ATM um.
Wer knapp rechnen muss, kann etwa wie folgt vorgehen: Wo die Server und Hosts nicht in klar zugeordneten Abteilungen arbeiten, sondern fuer (mehr oder weniger) alle Endgeraete zur Verfuegung stehen, sollte ein Backbone-Netzwerk eingerichtet werden, wenn das noch nicht der Fall ist. Verwendung faende hier FDDI oder 100BaseVG Anylan. Endgeraete, die bevorzugt bedient werden sollen, werden ueber Switches mit dem Backbone gekoppelt.
Wo die sternfoermige Kabelstruktur noch nicht vorhanden ist, sollte sie (wenn nicht sofort, so doch nach und nach) eingefuehrt werden. Alle Hochgeschwindigkeits-Architekturen arbeiten mit Sterntopologien (letztlich auch FDDI und MAN ueber die entsprechende Zahl an Glasfasern oder Kupferleitungen). Die Sternverkabelung bietet zudem die besten Moeglichkeiten der Ausfallsicherheit und des Netzwerk-Managements.
Der Schritt hin zu den Hochgeschwindigkeitsnetzen bedeutet den endgueltigen Abschied von Bus- und Ring-Strukturen; der Stern hat das Rennen gewonnen.
Wer heute schon mit einer reinen Sterntopologie arbeitet, ist bereits auf der sicheren Seite; hier sind die notwendigen Veraenderungen wenig schmerzhaft und nach und nach zu verwirklichen. Wer dagegen noch ueberwiegend mit Ethernet-Bus- Systemen, falschen Kabeln (womoeglich vollstaendig ohne Lichtwellenleiter) oder einem "tree of rings" im Token Ring arbeitet, muss noch kraeftig rudern, um das feste Land zu erreichen. Und vor allem wird es teuer werden.
Wer heute in ATM investiert, muss teuer bezahlen. Wenn nicht sehr schnell die ATM-Preise fallen, ist zunaechst der Zwischenschritt ueber ein intelligentes Switching von Ethernet und Token Ring zu empfehlen. Der Schritt zu FDDI ist im Backbone unbedenklich, fuer eine grosse Zahl an Endgeraeten aber immer noch zu teuer, wenn man es mit guten Switching-Loesungen vergleicht.u