11. Weiterentwicklungen und Perspektiven
Die bei der Implementierung des ISDNLAP gesammelten Erfahrungen eröffnen ein weites Feld von Perspektiven. In erster Linie ist hier die Weiterentwicklung des ISDNLAP zur Unterstützung von Mehrpunkverbindungen zu nennen. Nicht weniger aussichtsreich ist die Integration von LAN-Diensten in einer ISDN-Workstation. Schließlich ist auch eine Portierung des Konzepts zum Beispiel für Novell-Net auf IBM-kompatiblen Rechnern denkbar.
11.1 PluriLAN–AppleTalk über Mehrpunktverbindungen
Zur Zeit wird am Lehrstuhl für Informatik II bereits an einem LAN über Mehrpunktverbindungen gearbeitet. Die Busstruktur eines LAN wird bei Mehrpunktverbindungen dadurch realisiert, daß beim Zeitmultiplexverfahren einer ISPBX alle Knoten auf den gleichen Zeitschlitz zugreifen. Hierdurch ergeben sich die Eigenschaften eines physikalischen Busses (vgl. Abb. 11.1.1). Da somit auch Pakete kollidieren und zerstört werden können, muß der Zugriff auf den Zeitschlitz geregelt werden.
Abb. 11.1.1: Die Busstruktur durch Zugriff auf einen gemeinsamen Zeitschlitz
Mehrpunktverbindungen lassen sich auch für die Paketübertragung in AppleTalk nutzen und bewirken eine wesentliche Vereinfachung der Adressierung des ISDN-AppleTalk[1]. Die Mehrpunktversion des ISDNLAP, das sog. PluriLAP (vgl. Abb. 11.1.2), löst alle Probleme, die bei der Adressierung und dem Betrieb von Brücken auftreten. Auch die Interzonen-Adressierung wird erleichtert. Um AppleTalk über Mehrpunktverbindungen betreiben zu können, werden folgende Änderungen im ISDNLAP notwendig:
v PluriLAP benötigt keine Interruptprozedur (ReceiveCall), die einen Anruf entgegennimmt. Durch eine neue Release des Betriebssystems der Nixdorf 8818 Nebenstellenanlage werden Mehrpunktverbindungen unterstützt. Alle Stationen wählen eine einzige Rufnummer. Nicht eine Gegenstation, wie beim ISDNLAP, sondern die PBX nimmt den Anruf entgegen.
v Die Verbindungssteuerung des ISDNLAP wird überflüssig. Bei der Auswahl von PluriLAP wird eine Verbindung aufgebaut, die für die Dauer der AppleTalk-Sitzung bestehen bleibt.
v Das LAP erhält über die Mehrpunktverbindung das Echo seiner Pakete zurück. Dies muß bei der Implementierung der neuen Sendeprozedur berücksichtigt werden. Auch darf der Transmitter erst unmittelbar vor der Übertragung aktiviert werden, da andernfalls Flags gesendet werden, die die Übertragung der restlichen Stationen stören. Nach dem Senden wird der Transmitter wieder deaktiviert.
v Die dynamische Node-Adressierung kann wie im ursprünglichen ALAP gehandhabt werden. Die ENQ-Pakete werden beim Öffnen des .MPP-Treibers als Broadcast-Pakete an alle Stationen gesendet. Erhält der Knoten ein ACK-Paket zurück, so wird das dem LAP Manager über einen LSetInUse-Call mitgeteilt. Eine eigene Prozedur AcquireAddress erübrigt sich.
v Das LAP muß um einen Algorithmus für die Zugriffskontrolle auf den Zeitschlitz ergänzt werden. Dabei ist es günstig, den RTS/CTS-Handshake beizubehalten, da dadurch eine Protokollkonvertierung in einer späteren Brücke zu AppleTalk entfällt.
v Das Name Binding des ursprünglichen AppleTalk kann beibehalten werden. Alle Zusatzeinrichtungen, wie etwa der NameServer, werden überflüssig, da durch Mehrpunktverbindungen ein kompletter Bus realisiert wird.
v Außer am LAP sind keine weiteren Änderungen an AppleTalk-Protokollen notwendig. Beim Zugriff mehrerer Stationen kann keine Monopolisierung auftreten. Daher müssen die AppleShare-Treiber nicht mehr gepatched werden.
Abb. 11.1.2: Das Icon des PluriLAP im System Folder
Eine erste Version existiert seit August 1989 und wurde von mir in enger Zusammenarbeit mit Herrn Dr. Konrad Froitzheim an der Universität Augsburg entwickelt[2]. Diese Vorversion besitzt zur Zeit noch einen sehr einfachen CSMA-Algorithmus, der jedoch bereits den gleichzeitigen Zugriff mehrerer Stationen auf einen Fileserver erlaubt.
Bisher ist es nur möglich, Mehrpunktverbindungen mit digitalen Nebenstellenanlagen der Firma Nixdorf einzurichten. Im öffentlichen ISDN werden Mehrpunktverbindungen nur eingeschränkt (als Konferenz) verfügbar sein. Aus diesem Grund kann das ISDNLAP zur Zeit noch nicht vollständig durch eine Version für Mehrpunktverbindungen (PluriLAP) ersetzt werden.
11.2 ISDN-AppleTalk in einer ISDN-Workstation
Ein wichtiger Bestandteil der ISDN-Workstation, an welcher zur Zeit am Lehrstuhl gearbeitet wird, sind die LAN-Dienste (vgl. Abb. 2.1.1). Diese Workstation basiert auf einer am Lehrstuhl entwickelten S0-Karte für den NuBus, die den direkten Zugang zu ISDN erlaubt. Über diese Karte wird sowohl der Telefondienst der Workstation als auch die Datenkommunikation abgewickelt.
Um mit dieser Karte Verbindungen aufzubauen, werden über ein D-Kanal-Protokoll Informationspakete ausgetauscht. Neben normalen Telefonverbindungen lassen sich so auch Datenverbindungen herstellen. Dadurch können die X.21-Schnittstellen und X.21-Wählprozeduren entfallen. AppleTalk-Datenpakete werden über B-Kanäle durch ein HDLC-Protokoll übertragen. Die Adressierung wird entweder durch Mehrpunktverbindungen oder über einen NameServer gehandhabt.
Ein erster Prototyp dieser Workstation wurde im Frühjahr 1989 auf der Hannover Messe Industrie vorgestellt. Er enthält eine S0-Karte, die die Digitalisierung und Aufzeichnung von Sprache ermöglicht. Die gegenwärtige Implementierung integriert eine ergonomische Telefonoberfläche zur Handhabung der Leistungsmerkmale eines modernen Komforttelefons. Dadurch wird der Umgang mit den Komfortfunktionen moderner Vermittlungsanlagen erheblich erleichtert und die Akzeptanz der Workstation erhöht.
11.3 Verbesserungen am NameServer
11.3.1 Verwaltungstask im NameServer
Die gegenwärtige Version des NameServers besitzt keine Möglichkeit zu erkennen, wann ein Eintrag im Names Directory oder in der Liste der Node IDs ungültig geworden ist. Wird beispielsweise ein Rechner abgeschaltet, so verbleibt sein Eintrag im NameServer. Das kann dazu führen, daß die aktiven Stationen wiederholt versuchen über den NameServer auf deaktivierte Stationen zuzugreifen und keine Antwort erhalten.
Diese Situation wird vermieden, indem der NameServer, ähnlich wie ein AFPServer, regelmäßig seine Einträge auf Gültigkeit überprüft. Das kann durch eine Task im NameServer geschehen, die periodisch die registrierten Stationen sukzessive anwählt. Wird nach mehrmaligem Versuch eine Station nicht erreicht, so entfernt der NameServer diese aus der Liste mit den Node IDs. Ebenso wird durch das Aussenden von LkUp-Paketen mit den Names Table-Einträgen verfahren. Dadurch bleibt das Names Directory auch nach dem Abschalten von Stationen aktuell.
11.3.2 Erweiterung des NameServers für die Interzonen
Neben dem NBP vertrauen auch das RTMP und das ZIP auf die Broadcast-Fähigkeit des Übertragungsmediums und unterhalten auf dem Netz verteilte Tabellen, wie Weglenkungstabellen und Zone Information Tables. Gegenwärtig werden die Pakete dieser Protokolle zwar an den NameServer geleitet, dort jedoch verworfen.
Zusammen mit dem Bau eines ISDN-AppleTalk-Gateways muß der NameServer um eine Verwaltung dieser Tabellen und um eine Bearbeitung von Anfragen bezüglich des Inhalts dieser Tabellen ergänzt werden. Erst wenn das RTMP und das ZIP über den NameServer betrieben werden kann, ist die Bildung von Zonen möglich, wie wir sie von AppleTalk kennen. Das ISDN-AppleTalk kann dann als eigenständige Zone in einem AppleTalk-Internet bestehen.
11.4 Verbesserungen an der ISDN-AppleTalk-Brücke
Gegenwärtig ist die beschriebene Brücke nur in der Lage, eine Verbindung von seiten des ISDN-AppleTalk zu einem einzelnen Gerät, das über einen AppleBus mit der Brücke verbunden ist, aufzunehmen. Für das Drucken genügt das, auch wenn der Drucker erst durch manuelles Eintragen am NameServer bekannt wird. Werden mehrere Geräte an den AppleTalk-Port der Brücke angeschlossen, so ergeben sich Probleme mit der Adressierung. Da die Brücke die beiden Teilnetze auf der Verbindungsschicht koppelt, aber eine Verbindung nur von seiten des ISDN-AppleTalk aufgebaut werden kann und Kontrollpakete nicht weitergereicht werden, können doppelte Node IDs im ISDN-AppleTalk- und AppleTalk-Teilnetz auftreten. Zudem müssen alle Geräte des AppleTalk-Teilnetzes dem ISDN-AppleTalk durch Eintragung am NameServer bekannt gemacht werden.
Ein erster Schritt zur Verbesserung der Funktionsfähigkeit könnte somit die Ergänzung der Brücke um Algorithmen zur Behandlung von Kontrollpaketen und zur Registrierung von Einträgen der AppleTalk-Seite am NameServer sein. Weitaus sinnvoller erscheint jedoch der Bau eines ISDN-AppleTalk-Gateways, der das LocalTalk- und das ISDN-AppleTalk-Netzwerk als eigenständige Zonen behandelt. Dadurch lassen sich alle Adressierungsprobleme der gegenwärtigen Brücke lösen. Der Bau eines Gateways muß aber mit der Erweiterung des NameServers für das RTMP und das ZIP einhergehen. Unter Umständen läßt sich der ISDN-AppleTalk-Gateway zusammen mit dem NameServer in einer Applikation realisieren.
ISDN-AppleTalk hat Einfluß auf alle zentralen Projekte des Lehrstuhls und kann in vielfältiger Weise weiterentwickelt werden.