Netzkommunikation laeuft teils mit Unix-Systemen ueber TCP/IP, teils erfolgt der Zugang zu Novell-Servern ueber IPX/SPX. Andere Anwendungen greifen via SNA auf IBM-Hosts zu oder verwenden Netbeui, um an einem LAN Manager zu arbeiten. In den Wachstumsprozess fuer die Netze wurden immer mehr Komponenten einbezogen, die zwar neue und bessere Funktionalitaeten brachten, aber auch bisher ungewohnte Anforderungen an die Arbeitsplatz- Rechner stellten.

Was ein LAN bringen sollte

Die Mitarbeiter sollten von ihren Arbeitsplaetzen aus auf alle Ressourcen gleichzeitig zugreifen koennen. Dies erfordert, wenn die Host-Rechner nicht die gleichen Protokolle unterstuetzen, entweder eine Vielzahl von Gateways oder die Unterstuetzung der verschiedenen Protokolle durch die Workstations.

Mit den monolithischen Treibern, die lediglich die Verwendung eines Protokolls auf einem Netzadapter zuliessen, war dies nicht moeglich. Bestenfalls konnte man die Konfiguration aendern und neu booten. Ein Beispiel dafuer ist der Treiber IPX.COM, der fuer jede spezifische Adapterkonfiguration neu gelinkt werden muss und kein weiteres Protokoll neben sich zulaesst.

Die Standards ODI und NDIS

Inzwischen haben sich zwei Standard-Schnittstellen fuer Multiprotokoll-Anwendungen eta-

bliert, die es erlauben, auf einem Adapter mehrere Protokolle zu laden: Das Open Data Link Interface (ODI) und die Network Driver Interface Specification (NDIS). Mittlerweile unterstuetzen fast alle Netzadapter-Hersteller diese Interfaces.

Die grundlegende Idee dieser Multiprotokoll-Treiber ist der modulare Aufbau, mit dem auf einer Workstation die verschiedenen Protokolle geladen werden. Die Treiber sind im unteren Teil hardwarespezifisch und frei konfigurierbar, was Einstellungen wie Interrupt, Memory-Adresse und dergleichen betrifft. Diese Werte werden aus einer Konfigurationsdatei (net.cfg, protocol.ini) gelesen. Zu den oberen Schichten hin bieten die Treiber eine genormte Schnittstelle, auf der sich die benoetigten Protokolle installieren lassen. Die Multiprotokoll-Schnittstellen bringen eine Reihe von Vorteilen:

- Hard- und Software-Einstellungen sind frei konfigurierbar.

- Protokolle koennen bei Bedarf dynamisch geladen und wieder aus dem Speicher entfernt werden.

- Die Schnittstellen liegen offen, daher kann jeder Adapterhersteller ODI- und NDIS-Treiber fuer seine Produkte entwikkeln.

- Jedes Produkt, das auf ODI oder NDIS aufsetzt, wird von einer Vielfalt verschiedenster

Netzadapter unterstuetzt.

- Der Kaeufer eines Adapters kann sich der Funktion seines Adaptertreibers sicher sein.

- Multiprotokoll-Treiber sind nicht auf eine Topologie beschraenkt.

- Multiprotokoll-Treiber sind nicht auf ein bestimmtes Protokoll beschraenkt.

Die ODI-Schnittstelle haben Novell und Apple zusammen entwickelt. Aufgrund der enormen Marktpraesenz von Novells Netware kommt ODI eine besondere Bedeutung zu. Es gibt ODI-Treiber fuer Netware- Server sowie fuer DOS- und OS/2- Workstations.

Der ODI-Treiber heisst Multiple Link Interfaces Driver (MLID). Pro Adapter im Rechner wird ein MLID geladen. Jeder MLID mit Ausnahme der Arcnet-Treiber unterstuetzt mehrere Frame-Typen gleichzeitig. Dies ist notwendig, da zum Beispiel TCP/IP in der Regel in Ethernet II- Frames, IPX dagegen meist auf Ethernet 802.3 transportiert wird. Die Verbindung zwischen MLID und den Protokoll-Stacks uebernimmt der Link Support Layer (LSL). Dieser Dienst hat sowohl Informationen ueber die Netzadapter als auch ueber die darueberliegenden Protokolle und verteilt die ein- und ausgehenden Pakete an die richtige Stelle.

Auf den LSL kann jedes Protokoll gesetzt werden, das den ODI- Spezifikationen entspricht. Inzwischen unterstuetzt ODI die Protokolle IPX/SPX, Appletalk, TCP/IP und OSI (Abbildung 1 verdeutlicht den Aufbau einer ODI-Konfiguration).

Auf den Workstations kann zum Beispiel mit Hilfe von Novells LAN Workplace neben dem Standard IPX/SPX auch TCP/IP und darauf aufsitzend auch noch NFS geladen werden. Eine solche Workstation hat gleichzeitig Zugriff auf alle Novell-Dienste, auf einen Unix- Host oder eine Sun.

Auf dem Novell-Server und dem Multiprotokoll-Router erweisen sich die Faehigkeiten von ODI als segensreich. Sobald mehr als ein Adapter im Server installiert ist, hat man automatisch einen IPX- Router von zum Beispiel Token Ring auf Ethernet. Appletalk, TCP/IP und OSI-Routing koennen bei Bedarf dazugeladen werden. Auf dem Server lassen sich Transportdienste wie NFS oder OSI FTAM einsetzen. Dies ermoeglicht es, von den verschiedensten Systemen aus auf einen Novell-Fileserver zuzugreifen.

NDIS von 3Com und Microsoft

Die NDIS-Spezifikation (vgl. Abbildung 2) haben Microsoft und 3Com 1988 gemeinsam veroeffentlicht. Sie hat sich inzwischen zur wahrscheinlich wichtigsten herstellerunabhaengigen Schnittstelle fuer Multiprotokoll-Umgebungen entwickelt. Unzaehlige Netzapplikationen basieren auf NDIS: Microsofts LAN Manager, die 3Com-Protokollfamilie (TCP/IP, NFS, OSI), Suns PC-NFS, FTP- Produkte, IBMs LAN Support fuer Ethernet, IBMs Extended Services fuer OS/2, IBMs LAN Server, DECs Pathworks und viele andere mehr. Ausserdem beruhen Netz- Management-Applikationen wie Synoptics Lattisnet, HPs Open View oder 3Coms LinkWatch auf NDIS.

Der Netzadapter-Treiber heisst in der NDIS- Nomenklatur Media Access Control (MAC)-Treiber. Er steuert und kontrolliert die Adapterhardware. Der protman.sys, der vor dem MAC-Treiber geladen wird, sorgt fuer die richtige Initialisierung der Protokolle.

NDIS-basierende Protokolle werden auf den MAC-Treiber gebunden. Dies bedeutet, dass die einzelnen Module miteinander zu Protokoll- Stacks verknuepft werden. Waehrend dieses Vorgangs wird die protocol.ini abgearbeitet, eine ASCII-Datei, die alle wichtigen Hard- und Softwareparameter enthaelt. Aenderungen der Konfiguration, sei es an der Adapterhardware oder dem Protokollparameter, erfolgen in dieser Datei. Ein NDIS-basierendes Protokoll kann als Geraetetreiber in der config.sys geladen werden, aber auch als TSR oder Standardapplikation.

Odinsup verbindet die Vorzuege von ODI und NDIS

So vielfaeltig die Moeglichkeiten mit ODI oder NDIS fuer sich auch sind, ist es manchmal doch noetig, die Funktionalitaet von beiden Schnittstellen zusammen nutzen zu koennen. Unter OS/2 gibt es zum Beispiel keinen IPX-Protokoll-Stack fuer NDIS. Moechte man nun auf einer OS/2-Station die IBM-Extended-Services nutzen, die auf NDIS basieren, und zugleich den Zugriff auf Novell-Server via IPX , so kann man auf einen sehr praktischen Treiber zurueckgreifen. Er ermoeglicht es, basierend auf einem ODI-Treiber, neben den ODI- Diensten auch eine NDIS-Schnittstelle zu bilden. Dieser Odinsup- Treiber (vgl. Abbildung 3) wird etwa mit dem Netware-OS/2- Requester geliefert.

Es ist allerdings nicht ganz einfach, ihn zu installieren, da dabei sowohl die net.gfg (ODIals auch die protocol.ini veraendert werden muessen.

Ein aehnliches Problem laesst sich unter DOS einfacher loesen. Besitzer eines Microsoft-LAN-Managers finden in ihrem Diskettensatz auch einen IPX-Protokoll-Stack, der unter NDIS laeuft.

Auf diese Weise laesst sich eine Terminalemulation mit "Reflection" ohne weiteres auf NDIS realisieren, ohne dass man auf den Netware- Zugriff verzichten muss. Dieses Protokoll kann jederzeit bei Bedarf geladen werden. Natuerlich laesst sich dieses Problem auch mit dem Odinsup unter DOS loesen. In diesem Fall wird nicht der NDIS-, sondern der ODI-Treiber geladen und dann der Odinsup initialisiert.

Transparenter Zugriff auf die Netzdienste

Solche Loesungen, so funktional sie sind, haben auch Nachteile. Sie erfordern bei der Installation gute Kenntnisse und sind auch schwieriger zu verwalten, da eine kleine Aenderung in den Konfigurationsdateien schon eine laengere Fehlersuche nach sich ziehen kann.

Ausserdem verbrauchen mehrere Protokolle, die gleichzeitig geladen sind, viel Arbeitsspeicher. Zum Glueck koennen aber die meisten Treiber hochgeladen werden.

Eine gelungene Loesung dieses Problems bietet "Winnet plus" von Cogent. Die NDIS-basierende Applikation ermoeglicht unter Windows den Zugriff auf die verschiedensten Dienste, unabhaengig davon, unter welchem Netz-Betriebssystem sie angeboten werden. Damit ist der problemlose Zugriff zum Beispiel auf IPX, TCP/IP, NFS, Netbios und andere Protokolle gleichzeitig moeglich. Die Verwaltung der Protokolle uebernimmt Windows, fuer den Benutzer ist der Zugriff auf die Netzdienste transparent.

Zusatzfunktionen fuer das Netz-Management

Neben der Protokollvielfalt bieten ODI- und NDIS-Treiber auch Zusatzfunktionen, die vor allem im Netz-Management nutzbringend sind. Es gibt zum Beispiel von 3Com SNMP-Agenten, die auf einer bestehenden NDIS-Workstation integriert werden koennen beziehungsweise Bestandteil eines ODI-Treibers sind. Sie ermoeglichen mit einem Overhead von etwa 2 KB die Verwaltung von einer Standard-SNMP-Management-Station aus und liefern dem Netzverwalter Daten ueber die Konfiguration, Performance- und Fehlerraten der betreffenden Station.

Auf der anderen Seite gibt es sogenannte "promiscous" ODI- Treiber, die es erlauben, auf beliebigen Netzadaptern sowohl normalen Workstation-Betrieb zu fahren als auch Protokollanalyse zu betreiben. Ein Beispiel dafuer ist der "LANalyzer for Netware". Diese Windows-Applikation kann, waehrend gleichzeitig die Verbindung zum Fileserver aufrechterhalten bleibt, Netzinformationen sammeln. Der Analyzer erkennt mehrere Protokolle, bemerkt Fehler, die im Netz auftreten, diagnostiziert die Netzauslastung und fuehrt andere typische Analyzer-Funktionen aus.

*Gerhard Abeska ist Support Engineer bei der Computer 2000 Deutschland GmbH in Muenchen.

Abb. 1: Schematischer Aufbau einer ODI-Konfiguration. Quelle: Computer 2000

Abb. 2: 1988 haben Microsoft und 3Com die NDIS-Spezifikation veroeffentlicht. Quelle: Computer 2000

Abb. 3: Die Vorteile von ODI und NDIS verbindet der Odinsup- Treiber. Quelle: Computer 2000