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.07.1994

Vier Tunneling-Methoden stehen zur Auswahl Appletalk-Workgroups via TCP/IP zu WANs verbinden

Ob Sie ein kleines Buero in Cincinnati mit einem anderen in Seattle verbinden muessen oder Ihre weit voneinander entfernt taetigen Vertriebsleute an ein und dasselbe WAN anbinden moechten, Sie finden die Loesung moeglicherweise vor der eigenen Haustuer: ein TCP/IP-Netzwerk. Um aber Appletalk-LANs ueber ein TCP/IP-Netz hinweg zu verbinden, muessen Sie sich unterirdisch orientieren und einer Methode bedienen, die als Tunneling bekannt ist.

Appletalk und TCP/IP koennen sich ein Ethernet teilen, doch wie PKW und LKW, die gemeinsam eine Autobahn benutzen, kommen sie sich dabei manchmal in die Quere. Tatsaechlich verbannen viele Administratoren Appletalk aus ihren TCP/IP-Netzen. Das wortreiche Sendeprotokoll verschwendet Bandbreite. Ausserdem erschwert es die Administration, wenn noch ein weiteres Protokoll auf dem gleichen Backbone laeuft.

Das Tunneling-Verfahren ermoeglicht es Routern, ueber ein bestehendes TCP/IP-Netz (oder einen Backbone) Pakete von einer Appletalk-Workgroup zu einer anderen zu senden. Beim Appletalk- Tunneling stellen zwei Router, jeweils an einem Ende eines TCP/IP- Netzes plaziert, einen Durchgang her, durch den "fremde" Appletalk-Netzpakete passieren koennen. Dann benutzen die Router diesen Tunnel, so wie sie eine Telefonleitung benutzen wuerden, um zwei raeumlich verteilte Lokationen zu verbinden. Sie verstecken Appletalk-Pakete in TCP/IP-Paketen.

Apple strebt ein einziges Tunneling-Protokoll an

Das TCP/IP-Netz weiss nur so viel ueber Appletalk, wie es wissen muss. Es realisiert lediglich eine TCP/IP-Verbindung zwischen zwei Systemen im Netz, und lenkt "ahnungslos" den versteckten Appletalk-Verkehr weiter, als handele es sich um spezifischen TCP/IP-Verkehr.

In der Theorie stellt sich das Tunneling einfach dar: Man verbindet Appletalk-Router, die den betreffenden Netzen TCP/IP- Tunneling anbieten. Die Praxis ist etwas komplizierter. Tun- neling ist nicht immer die beste Loesung. Waehrend es fuer Appletalk- Benutzer bequem sein mag, stellt es fuer den TCP/IP-Administrator ein Sicherheitsrisiko dar, da er Art und Umfang des Verkehrs, der den Tunnel passiert, nicht kontrollieren kann. Manchmal steht kein TCP/IP-Backbone zur Verfuegung.

Auch wenn Sie Tunneling grundsaetzlich als Ihre Loesung ansehen, muessen Sie sich noch immer fuer ein Tunneling-Verfahren entscheiden. Zwar streben Apple und Router-Anbieter ein einziges Tunneling-Protokoll an, doch muessen Sie einstweilen zwischen vier verschiedenen Methoden waehlen, von denen drei nicht miteinander kompatibel sind.

Cayman Systems fuehrte 1989 Cayman Tunnels ein, heute bekannt als SEDI (Simple Encapsulation of DDP in IP). Da es sich um das erste Tunneling-Protokoll handelte, wurde SEDI allein schon aufgrund der zahlenmaessigen Verbreitung zum De-facto-Standard fuer Appletalk-Tun- neling durch TCP/IP. Ausser Cayman bieten weitere Unternehmen wie Farallon Computing und Compatible Systems Router an, die SEDI verwenden.

Das SEDI-Prinzip ist einfach: Zwei Router treten ueber TCP/IP miteinander in Kontakt. Unter Nutzung der Verbindung als dedizierte Leitung (in ihrer Funktion mit einer Telefonleitung vergleichbar) verfrachten sie die DDP-Pakete von Appletalk in die UDP-Pakete von TCP/IP. Im wesentlichen ist dies alles. Die Kopplung zweier kleiner Appletalk-Netze mittels SEDI erfordert nicht viel Hardware oder Management. Fuer grosse Netze aber ist SEDI ungeeignet.

Bei der Einfuehrung von Appletalk gab es noch nicht die immensen erweiterten Ethernet-LANs von heute. Eines der erklaerten Ziele von Appletalk war die Schnelligkeit beim Identifizieren neuer Ressourcen wie auch beim Erkennen abgetrennter oder anderweitiger dem Netz nicht zur Verfuegung stehender Ressourcen. Das Appletalk Routing Table Maintenance Protocol (RTMP) wird von den Routern dazu benutzt, neue Appletalk-Netze zu finden. Alle zehn Sekunden sendet jeder Appletalk-Router seine gesamte Routing-Tabelle in einem RTMP-Paket.

Meldet sich ein Router nicht mindestens einmal innerhalb von zwanzig Sekunden, nehmen die anderen Router an, dass sein Netz offline ist. Fuer die Benutzer ergibt sich daraus der Vorteil, dass das RTMP schnell neue Netze und Wege entdeckt und Probleme im Netz frueh erkannt werden - gewoehnlich binnen zwanzig Sekunden. Fuer die Manager stabiler Netzwerke erweist sich RTMP jedoch als verschwenderisch, da es im Zehn-Sekunden-Takt rund um die Uhr die gleichen Informationen ausgibt. Dies bedeutet keinen grossen Verkehrs-Overhead fuer ein Appletalk-Netz mit nur zehn Routern. Steigt ihre Zahl jedoch auf 100, wie es in einem Corporate-Netz- Backbone leicht der Fall sein kann, nimmt der RTMP-Verkehr ueber 25 Prozent der Bandbreite des Ethernet-Backbones in Anspruch. Ueberdies verschlingen die RTMP-Pakete Verarbeitungskapazitaeten, so dass fuer die Router nichts mehr bleibt: Sie koennen die Funktion, fuer die sie angeschafft wurden, naemlich TCP/IP-Routing, nicht mehr ausueben.

Nur wenigen war dieses Leistungsproblem aufgefallen (obgleich Apple seit Jahren darauf hingewiesen hatte), bis die weitraeumigen Verbindungen aufkamen. Die schnellsten typischen TCP/IP-WAN- Verbindungen arbeiten mit etwa 15 Prozent der Kapazitaet der 10- Mbit/s-Bandbreite von Ethernet (Typische WAN-Datenraten sind 9,6 Kbit/s, 56 Kbit/s und 1,5 Mbit/s.) Angesichts einer derart beschraenkten Bandbreite ist es nicht sehr sinnvoll, dieselben Routing-Informationen immer wieder zu senden. Das Original- Tunneling von Cayman, SEDI, unternimmt nichts zur Eindaemmung des Routing-Verkehrs. Hier treten AURP, Dr. Pepper und TREDI auf den Plan.

AURP, das Appletalk Update-based Routing Protocol, ist Apples Antwort auf dieses und noch viele weitere Probleme. Ueber einfaches Tunneling und die Reduzierung des Verkehrs hinaus erfuellt AURP auch eine ganze Reihe anderer Funktionen. Es stellt eine breit gefaecherte Loesung fuer die Probleme beim Einrichten enormer Multi- Company-Appletalk-Netze dar, die zwar dem Internet selbst aehneln, aber nicht auf TCP/IP, sondern auf Appletalk basieren. Ausserdem bieten AURP-Router Grundsicherheit, indem sie gezielt Geraete und Netze verstecken.

AURP-Router koennen auch Appletalk-Netze umnumerieren, ein bei der Realisierung unternehmensuebergreifender Netze bedeutendes Feature, das die Verbindung zwischen zwei Appletalk-Netzen ermoeglicht, ohne dass ein Nummernkonflikt zu befuerchten ist. Ebenso sieht AURP eine gesonderte Vorgehensweise fuer eine "Freihandelszone" vor, aufgrund derer zwei oder mehr Unternehmen ausgewaehlte Bereiche ihrer Netze koppeln koennen, ohne die Sicherheit der uebrigen Netzbereiche zu gefaehrden. Apple foerdert auch ein weltweites, AURP-basiertes Appletalk-Netz, um zu demonstrieren, dass Unternehmen mittels AURP schnell und einfach Appletalk-Netze verbinden koennen.

Derzeit wird AURP jedoch nur von Apple und Farallon Computing unterstuetzt. Andere Router-Anbieter kritisieren das Protokoll als zu weitreichend fuer die einfachen Anforderungen der meisten Tunneling-Anwendungen.

Dr. Pepper als Loesung fuer bescheidenere Ansprueche

Als Reaktion auf die Komplexitaet von AURP haben mehrere Hardware- und Softwarefirmen das Appletalk-Network-Forum (ANF) eingerichtet, das sich anfangs fuer eine andere Tunneling-Spezifikation mit dem Namen Dr. Pepper stark machte. Die Ziele von Dr. Pepper sind nicht so weit gesteckt wie die von AURP. Neben dem Tunneling konzentriert sich Dr. Pepper vor allem auf die Verringerung der Zahl von RTMP-Routing-Paketen, die einen TCP/IP-Tunnel zwischen zwei Appletalk-Netzen passieren. In vielen betrieblichen Umgebungen gehen die Anforderungen ueber die von Dr. Pepper gebotenen Grundleistungsmerkmale - "Verkehrsberuhigung" und Sicherheit - nicht hinaus.

Ein mit Dr. Pepper kompatibles Produkt wird lediglich von der Shiva Corporation angeboten. Tunneltalk, die Shiva-Implementierung der Dr. Pepper-Spezifikation, wird von Shivas Fastpath-Routern zur Verfuegung gestellt. Wie die AURP-Router von Apple und Farallon verbindet Fastpath mit Tunneltalk Appletalk-Netze ueber einen TCP/IP-Backbone. Im Gegensatz zu AURP umfasst Tunneltalk keine Netznumerierung oder andere AURP-Features, die speziell zur Unterstuetzung sehr grosser Appletalk-Internets konzipiert sind.

TREDI ist kompatibel zu Cayman Systems. Der aelteste Teilnehmer im Appletalk-Tunneling-Spiel offeriert den Benutzern mit TREDI (Traffic Reduced Encapsulation of DDP in IP) ein zweites Werkzeug zum Graben von Tunnels. TREDI ist rueckwaerts-kompatibel mit SEDI, dem Tunneling-Verfahren, das bereits bei vielen Routern im Einsatz ist. Tritt ein TREDI-Router mit einem SEDI-Router in Verbindung, faellt er zurueck in den SEDI-Betrieb. Soweit das Positive fuer die Besitzer von SEDI-Routern. Als Negativum ist anzumerken, dass mit TREDI ein dritter Ansatz zur Realisierung von Appletalk-Tunneling ohne allzu hohe Verkehrskapazitaet ins Spiel kommt.

Inzwischen bietet Cayman Systems TREDI-kompatible Versionen ihrer Gatorbox- und Gatorstar-Router an.

Demgegenueber bringt Cisco Systems nicht nur fuer Mac-Netze noch ein weiteres und damit viertes, Appletalk-via-TCP/IP-Tunneling- Verfahren namens GRE (Generic Route Encapsulation) zum Einsatz. GRE kann nicht nur Appletalk innerhalb eines TCP/IP-Tunnels verkapseln, sondern darueber hinaus auch viele andere Protokolle, wie zum Beispiel das IPX von Netware. Derzeit wird GRE nur von Cisco verwendet. Doch bildet es aufgrund seiner Vielseitigkeit die Grundlage fuer das Appletalk Least-Common-Denominator-Tunneling- Protocol (ALTP), das vom ANF als endgueltiger Standard angesehen wird. (Zum Zeitpunkt der Drucklegung unterstuetzte kein Router ATLP).

Das Internet als Backbone-Alternative

Die Wahl eines Tunneling-Protokolls ist nur der erste Schritt zur Kopplung von Appletalk-Netzen. Die zweite Aufgabe besteht darin, ein Netz zum "Untertunneln" zu finden. Viele Unternehmen besitzen ein TCP/IP-Hausnetz. Eine praktikable Alternative ist auch das Internet.

Vielleicht sind Sie nicht in der gluecklichen Lage, sich das fuer Sie guenstigste Tunneling-Verfahren aussuchen zu koennen. Wenn alle Ihre installierten Router mit SEDI arbeiten, dann bleibt Ihnen wahrscheinlich nur das bandbreitenfressende Protokoll. Halten Sie Ruecksprache mit Ihrem Backbone-Administrator, bevor Sie SEDI- generierten Verkehr ins Netz laden.

Haben Sie dagegen bei Neuzukaeufen voellig freie Hand oder geht es darum, Router aufzuruesten, die eine andere Routing-Methode als SEDI benutzen, stehen Ihnen drei Moeglichkeiten zur Wahl: Entweder Sie entscheiden sich fuer SEDI, eine bewaehrte, aber verschwenderische Tunneling-Methode, oder Sie waehlen den Apple- Standard mit seinen anderweitigen Vorteilen, oder aber Sie verwenden eines der alternativen rationalisierten Protokolle.

In grossen unternehmensuebergreifenden Netzen wird AURP Anforderungen gerecht, die Dr. Pepper und TREDI nicht erfuellen, doch erfaehrt es noch keine weitreichende Unterstuetzung. Bei einem Bestand zahlreicher alter Router muessen Sie eventuell aufruesten oder neue Router kaufen.

Wenn Sie ausschliesslich am Tunneling interessiert sind und dabei die Auswirkungen auf das Host-Netz moeglichst gering halten moechten, sollten Sie TREDI oder Tunneltalk, das auf Dr. Pepper basierende Shiva-Protokoll, ins Auge fassen.

Falls Sie dagegen nur einige Appletalk-LANs verbinden muessen, die Bandbreite Ihres Netzwerks fuer Sie kein Thema ist oder Sie auf Tunneling nicht unbedingt Wert legen, sondern Ihren Router eher unter anderen Gesichtspunkten auswaehlen moechten, sind diese Protokolle im Grunde insofern gleichermassen geeignet, als sie alle Appletalk-Verkehr in TCP/IP-Tunnels unterstuetzen. Jedes Tunneling- Protokoll funktioniert, solange die Router an beiden Enden des Tunnels das gleiche Protokoll benutzen.

Wenn es nur darum geht, zwei Standorte zu verbinden, ist das Internet keine sehr preisguenstige Option. Vorteilhafter wird es dagegen bei zahlreichen Standorten. Um mit gemieteten Telefonleitungen fuer sechs Standorte ein vermaschtes Netzwerk einzurichten (in dem jede Lokation mit jeder anderen verbunden ist), braucht man 15 Mietleitungen, nicht zu vergessen die grossen Router fuer jeden Standort. Mit dem Internet laesst sich ein solches vermaschtes Netzwerk mit nur sechs Leitungen und kleineren, kostenguenstigeren Routern zum Anschluss der einzelnen Standorte an das Netz realisieren.

Es gibt allerdings Einschraenkungen im geschaeftlichen Austausch. CIX (Commercial Internet Exchange) ist eine Wirtschaftsvereinigung, die kommerzielle Anbieter von Internet- Dienstleistungen zusammenfuehrt. CIX-Mitgliedsnetze koennen uneingeschraenkt Daten ueber den CIX-Backbone versenden. Folglich kann ein Unternehmen, das mit einem der CIX-Mitglieder verbunden ist, seine Internet-Verbindung fuer rein kommerzielle Zwecke nutzen, zum Beispiel zum Tunneling von Appletalk-Netzen, sofern es dabei mit einem anderen CIX-Mitglied kommuniziert. Man kauft die Verbindungszeit von einem CIX-Anbieter und vertraut darauf, dass er den Verkehr nur ueber kommerzielle Leitungen dirigiert.

CIX gehoeren sieben regionale und vier grosse ueberregionale Anbieter von Internet-Zugriffsdiensten sowie kleinere Netze in den USA, Europa und Asien an. CIX ist nicht der einzige kommerzielle Verbindungsweg. Falls Ihr Verkehr auf eine Region begrenzt ist, eignet sich eventuell auch ein regionales Nicht-CIX-Netz in Ihrer Umgebung.

Den Umfang der CIX-Netze erfahren Sie von CIX unter der Telefonnummer 001/303/ 482-2150. In Deutschland bietet unter anderem die Eunet Deutschland GmbH, Dortmund, Telefon: 02 31/972 00, Internet-Zugang.

Vor- und Nachteile des Tunneling

Vorteile

-Tunneling ermoeglicht die allmaehliche Ausbreitung von Appletalk ueber ein Corporate Backbone.

-Es setzt nicht voraus, dass Appletalk auf dem Backbone laeuft.

-Verglichen mit gewoehnlichen Appletalk-WANs, bietet es mehr Sicherheit fuer Appletalk-Workgroups.

-Ueber den weltweiten TCP/IP-Backbone des Internet lassen sich entfernte Lokationen mittels Tunneling und somit ohne groessere Ausgaben fuer Mietleitungen anbinden.

Nachteile

-Eventuell muessen teure Router angeschafft werden, die die Tunneling-Last tragen koennen oder kompatible Tunneling-Methoden verwenden.

-Das Verkapseln und Auspacken der einzelnen Appletalk-Pakete kann die Netzwerkgeschwindigkeit mindern.

-Tunnels stellen fuer TCP/IP-Verwalter ein potentielles Sicherheitsrisiko dar.

-Appletalk-Tunnels beanspruchen die Zeit von Administratoren und muessen darueber hinaus eingerichtet, verwaltet und gewartet werden.