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/Enkapsulierung und Emulation sind nur erste zaghafte Schritte

Der Weg zum ATM-Netz kann nur ueber das Routing fuehren

Manchmal sieht man den Wald vor lauter Baeumen nicht: Dieses Bild scheint besonders auf das Thema ATM zuzutreffen. Die Entwickler haben lange nicht ueber die Komplexitaet von ATM gesprochen, die Hersteller haben sie gern verschwiegen. Jetzt scheint sich der Blick fuer das gewaltige Vorhaben ATM allmaehlich zu schaerfen. Diejenigen, die sich bewusst oder unbewusst von den ATM-Verlockungen blenden liessen, erkennen jetzt, dass sich diese Technik nicht mit den unteren Netzwerkebenen realisieren laesst und sehr viel an Funktionalitaet zu beherrschen ist, beispielsweise das Routing im ATM-Netz.

Welche immense Definitions- und Entwicklungsarbeit dazu noetig ist, davon kann man im ATM Forum derzeit ein Liedlein singen. Doch selbst wenn das Super-Routing-Protokoll IPNNI vielleicht in etwa vier Jahren als verlaessliche Norm vorliegen sollte, werden laengst nicht alle Entwicklungsluecken im ATM-Netz geschlossen sein. Grund genug, das Thema ATM zunaechst eher vorsichtig anzugehen und sich erst einmal mit der Perspektive des vielzitierten Hoffnungstraegers ATM im traditionellen LAN-Umfeld zu beschaeftigen.

Immerhin haben Normierungsgremien bereits einige Vorarbeit geleistet, um mit traditioneller LAN-Technik wie Ethernet und Token Ring ueber einen ATM-Backbone zu kommunizieren. Die Standards hier: RFC 1483, RFC 1577 und LANE 1.0.

Der RFC 1483, bereits 1993 von der IETF spezifiziert, ermoeglicht es zumindest, alle Protokolle, die auf Ethernet, Token Ring, FDDI oder Datex-M basieren, im Enkapsulationsverfahren ueber das ATM- Netz zu multiplexen. Die Anpassung selbst erfolgt ueber die ATM- Adaptionsschicht AAL5. Zwei Verfahrenswege sind moeglich: mehrere Protokolle ueber eine feste virtuelle Verbindung zu transferieren oder jedem Protokoll einen eigenen virtuellen Kanal einzuraeumen.

Damit durch die erste Verfahrensweise beim Ziel-Router kein Durcheinander zwischen den Protokollen entsteht, wird jedes Protokoll anhand des LLC/ SNAP-Vorspanns, der dem Ebene-3-Paket vorangestellt wird, eindeutig identifiziert. Eine Kennung, die bei der zweiten Variante entfaellt, eben weil jedes Protokoll gesondert ueber eine eigene virtuelle Verbindung transportiert wird.

Die zweite Methode hat vor allem in vermaschten ATM-Netzen mit einer Vielzahl von Protokollen einen Vorteil, weil sie den Konfigurationsaufwand drastisch reduziert.

Es muss nicht mehr - wie bei der ersten Methode - jede Verbindung einzeln zeitaufwendig definiert werden. Voraussetzung fuer den Einsatz der zweiten Methode ist allerdings, dass geschaltete virtuelle Kanaele durch SVC unterstuetzt werden.

Dennoch haben beide Verfahrensweisen auch erhebliche Nachteile: Der zusaetzliche Rahmen bringt auf dem ATM-Backbone eine erhebliche Steuerlast mit sich, und das Ein- und Auspacken der Pakete verzoegert den Durchsatz im Router - dem Mittler in diesem Fall zwischen traditioneller LAN-Welt und dem ATM-Backbone. Natuerlich erschliessen sich dem Anwender mit der kosmetischen Anpassung des LAN-Pakets an die ATM-Transporterfordernisse nicht die eigentlichen Vorteile des zellenorientierten Dienstes wie ATM- spezifische Dienstgueten (Quality of Services). Letztlich wird mit RFC 1483 auch nicht die Zielzuweisung des Pakets im Netz realisiert.

Immerhin hat ebenfalls IETF auf RFC 1483 aufsetzend mit RFC 1577 die Weichen fuer eine Wegfindung im Netz gestellt. Dazu wird mit RFC 1577 - Classical IP and ARP over ATM - das ATM-Netz aus der Netzwerksicht als "ein" IP-Subnetz betrachtet. Ein ARP-Server innerhalb dieses Subnetzes uebernimmt die Umsetzung von einer IP- in eine ATM-Adresse und umgekehrt.

Nur wurden diese Regeln mit einer vollstaendigen Internet- Protokoll-Implementierung ausschliesslich fuer die IP-Protokollwelt spezifiziert. Zudem ist fuer jedes IP-Subnetz ein eigener ARP- Server erforderlich - eine aufwendige Loesung, falls das ATM-Netz in mehrere IP-Subnetze strukturiert werden muss. Die Kommunikation zwischen den Teilnetzen und die Paket-/Zellumwandlung ist wiederum Sache eines ATM-faehigen Router-Systems.

Diese konventionelle Router-Kopplung funktioniert allerdings nur dann, wenn route-faehige Protokolle zum Einsatz kommen. Bei nicht route-faehigen Protokollen und speziell beim Einsatz von Switch- Techniken im lokalen Netz kann nur die Emulation der LAN-MAC- Schicht ueber ATM weiterhelfen. Auf diese Weise koennen dann mittels LAN-Emulation (LANE) Shared-Media-LANs und einzelne Rechner ueber LAN-ATM-Switch-Systeme zu durchsatzstarken Arbeitsgruppen zusammengefasst werden. Die LAN-Pakete werden dazu innerhalb sogenannter LAN-Emulationsdatenpakete ueber die ATM- Adaptionsschicht AAL5 uebertragen. Der Vorteil: Alle LAN- Anwendungen lassen sich ohne Modifikation ueber das ATM-Netz hinweg weiterbetreiben. Der Nachteil: Eigentlich wird das traditionelle LAN lediglich ueber den ATM-Backbone hinweg erweitert.

Eine Kommunikation zwischen emulierten LANs sowie ein Topologiewechsel ist nur mittels Router moeglich. Darueber hinaus erzeugt der Router zwischen den emulierten LANs die Wegetabellen, uebernimmt den Durchsatz der Datenpakete, trennt als Ebene-3-System den Broadcast und separiert ueber seine internen Filter die Datenstroeme, um sie so vor unberechtigten Zugriffen zu schuetzen.

Zwei Verbindungsarten sind moeglich: Entweder wird jedem emulierten LAN eine gesonderte Router-Schnittstelle (Ethernet oder Token Ring) zugewiesen, oder alle emulierten LANs werden ueber virtuelle Kanaele einer Router-ATM-Schnittstelle realisiert. Das Plus der zweiten Loesung: In diesem Fall ist nur ein Interface fuer die komplette LAN-ATM-Installation erforderlich, ueber sie lassen sich bis zu 255 virtuelle Verbindungen realisieren. Der Nachteil: An der einen ATM-Schnittstelle koennen bei erheblichem Inter-LAN- Verkehr enorme Datenmengen auflaufen, wodurch es an dem Router- Interface zu erheblichen Durchsatzverzoegerungen und eventuell zu Datenverlusten kommen kann. Zudem ist diese Verbindungsloesung bis heute nur proprietaer zu bewerkstelligen.

Weder mit RCF 1483, RFC 1577 noch mit der LAN-Emulation erschliessen sich also fuer den Anwender die eigentlichen Vorteile von ATM wie Quality of Services, weil kein natives ATM-Protokoll zum Einsatz kommt. Ausserdem wird mit zusaetzlichem Steuerballast operiert, der den Nettodatenverkehr erheblich reduziert und damit den Geschwindigkeitsvorteil von ATM verringert. Aus diesem Grund denkt man verstaerkt ueber den Einsatz des ATM-Protokolls und eine adaequate Vermittlungstechnik - das Routing - im ATM-Netz nach.

Hersteller wie Cisco Systems planen, die Ebene-3-Funktionalitaet in ihre Switch-Systeme zu integrieren. Konzepte wie Baysis oder Cisco Fusion weisen bereits in diese Richtung, derweil vom ATM Forum fieberhaft an potentiellen Routing-Protokollen fuer ATM gearbeitet wird. Die Palette der Aspiranten reicht von MPOA, ueber das bereits standardisierte IISP bis hin zu PNNI und der mutigen Vision IPNNI.

Zudem hat sich im Markt mittlerweile eines herumgesprochen: Auch in ATM-Netzen wird man kuenftig nicht auf Vorteile der Ebene-3- Technik wie Broadcast-Lasttrennung, ausgefeilte Filtertechnik und flexiblere Netzwerkerweiterung verzichten koennen. Bis der Anwender jedoch einigermassen sicher in die ATM-Kommunikation einsteigen kann, wird wohl noch einige Zeit vergehen. Zu gross sind bisher die Definitionsluecken fuer den Einsatz von Routing im ATM-Netz, und die Herstellerbindung ist aufgrund fehlender Standards zu stark. Zudem werden nicht alle angepriesenen Routing-Mechanismen letztlich zum Ziel fuehren.

Eine Arbeitsgruppe des ATM Forums beschaeftigt sich gerade unter dem Kuerzel MPOA mit Routing im ATM-Netz und damit, wie sich andere Routing-Protokolle (Overlay-Routing) darueber transportieren lassen. MPOA - eine Initiative von Cisco Systems - soll dazu dienen, den Weg zu einem definierten Ziel per Broadcast herauszufinden. Die Frage nach dem Ziel wird per ARP von Router zu Router durch das Netz weitergeleitet - bis zu dem Router, der es kennt. Mit der Aneinanderreihung der einzelnen Hops ist damit auch der Weg zum Ziel bekannt, auf dem nun die Datenpakete versendet werden koennen. Die Weitervermittlung der Daten zwischen den Routern obliegt dann den Switch-Systemen.

Allerdings kann MPOA - es liegt bisher nur als Diskussionspapier vor - kaum der Weisheit letzter Schluss sein. Zum Beispiel ist ein Rerouting - die Schaltung von Ersatzstrecken bei einem Verbindungsausfall - mit MPOA nicht moeglich. Zugangsknoten und Switch-Systeme werden erst gar nicht in den Wegfindungsmechanismus einbezogen. Und als einziger Quality-of-Service-Dienst laesst sich lediglich Bandbreite nach Bedarf fest zuteilen. Andere Dienste wie Constant Bit Rate (CBR), Variable Bitrate (VBR) und Unspecified Bitrate (UBR) - die eigentlichen Servicestaerken von ATM - sind mit MPOA nicht zufriedenstellend realisierbar.

Eine genaue Betrachtung des MPOA-Mechanismus zeigt, wieso: Wie gehabt werden naemlich nur Router in die Wegfindungskette einbezogen, nicht aber die Switch-Systeme. Deshalb fehlen wesentliche Switch-spezifische Parameter wie Zellverlustrate sowie Durchsatzverzoegerung und verfuegbare Bandbreite, die solche Servicequalitaeten auf der Strecke zum Ziel erst garantieren koennten. Zudem kann bei der Kommunikation zwischen Endgeraeten unterschiedlicher Subnetze die zu durchlaufende Router-Kette schnell zur Durchsatzbremse werden.

Grund genug fuer das ATM Forum, sich parallel mit der Definition eines anderen Routing-Protokolls - dem PNNI Phase 1 - auseinanderzusetzen. Genauer betrachtet, verbergen sich hinter PNNI zwei Protokolle:

-ein Signalisierungsprotokoll, das nahezu identisch mit der UNI- 3.0/3.1-Signalisierung ist - es wurde lediglich um einige mit dem Routing-Mechanismus zusammenhaengende Funktionen wie Source-Routing und Alternate-Routing ergaenzt - sowie

-ein Topologie-Protokoll, um Informationen zur Netztopologie ueberhaupt an die Teilnehmer verteilen zu koennen.

Mit PNNI Phase 1 sollen nicht, wie bei MPOA, die Router, sondern die Switch-Systeme in den Wegfindungsprozess einbezogen werden. Damit werden sich dem Anwender erstmals auch Dienstgueten wie CBR und VBR erschliessen. ABR und UBR werden nur in Ansaetzen mit PNNI Phase 1 beruecksichtigt werden. Dazu hat man den Weg des Hop-to- hop-Routing verlassen und sich statt dessen fuer den Mechanismus des Source-Routing entschieden. Fuer paketorientiert arbeitende Router-Systeme im Netz sind weiterhin gesonderte Routing- Protokolle erforderlich.

PNNI ist hierarchisch aufgebaut, um die Wegeauswahl zu bewerkstelligen und Dienstgueten in komplexen ATM-Netzen ueberhaupt garantieren zu koennen. Einzelne Switch-Systeme werden in sogenannte Peer-groups zusammengefasst. Jeder Netzknoten teilt den Nachbarn durch Hello-Pakete seine Identitaet und den Status seiner Verbindungen mit. Jede Peer-group wird durch einen Peer-group- Leader repraesentiert, der mit anderen Peer-group-Leadern Topologieinformationen zu seiner Gruppe in verkuerzter Form austauscht.

Die Definition des Topologie-protokolls hat sich jedoch als aufwendiger erwiesen als erwartet. Mittlerweile geht man davon aus, dass PNNI Phase 1 - entgegen vieler vorschneller Ankuendigungen - erst Mitte dieses Jahres standardisiert sein wird.

Fehlender PNNI-Standard erschwert ATM-Migration

Der fehlende PNNI-Standard ist schon deshalb fuer den Anwender besonders schmerzlich, weil sich nur mit ihm standardkonforme ATM- Netze aus Komponenten vieler Hersteller aufbauen lassen. Zudem birgt auch PNNI Phase 1 fuer den Anwender zumindest in komplexen ATM-Netzen Risiken. Durch die "Unschaerfe" der Topologieinformationen bedingt, die zwischen Peer-group-Leadern ausgetauscht werden, kann der Routing-Prozess mit der Auflage, fuer VBR oder CBR bestimmte Dienstgueten zu gewaehrleisten, ins Leere laufen. Der Wegfindungsmechanismus muss noch einmal - notfalls sogar mit anderen Vorgaben - initiiert werden.

Bis PNNI schliesslich standardisiert ist, soll ein anderes Routing- Protokoll - IISP, auch PNNI Phase 0 genannt - in die Bresche springen. Bei genauer Betrachtung erweist sich IISP, das bereits vom ATM Forum standardisiert wurde, jedoch lediglich als Lueckenbuesser ohne ueberzeugende Funktionalitaet. Weil IISP wie MPOA auf Hop-to-hop-Routing basiert und die Switch-Systeme ebenfalls nicht in den Wegfindungsprozess einbezogen werden, hofft der Anwender vergeblich auf Dienstgueten wie CBR und VBR. Darueber hinaus muessen alle moeglichen Kanalverbindungen im Netz manuell definiert werden - bereits in ATM-Installationen mit nur wenigen Switch-Systemen eine Heidenarbeit. Deshalb duerfte IISP nur in aeusserst begrenzten ATM-Umgebungen Sinn machen.

Vor allem wird IISP nicht kompatibel zum kommenden PNNI-Standard sein, weil lediglich die UNI-3.0/3.1-, nicht aber die NNI- Signalisierung genutzt wird. Nur mit einem spaeteren Upgrade wird also eine Kompatibilitaet zwischen beiden Varianten herzustellen sein. Zudem unterstuetzen weder IISP noch PNNI Phase 1 die UNI-4.0- Schnittstelle. Damit fehlen Faehigkeiten wie Punkt-zu-Multipunkt- Verbindungen, um damit Multicast-Gruppen herauszubilden. Solche Faehigkeiten werden wohl erst mit PNNI Phase 2 in ATM-Netze einkehren. Wann PNNI Phase 2 als Standard vorliegen und welche zusaetzlichen Erweiterungen er bringen wird, steht heute allerdings noch nicht fest.

Kein Grund scheinbar fuer einige Hersteller, bereits mit einem weiteren Schlagwort zu werben. Die Rede ist vom Super-Routing- Protokoll IPNNI, das als Konstante fuer kuenftige ATM-Entwicklungen herausgestellt wird. Optimisten gehen von einer Zeitspanne von zwei Jahren aus, Realisten sehen mindestens vier Jahre ins Land gehen, bis das Super-Routing-Protokoll bis zu den Zugangsknoten verwirklicht ist. Andere halten es noch nicht einmal fuer realisierbar. Ein gewaltiges Vorhaben ist es auf jeden Fall, denn zu schaffen waeren mehr als 100 hierarchische Schichten. In die Ende-zu-Ende-Kommunikation via IPNNI sollen sowohl paketverarbeitende Router als auch ATM-Switch-Systeme einbezogen werden. Gesonderte Routing-Tabellen fuer paketverarbeitende Router- Systeme sollen dann also nicht mehr erforderlich sein. Die aufwendige Verarbeitung muessten Edge-Router uebernehmen - mit den aktuell verfuegbaren Systemen kaum vorstellbar.

In dieser Situation erscheint das Hersteller-"Argument" IPNNI nicht mehr zu sein, als ein blosses Marketing-Versprechen, ohne fuer den Anwender einen verlaesslichen Orientierungsinhalt zu bieten - zu weit ist die Netzwerkrealitaet noch von diesem Super-Protokoll entfernt, und zuviel muss bis dahin noch an Standardisierungsarbeit geleistet werden.

Kurz & buendig

Die Aufregung ist gross: 20 bis 30 Milliarden Mark muessen deutsche Anwenderunternehmen nach Ansicht von Experten fuer die Bereinigung der Datumsfehler in IT-Systemen schon einmal einplanen. Allein auf das Projekt 2000 sollen so viel Kosten entfallen, wie 1993 weltweit fuer IT ausgegeben wurde: 386 Milliarden Dollar. Doch die Konzentration auf den Neujahrstag zu Beginn des naechsten Jahrtausends greift ebenso zu kurz wie die Hochrechnung irgendeiner Milliardensumme ohne vorhergehende Analyse. Was im einzelnen auf den Anwender zukommt und welche Prioritaeten bei der Planung einer Vorsorgestrategie zu bedenken sind, zeigt dieser Beitrag.

*Bernd Steinhoff ist freier Journalist in Wiesbaden.