Kommunikation und Integration verschiedenartiger LANs sind für viele Firmen und Organisationen von größter Bedeutung. Daß diese Aufgabe alles andere als einfach ist, liegt hauptsächlich an der Vielzahl der in der Vermittlungs- und Transportschicht vermuten Protokolle.

Da OSI (Open Systems Interconnection - Kommunikation offener Systeme) noch nicht verfügbar ist, liegt der Schlüssel zu einer unternehmensweiten Verknüpfung von LANs in der Verwirklichung einer Transportprotokoll-Struktur, die die verschiedenen Anwendungs- und Datenkommunikationsformen des Unternehmens unterstützt und alle vorhandenen LANs und WANs umfaßt.

Für den Aufbau einer solchen integrierten Struktur steht eine Fülle von Protokoll-Umwandlungssoftware zur Verfügung. Obwohl damit der Grundstein für den Bau protokollübergreifender Netzwerke gelegt ist, sollten sich Unternehmen außerdem ein möglichst umfassendes Protokoll als Grundlage für die kurz- und langfristige Weiterentwicklung ihrer Netzwerkumgebung aussuchen. Dieses Protokoll sollte mit möglichst vielen Protokolloptionen der Vermittlungs- und Transportschicht zurechtkommen.

In LAN-Umgebungen arbeiten solche Protokolle oberhalb der Bit-Übertragungs- und Sicherungsschichten von IEEE 802.3-Ethernet- und 802.5-Token-Ring-LANs.

Für die meisten Netzwerkverwalter kommen heute keine herstellerspezifischen LAN-Technologien der unteren Ebenen mehr in Frage. Dazu zählt auch Localtalk von Apple, das sich über Jahre hinweg wegen seiner einfachen Installation und Anwendung bei der Vernetzung von Macintosh-Rechnern gut verkaufte. Dieser Vorteil wird durch Produkte wie 10Base-T, die auf neueren Ethernet-Versionen basieren und ebenso anwenderfreundlich sind, inzwischen weitgehend relativiert.

Das bedeutet nicht, daß die Apple-eigene Netzwerkarchitektur Appletalk überholt wäre. Appletalk umfaßt die Protokolle der höheren Ebenen, die früher ausschließlich unter Localtalk liefen. Aufgrund seiner besonders engen Anpassung an Macintosh-Rechner wird es auch in; Zukunft zu den wichtigeren Vermittlungs- und Transportprotokollen zählen.

Noch Inkompatibilitäten in der Steuerungsschicht

Der Einsatz von Appletalk ist allerdings nicht mehr an Localtalk gebunden. Die neueste Appletalk-Version entspricht den IEEE-802-LAN-Normen und kann daher zusammen mit beliebigen anderen Vermittlungs- und Transportschichtprotokollen auf ein und demselben Ethernet- oder Token-Ring-Netzwerk betrieben werden.

Bei der Ende-zu-Ende-Übertragung über Netzwerkbrücken in gemischten Ethernet- und Token-Ring-Umgebungen können zwar kleinere Schwierigkeiten auftreten, die hauptsächlich beim Zugriff auf Datenträger durch Inkompatibilitäten in der Steuerungsschicht. (zum, Beispiel bezüglich Übertragungsblockgröße oder Leitwegsteuerung) entstehen. Derartige Probleme dürften aber bei der Auswahl von Transportschichtprotokollen kaum eine Rolle spielen und führen auch nicht zu einer Beschränkung des Anwenders auf den Einsatz bestimmter Netzwerkbrücken. Eine möglichst effektive Ende-zu-Ende-Datenübertragung kann in solchen Fällen allerdings nur durch sorgfältige Feinabstimmung der in der Protokoll- und Brückenschicht anfallenden Operationen gewährleistet werden.

Protokollfolgen der Vermittlungs- oder Transportschicht stellen keine separaten Netzinstanzen dar, sondern unterstützen Anwendungen wie zum Beispiel Filetransfer, die in diesen Schichten ablaufen. In manchen Fällen werden solche Anwendungen auch als über der Transportschicht liegende Teile der Protokollstruktur behandelt. Zu diesen Protokollkomponenten der höheren Ebenen zählen das Appletalk Filing Protocol, das OSI-spezifische FTAM-Protokoll (File Transfer, Access and Management), das Unix- und TCP/IP (Transmission Control Protocol/Internet Protocol) orientierte FTP (File Transfer Protocol) und das Network File System, ein hochentwickeltes Fileserver-Protokoll der Firma Sun Microsystems.

Unter Umständen läuft eine Vielzahl unterschiedlicher Protokolle und Schnittstellen über eine Protokollfolge der Vermittlungs- oder Transportschicht ab Dies gilt in besonderem Maße für TCP/IP, über das viele modulare Protokollkomponenten der höheren Ebenen wie Telnet, FTP, Simple Mail Transfer Protocol und sogar Simple Network Management Protocol mehr oder weniger unabhängig voneinander operieren können.

Andererseits ist die Integration von Fremdprotokollen in herstellerspezifische Protokollstrukturen wie zum Beispiel APPC (Advanced Program-to-Program Communications) von IBM nur in den seltensten Fällen möglich, da die Anbieter meist nicht bereit sind, ihre Protokollspezifikationen zu veröffentlichen. Dieses Verhalten verdirbt Drittherstellern die Lust an der Entwicklung eigener Module für Protokollschichten oberhalb dieser herstellenspezifischen Transportprotokolle. Deshalb meiden viele Anwender heterogener Netzwerke herstellereigene Protokolle in letzter Zeit haben einige Anbieter herstellerspezifischer Protokolle ihre Strategie überdacht. Dem Vernehmen nach lizenzieren sowohl Apple als auch Novell inzwischen ihre vollständigen Protokollspezifikationen, um eine weitere Verbreitung von Appletalk und Novell IPX (Internetwork Packet Exchange) als vielseitig verwendbare Vermittlungs- und Transportschichtprotokolle zu fördern. IBM und DEC scheinen dagegen noch keine Notwendigkeit einer Öffnung ihrer Protokollstrukturen für Fremdhersteller zu sehen.

Im Gegensatz zu diesen herstellerspezifischen Ansätzen erleichtert die modulare OSI-Schichtstruktur den Zugang zur Transportschicht. Tatsächlich wird OSI wohl vorwiegend als reine Vermittlungs- und Transportsicht-Protokollfolge eingesetzt werden-, solange der Markt noch keinen ausreichenden Anreiz für die Entwicklung und weitere Verbreitung vollständiger siebenschichtiger OSI-Implementierungen bietet.

Einige Hersteller, darunter auch AT&T und Syntax, bieten OSI-Transportdienste an, die allerdings momentan noch ausschließlich über eine Netbios (Network Basic 110 System)-Softwareschnittstelle in der Transportschicht ablaufen. Diese Schnittstelle wurde im sogenannten TO-Netbios-Standard normiert.

Die Spreu vom Weizen trennen

Das neue Netware-FTAM-Paket von Novell stellt eine vollständige siebenschichtige OSI-Implementierung dar. Mit dieser Zusatzsoftware kann ein Netware-3.11-Server als Fileserver für alle Systeme eingesetzt werden, die ebenfalls über eine auf FTAM basierende Protokollstruktur verfügen. Dabei handelt es sich nicht um einen Netzkoppler, der konventionellen DOS- oder OS/2-Netware-Clients eine Kommunikation mit OSI-Systemen oder über ein OSI-Netzwerk ermöglicht.

Es gibt viele gute Gründe für Netzwerkverwalter, bei der Vielzahl der auf den LANs ihrer Unternehmen eingesetzten Protokolle die Spreu vom Weizen zu trennen. Einer liegt in den komplexen Problemen, die bei der Leitwegsteuerung und der Netzwerkverwaltung auftreten, wenn diese LANs zu einem unternehmensweiten Netzwerk verknüpft werden sollen.

Die Entscheidung darüber, welche Protokolle beibehalten oder neu eingeführt und welche vermieden oder ausgemustert werden sollten, wird durch die Vielfalt der Wahlmöglichkeiten nicht gerade erleichtert. Im LAN-Bereich ringen derzeit folgende führende Vermittlungs- und Transportprotokolle um die Gunst des Kunden:

- TCP/IP;

- OSI;

- Netbios Extended User Interface (Netbeui), das auch unter dem Namen Netbios/DLC (für Data Link Control) bekannt ist und Netbios-over-02.2-, 1- IPX von Novell, das auf Datagrammen basiert und das normalerweise zusammen mit SPX (Sequenced Packet Exchange), seinem ebenfalls von Novell stammenden kaum gebräuchlichen, verbindungsorientierten Äquivalent, als IPX/SPX bezeichnet wird;

- Decnet, eine DEC-eigene Protokollstruktur - in DEC-Umgebungen ist außerdem das von DEC entwickelte auf LANs beschränkte LAT (Local Area Transport)-Protokoll zur Verbindung von VAX-Rechnern und Terminals weit verbreitet, dessen Funktionen allerdings keine Teilmenge von Decnet darstellen;

- das APPC-Protokoll von IBM, das auch als LU6.2 bekannt ist;

- Appletalk, dessen neueste Version von Apple an den IEEE-802.2-Standard für die logische Übertragungssteuerung auf LANs angepaßt wurde; diese Version wird in zwei Ausführungen angeboten: Tokentalk für Token-Ring- und Ethertalk für Ethernet-Netzwerke. Da zwischen beiden Ausführungen kaum funktionale Unterschiede bestehen, werden sie in diesem Artikel unter dem Begriff Appletalk zusammengefaßt.

Die TCP/IP-Kombination, deren Komponenten meist gemeinsam eingesetzt werden, konnte sich inzwischen eindeutig als populärstes Protokoll für heterogene Netzwerkumgebungen etablieren. Der Speicherbedarf einiger TCP/IP-Implementierungen für DOS-PCs liegt bei nur 30 bis 50 KB, während APPC ungefähr das Zehnfache dieses Speicherplatzes benötigt.

TCP/IP kann auf großen, aus verknüpften LANs und WANs zusammengesetzten Netzwerken laufen und bietet außer Funktionen höherer Schichten auch eine genau definierte Schnittstelle für den Zugang zur Transportschicht. Neben seiner fast universellen Verwendbarkeit in Unix-Systemen und -Anwendungen ermöglichen genormte Schnittstellen zu TCP/IP die problemlose Abwicklung des Datenverkehrs von Netbios- und OS-Anwendungen über und - in eingekapselter Form - innerhalb eines TCP/IP-Netzwerks.

Die Vorteile von TCP/IP sind heute so groß, daß sogar Anbieter von Konkurreuerodukten, darunter IBM und Novell, dazu übergehen, diesen Standard zu unterstützen. Novell integrierte die simultane Unterstützung heterogener Protokolle in die Februar-Ausgabe seiner Netwareergänzungen. Außerdem ist TCP/IP ein integraler Bestandteil der Netware-Version 3.11. Das ladbare Netware-Modul kann der Server nach Bedarf ein- und auslagern, so daß DOS-Clients nun über drei verschiedene Zugriffsmöglichkeiten auf den Netware-Server verfügen:

In einer reinen TCP/IP-Umgebung kann auf PCs Jede handelsübliche TCP/IP-Implementierung für das oder OS/2 gefahren werden. Solche Implementierungen sprechen den Netware-Server als TCP/IP-Host-Rechner an.

Unter dem von Novell für diesen Monat angekündigten. "LAN-Workplace für das 4.0 greifen DOS- und Windows-Clients wie bisher nach dem Novell-IPX-Protokoll auf den Server zu, wobei IPX allerdings für den Transport über das Netzwerk in das TCP/IP-Protokoll eingekapselt wird. Als dritte Möglichkeit steht nach wie vor der direkte Client-Server-Zugriff über IPX zur Verfügung.

IBM war Ende Februar nicht bereit, Auskunft über den Entwicklungsstand ihrer aktuellen Softwareprodukte für heterogene Protokolle zu geben. Erwartungsgemäß setzt IBM TCP/IP als Standard auf ihrem Unix-RISC-System/6000 ein. Außerdem liefert Big Blue ein TCP/IP-Support-Paket für OS/2 aus, das über besonders umfangreiche Leistungsmerkmale verfügt.

TCP/IP unter OS/2 ist allerdings auf IBM-LANs kein Ersatz für das bislang verwendete Netbeui-Protokoll und wirft in der Praxis mehr Fragen auf, als es beantwortet. In Form einer fehlenden Schnittstelle für den Zugriff von Netbios-Anwendungen auf TCP/IP scheint IBM dabei ein wichtiges Bindeglied vergessen zu haben. Die Firma Syntax in Auburn, Washington, beeilte sich jedoch, diese Lücke zu schließen. Ihr Softwarepaket Netbios/2 kostet 120 Dollar und sorgt auf OS/2-Systemen für eine Verbindung zwischen Netbios-Anwendungen und TCP/IP für OS/2 von IBM.

Anfang vom Ende des OS/2 LAN Servers

Wie es scheint, bekämpfen sich im IBM-Produkt-Management die Anhänger unterschiedlicher Protokolle, die sich abwechselnd für TCP/IP, OSI, APPC und jetzt sogar für IPX von Novell stark machen. In den Augen mancher Unternehmensberater läutete die Mitte Februar von IBM gemachte Ankündigung, man werde demnächst als Wiederverkäufer für Netware auftreten, den Anfang vom Ende des IBM-eigenen Netware-Konkurrenten OS/2 LAN Server ein.

In einem von Novell veröffentlichten Dokument heißt es, IBM habe versprochen, die Netzwerkbrücke IBM 8209 LAN Bridge mit einer IPX-Unterstützung zu versehen. Novell hat selbst auch Pläne für eine Netware-Version im SNA-Netz bekanntgegeben, die via APPC und Token-Ring eine Verbindung zwischen Netware-Servern und IBM-Hosts ermöglichen soll. Laut Novell läuft die Version 1.0 von Netware für SNA unter Netware 3.11. Ein Preis steht noch nicht fest.

Ferner wird erwartet, daß Novell DOS-Clients Möglichkeiten verschafft, sowohl auf Netwareals auch auf IBMs OS/2 LAN Server zuzugreifen. Dies soll zunächst verwirklicht werden, in. dem auf dem DOS-Client gleichzeitig die Netware-Client-Shell zur Kommunikation mit dem Netware-Server (über IPX und Token-Ring) und der IBM das LAN-Requestor zur Kommunikation mit dem IBM-Server (über das Netbeui-Protokoll) gefahren werden. Novell legt Wert auf die Feststellung, daß Netbios das einzige LAN-Transportprotokoll für OS/2-Clients ist, das sowohl von IBM als auch von Novell unterstützt wird. Im Lichte der gegenwärtigen Vereinbarungen zwischen IBM und Novell scheint also eine Anbindung von OS/2-Clients an Netware-Server via APPC ausgeschlossen zu sein.

Die Tage von Netbeui scheinen gezählt

Netbeui ist eine um die Kompatibilität zu IEEE-802.2-LANs erweiterte Version der ur(...) Kombination heißt Appletalk Support Package 3.0 und lädt lediglich die Appletalk-Transportprotokolle auf den Server. Laut Novell übernimmt der Netware-Server auf diese Weise praktisch die Aufgabe einer Appletalk. Leitwegsteuerung. Novell deutet außerdem an, daß in nächster Zeit mit dem Erscheinen von Anwendungen zu rechnen ist, die diesen Zugang zu Appletalk über die Transportschicht intensiver nutzen.

Ein seit zwei Jahren bestehendes gemeinsames Entwicklungsvorhaben von DEC und Apple hat bislang noch keine bahnbrechenden Neuerungen im Netzwerkbereich hervorgebracht. Nach den bisher daraus hervorgegangenen Softwareprodukten zu urteilen, scheinen sich Apple und DEC noch nicht darüber verständigt zu haben, ob Macintosh-Rechner nun über Appletalk oder über Decnet kommunizieren sollen.

Die beiden Firmen haben eine Methode entwickelt, nach der der Appletalk-Datenverkehr in gekapselter Form über ein Decnet-WAN abgewickelt wird. Dieses Verfahren wird von DEC und Apple als Appletalk-Tunnel durch Decnet bezeichnet. Dazu muß jedoch an jedem Ende der Decnet-Verbindung, die Appletalk als Tunnel dient, eine VAX stehen - eine Lösung, die weder sonderlich elegant noch ausgesprochen wirtschaftlich ist.

Netzkoppier als potentielles Nadelöhr

Außer den bisher erwähnten Produkten gibt es noch eine weitere Möglichkeit zur Integration heterogener Netzwerke, nämlich die Zusammenschaltung über Netzkoppler. In diesem Fall können verschiedene Teile des Netzwerks mit verschiedenen Protokollen arbeiten, ohne daß das gesamte Netzwerk gleichzeitig mit allen Protokollen zurechtkommen muß. Netzkoppler sind allerdings immer potentielle Nadelöhre. Deshalb muß ihr Einfluß auf den Datendurchsatz und das Antwortverhalten eines Netzes bei der Netzwerkplanung sorgfältig evaluiert werden.

Ein weiteres Problem ergibt sich bei der Netzwerkverwaltung: Es ist stets leichter, ein Netz zu verwalten, bei dem ein bis zwei Transportprotokolle netzwerkweit zum Einsatz kommen, als eine Vielzahl von Teilsegmenten mit jeweils völlig unterschiedlichen Protokollen zu integrieren.

Während viele Firmen und Organisationen noch an ihren Kurz- und langfristigen Protokollstrategien feilen, haben manche schon eingesehen, daß ein sinnvoller Plan offen für spätere Änderungen sein muß. Keine Protokollstrategie kann allen Situationen gerecht werden und beispielsweise ein Dutzend verschiedener Protokolle gleichzeitig unterstützen, qu denen in regelmäßigen Abständen neue hinzukommen. Der Schlüssel zur Verwaltung heterogener Netzwerke liegt zweifellos in einer flexiblen, anpassungsfähigen Struktur.