8. Die Adressierung in ISDN-AppleTalk
Mit der Änderung der Netzwerkstruktur muß auch eine Anpassung der Algorithmen zur Adressierung auf dem Netzwerk erfolgen. Ursache hierfür ist die mangelnde Broadcast-Fähigkeit eines leitungsvermittelnden Systems. Einerseits wird auf dem AppleTalk-Bus das Broadcasting zur Adressierung verwendet, andererseits ist in einem leitungsvermittelnden System nur das sukzessive Anwählen einzelner Stationen möglich. Die Adressierung in ISDN-AppleTalk muß daher folgende Aufgaben übernehmen:
v Neue Knoten müssen durch eine dynamische Node-Adressierung eine eindeutige Node ID erhalten. Zwischen den Node IDs und den Rufnummern der Knoten muß ein eindeutiges Mapping gewährleistet sein.
v Die Adressierungsprotokolle in AppleTalk (NBP, RTMP, ZIP) verwenden Broadcast-Pakete zur Verwaltung verteilter Adreßtabellen. Um die Funktionsfähigkeit dieser Protokolle zu gewährleisten, sind ihre Broadcast-Pakete gesondert zu behandeln.
v Allgemeine Broadcast-Pakete von Klienten sind auf dem Netz zu verteilen.
Alternative Ansätze zur Adressierung in ISDN-AppleTalk werden deshalb in den folgenden Abschnitten diskutiert.
8.1 Address Mapping
Kommunizieren Systeme unterschiedlicher Adreßstruktur miteinander, so ist eine Abbildung von den Adressen des einen Systems auf die Adressen des anderen Systems notwendig. Je nach Beschaffenheit und Generierung von Adressen in den jeweiligen Systemen kann dieses Address Mapping auf unterschiedliche Art geschehen.
Der einfachste Fall ist, daß die Transformation von Adressen durch eine eindeutige Abbildungsvorschrift durchgeführt werden kann. Das ist jedoch nur möglich, wenn alle Adressen umsetzbar sind und die Abbildungsvorschrift keine Ausnahmen kennt. Aber selbst wenn diese Bedingungen erfüllt sind, kann eine Umsetzung durch die vielfältigen Möglichkeiten der Kodierung sehr kompliziert sein.
Ist es nicht möglich, eine einfache Abbildungsvorschrift für die unterschiedlichen Adressen zu finden, so muß eine Tabelle angelegt werden, die den Adressierungsunterschied durch eine Relation behebt. Diese Tabelle wird einmal erstellt und ist danach fortlaufend verwendbar. Um den Umfang einer Tabelle zu minimieren, kann eine Abbildungsvorschrift mit einer Tabelle kombiniert werden.
Adreßtabellen (z.B. das öffentliche Telefonbuch) sind meist Änderungen unterworfen, so daß eine ständige oder zumindest periodische Überprüfung (Validierung) notwendig wird. Die Verwaltung einer Adreßtabelle wird in der Kommunikationstechnik von einem Verwaltungsprotokoll übernommen. Die Netzwerkknoten tauschen dazu Kontroll- und Informationspakete aus. Ein Verwaltungsprotokoll erfüllt folgende Aufgaben:
v Prüfen der Tabelleneinträge auf Gültigkeit
v Finden und Hinzufügen neuer Einträge
v Löschen ungültiger Einträge
Ein Beispiel für ein Protokoll, das ein Address Mapping realisiert, ist das AppleTalk Address Resolution Protocol (AARP) oder das Name Binding Protocol. Das AARP dient dazu, die Adressierungsunterschiede in AppleTalk und Ethernet auszugleichen.
Die Abbildung von Netzwerkadressen des AppleTalk auf die Rufnummern eines leitungsvermittelnden Systems kann nicht über eine eindeutige Abbildungsvorschrift geschehen, da sowohl die Rufnummern als auch die Knotenadressen in AppleTalk variabel sind.
8.2 Dynamische Node-Adressierung in ISDN-AppleTalk
Im AppleTalk-Netzwerk besitzt jeder Knoten eine eindeutige Node-Adresse, die durch den in Kapitel 4 beschriebenen Algorithmus beim Öffnen des .MPP vereinbart wird, indem Broadcast-Pakete an alle Stationen gesendet werden. Da in einem leitungsvermittelnden, sternförmigen Netz keine ständige Verbindung zu allen Stationen besteht, kann der Algorithmus, der darauf beruht, daß alle Stationen an der Leitung horchen, nicht in dieser Form übernommen werden. Vielmehr muß eine flexible Methode gefunden werden, eine eindeutige Zuordnung der Node IDs in AppleTalk zu den physikalischen Adressen in einem leitungsvermittelnden System, den Rufnummen, zu realisieren.
8.2.1 Node-Adressierung über ein Telefonbuch
Eine einfache Möglichkeit, ein Mapping zwischen Node ID und Rufnummer zu erhalten, ist die Einrichtung eines Telefonbuches. In einer Tabelle kann jeder Node ID eine Rufnummer zugeordnet werden. Bei Macintosh-Rechnern bietet sich hier die Unterbringung in einer Resource an. Wird ein Paket übertragen, so kann im Telefonbuch nach der Zieladresse gesucht und die zugehörige Rufnummer gewählt werden (Abb. 8.2.1). Die Eindeutigkeit einer Node ID im Netzwerk wird durch eine entsprechende Verwaltung des Telefonbuches gewährleistet.
Abb. 8.2.1: Adressierung über ein lokales Telefonbuch in den Knoten
Für die Verwendung eines Telefonbuches sprechen folgende Punkte:
+ Einfacher Algorithmus zur Suche nach einer Rufnummer.
+ Keine zusätzlichen Verbindungen notwendig.
+ Die Eindeutigkeit der Node ID ist einfach herzustellen.
+ Das Telefonbuch kann als Resource angelegt werden.
Dagegen spricht:
- Das Telefonbuch ist nur schwer zu aktualisieren, da jede Änderung im Netz eine Anpassung des lokalen Telefonbuches zur Folge hat. Die Erfahrung zeigt aber, daß gerade die manuelle Aktualisierung derartiger Tabellen meist vernachlässigt wird.
- Die Node-Adressierung und die Nummernsuche sind nicht mehr automatisiert.
- Für den Anwender ist die Node ID eines Knotens nur schwer zugängig.
- Die Node ID ändert sich dynamisch und jede Änderung muß auch im Telefonbuch erfaßt werden.
8.2.2 Ringartige Suche nach der Rufnummer
Die Idee bei der ringartigen Suche nach einer Node ID und einer Rufnummer ist, daß jede Station nur die eigene und die Rufnummer der im logischen Ring nächsten Station kennt.
Die Eindeutigkeit einer Node ID kann gewährleistet werden, indem das Paket zur Node-Adressierung[1] im Kreis von Station zu Station weitergereicht wird. Besitzt eine Station die gesuchte Node ID, so wird das Suchpaket durch ein Antwortpaket ersetzt, das direkt an die suchende Station gerichtet ist. Andernfalls wird das Suchpaket an die nächste Station weitergereicht (Abb. 8.2.2). Schließlich erhält die initiierende Station am Ende der Kette entweder ihr Suchpaket zurück und weiß somit, daß keine andere Station mit derselben Node ID vorhanden ist, oder sie erhält ein Antwortpaket, welches ihr mitteilt, daß die gesuchte ID schon in Verwendung ist, und startet darauf einen neuen Versuch mit einer anderen Node ID.
Abb. 8.2.2: Die ringartige Suche nach einer Node ID
Die Suche nach einer Rufnummer zu einer Node ID läßt sich ähnlich gestalten. Hier kann ein Paket von Station zu Station gereicht werden. Dieses Paket trifft entweder auf eine Station, die die gesuchte Node ID besitzt und sich dann direkt bei der suchenden Station meldet, oder aber das Paket wandert erfolglos zur Ausgangsstation zurück.
Von dieser Art der dynamischen Node-Adressierung sind verschiedene Ausprägungen denkbar. Allen gemeinsam sind jedoch die folgenden Vor- und Nachteile:
+ Das Prinzip ist flexibler als ein Telefonbuch.
- Die Suche dauert relativ lange, da ein häufiger Verbindungswechsel erforderlich ist.
- Diese Methode verursacht einen starken Verkehr auf den Leitungen.
- Probleme beim Ausfall einer Station.
8.2.3 Adressierung über eine Steuerstation
Dieses Prinzip beruht auf der Idee, alle Adressierungsinformationen, die normalerweise über das Netz verteilt sind, in einer Steuerstation zu sammeln. Dadurch wird die Information in einem leitungsvermittelnden System für eine einzelne Station leichter erreichbar.
8.2.3.1 Mapping von Node ID zu Rufnummer über eine Steuerstation
In AppleTalk basiert die dynamische Node-Adressierung auf der Broadcast-Fähigkeit des AppleTalk-Buses. Broadcast-Pakete werden an eine besondere Broadcast-Adresse ($255) gesendet und können von allen Stationen am Bus empfangen werden. Beim Öffnen des .MPP wird eine Station unter einer Node ID registriert, indem ENQ-Pakete an alle Stationen ($255) gesendet werden. Leitet man nun alle Broadcast-Pakete an eine besondere Station und hält dort zu jeder Node ID die Nummer der anrufenden Station fest, so entsteht ein Verzeichnis, das jeder Node ID im Netz eine Rufnummer zuordnet. Durch die Verwaltung dieser Liste kann sichergestellt werden, daß eine Node ID im Netzwerk eindeutig ist.
Hat eine Station ein Paket an einen Knoten zu übertragen, dessen Rufnummer ihr nicht bekannt ist, so fordert sie zuerst von der Steuerstation die Rufnummer zur Node ID des Knotens an. Wurde zur Node ID eine Rufnummer gefunden, so wird die Station unter der ermittelten Nummer angewählt und das Paket übertragen. Bei dieser Methode gibt es folgende Pro- und Contra-Punkte:
+ Die Methode ist flexibler als ein Telefonbuch und das Verzeichnis immer aktuell.
+ Im Vergleich zur ringartigen Suche ist eine geringere Anzahl von zusätzlichen Verbindungen notwendig.
+ gute Übertragbarkeit der dynamischen Node-Adressierung des AppleTalk.
- zusätzlicher Implementierungsaufwand für Steuerstation und Suchfunktionen.
- Jedem Zugriff auf einen Knoten muß ein Anruf bei der Steuerstation vorausgehen.
- hoher Verwaltungsaufwand in der Steuerstation, um das Verzeichnis zu aktualisieren.
- Die Steuerstation wird zum Schwachpunkt im Netz (Ausfallgefahr).
8.2.3.2 Zugriffsreduzierung durch Zwischenspeichern der Rufnummern
Im Normalfall wird nicht nur ein einzelnes Paket an eine Station übertragen, sondern es findet ein Dialog statt, der aus mehreren Anfrage- und Antwortpaketen besteht. Diesen Umstand berücksichtigt die retardierende objektorientierte Verbindungssteuerung, indem sie eine Verbindung nicht sofort nach der Übertragung eines Paketes abbaut.
Ebenso verhält es sich mit den notwendigen Verbindungen. Es ist sehr wahrscheinlich, daß dieselbe Station mehrmals hintereinander anzuwählen ist oder diese Station zurückruft. Daher kann die Anzahl der notwendigen Anfragen bei der Steuerstation erheblich reduziert werden, indem sich die Kommunikationspartner jeweils die Node ID und die Rufnummer der Gegenseite merken und diese dadurch beim nächsten Anruf nicht mehr bei der Steuerstation erfragen müssen.
Grundsätzlich kommen zwei Methoden in Betracht:
v Mehrere Nummern im Zwischenspeicher zu halten erscheint nicht sinnvoll, da in den meisten Fällen nur eine Station zur selben Zeit angesprochen wird. Außerdem wird dadurch die Verwaltung der Nummern im Zwischenspeicher komplexer und steht in keinem Verhältnis zum Nutzen.
v Das Speichern der letzten Rufnummer genügt, um eine erhebliche Reduzierung der notwendigen Verbindungen zu erreichen, da sich der Verkehr in einem lokalen Netzwerk auf ein oder zwei zentrale Stationen, wie Fileserver oder Drucker, konzentriert. Außerdem ist der zusätzliche Verwaltungsaufwand gering.
8.3 Realisierung der Name Binding-Funktionen
Da Namen für den Anwender besser handhabbar sind als Adressen, verwendet AppleTalk ein Name Binding-Protokoll, um Namen an Socket-Adressen zu binden, auf dem Netzwerk zu suchen und schließlich wieder zu löschen. Dieses Name Binding basiert allerdings sehr stark auf dem Broadcasting von Paketen[2]. Broadcast-Pakete bereiten aber, wie schon mehrmals erwähnt, bei Circuit Switching erhebliche Probleme, da es nicht möglich ist, gleichzeitig Pakete an alle Teilnehmer abzusetzen. Somit muß auch eine adäquate Methode gefunden werden, das Name Binding in einem leitungsvermittelnden System zu realisieren. Eine Strategie für das Name Binding muß darauf ausgelegt sein, möglichst keine Veränderungen am bestehenden NBP vorzunehmen. Infolge werden verschiedene Methoden vorgestellt und kurz diskutiert.
8.3.1 Name Binding über eine lokale Tabelle
Die zunächst einfachste, aber zugleich unflexibelste Methode das Name Binding zu realisieren, ist das lokale Abspeichern aller Names Table-Einträge in einer Datei oder Macintosh-Resource[3]. Jeder Knoten besitzt eine Tabelle mit den auf dem Netzwerk bekannten Namen und den zugehörigen Netzwerkadressen. Registriert eine Station einen neuen Eintrag auf dem Netzwerk, so muß dieser (eventuell manuell) in die lokale Tabelle jeder Station aufgenommen werden, was sich unter Umständen als schwierig erweisen kann[4]. Sucht ein Knoten nach einen Gerät (Namen) im Netzwerk, so wird die Information, ob und wo ein Gerät sich im Netzwerk befindet, der lokalen Tabelle entnommen.
Diese Methode hat vor allem folgende Vor- und Nachteile:
+ Für die Suche und Registrierung sind keine zusätzlichen Verbindungen notwendig.
+ Die Tabelle kann als Macintosh-Resource oder lokale Datei angelegt werden.
- Das Name Binding ist nicht mehr automatisiert. Für die manuelle Registrierung von Namen sind Hilfsprogramme erforderlich.
- Pakete müssen gefiltert oder das Name Binding völlig neu implementiert werden.
- Die Eindeutigkeit der Namen ist nur schwer herzustellen. Ein neuer Name kann zwar mit der lokalen Tabelle abgestimmt werden, jedoch nicht direkt mit den anderen Stationen.
- Dieses Prinzip ist für das dynamische Name Binding viel zu unflexibel, da sich die Einträge ständig ändern können. Periodisch müßte eine aufwendige Aktualisierung der Tabelle stattfinden. Diese Methode kann höchstens bei Geräten verwendet werden, deren Namen und Adressen sich im allgemeinen nicht ändern[5].
8.3.2 Sukzessives Anwählen über ein Telefonbuch
Unter Verwendung des Telefonbuches aus Abschnitt 8.2.1 ist es möglich, bei einem Name LookUp sämtliche, einem Knoten über das Telefonbuch bekannte Stationen anzuwählen und dort nach einem Eintrag zu suchen. Das Broadcasting, das normalerweise gleichzeitig Pakete an alle Stationen im Netzwerk sendet, wird so sequentialisiert (vgl. Abb. 8.3.1).
Abb. 8.3.1: Sukzessives Anwählen über ein Telefonbuch
Dieses Vorgehen hat folgende Vor- und Nachteile:
+ Es ist flexibler als eine lokale Tabelle mit Names Table-Einträgen.
+ Die Wartung eines Telefonbuches ist problemloser als die einer Namenstabelle.
- Eine Suche dauert relativ lange[6], da häufiger Verbindungswechsel erforderlich ist. Das Name Binding wartet aber nur etwa 2 Sekunden[7] auf eine Antwort. Hinzu kommt, daß dabei unter Umständen ein Teilnehmer besetzt ist und nur durch Wahlwiederholung erreicht werden kann. Außerdem sendet das NBP LkUp-Pakete meist mehrmals hintereinander. Eine Änderung des Name Binding-Protokolls wäre also kaum zu vermeiden.
- Sukzessives Anwählen verursacht eine starke Belastung der Leitungen und Stationen. Jeder Teilnehmer muß einzeln angewählt, das Paket übertragen und auf die Antwort gewartet werden. Gerade das ist aber in einem leitungsvermittelnden Netzwerk nur schwer durchführbar.
8.3.3 Ringartige Suche nach einem Names Table-Eintrag
Ähnlich, wie bei der ringartigen Suche nach einer Node ID und einer Rufnummer, kann auch nach einem Names Table-Eintrag gesucht werden. Ein LkUp-Paket zur Suche nach einem Eintrag wird im Kreis von Station zu Station weitergereicht. Besitzt eine Station den gesuchten Names Table-Eintrag, so wird ein Antwortpaket an die suchende Station übertragen und das Suchpaket an die nächste Station weitergegeben. Schließlich erhält die suchende Station am Ende der Kette ihr Paket zurück. Ist bis zu diesem Zeitpunkt kein Antwortpaket eingegangen, so weiß der suchende Knoten, daß der gesuchte Eintrag nicht auf dem Netz vorhanden ist. Diese Methode hat folgende Vor- und Nachteile:
+ Eine ringartige Suche ist flexibler als eine lokale Tabelle mit Namen und Adressen.
+ Ein Telefonbuch mit Node IDs und Rufnummern wird nicht benötigt.
- Eine Suche dauert relativ lange, da ein häufiger Verbindungswechsel erforderlich ist.
- Diese Methode verursacht eine starke Beanspruchung der Leitungen, da ständig Pakete von Station zu Station wandern. Die Last ist jedoch besser über das Netz verteilt.
- Der Ausfall einer Station unterbricht den Ring!
8.3.4 Zentrale Verwaltung des Names Directories
Analog zur dynamischen Node-Adressierung läßt sich auch das Name Binding über eine zentrale Steuerstation abwickeln. Das Name Binding verwendet sowohl zum Registrieren als auch zur Suche nach Einträgen LkUp-Pakete, die an alle Stationen im Netz gerichtet sind (destID $255). Wie alle Broadcast-Pakete werden diese an eine Steuerstation geleitet und dort bearbeitet. Neue Namen in LkUp-Paketen werden in eine Tabelle aufgenommen, bereits vorhandene Namen werden in LkUpReply-Paketen erwidert. Dadurch entsteht in der Steuerstation eine Kopie aller über das Netz verteilten Names Tables, das Names Directory, das die Eindeutigkeit der Namen gewährleistet und auf Anfrage Auskunft über gesuchte Namen gibt.
Folgende Argumente sind abzuwägen:
+ Diese Methode ist flexibler und aktueller als eine lokale Namenstabelle.
+ Es ist nur eine minimale Anzahl von zusätzlichen Verbindungen notwendig.
+ Diese Methode arbeitet nach dem Prinzip des Name Bindings in AppleTalk. Somit ist keine Änderung des Standard-Name Binding-Algorithmus notwendig.
- Es entsteht ein zusätzlicher Implementierungsaufwand für die Steuerstation.
- Um das Verzeichnis in der Steuerstation zu aktualisieren, wird ein hoher Verwaltungsaufwand erforderlich.
- Die Steuerstation wird zum Schwachpunkt im Netz (Ausfallgefahr). Abhilfe kann eine alternative Steuerstation schaffen, die eine Kopie des Names Directories hält und bei Ausfall der Primärstation angewählt wird.
8.4 Die Funktionen des RTMP und des ZIP
Ähnlich wie das Name Binding Protocol (NBP) verwenden auch das Rooting Table Maintenance Protocol (RTMP) und das Zone Information Protocol (ZIP) Broadcast-Pakete zur Verwaltung verteilter Adreßtabellen. Um die Informationen der Weglenkungstabellen und Zone Information Table (ZIT) in einem leitungsvermittelnden Netzwerk bereitzustellen, sind wie beim NameBinding vor allem zwei verschiedene Methoden denkbar:
8.4.1 Manuelle Verwaltung der Interzonen-Tabellen
Eine einfache Methode die Weglenkung zu realisieren, ist das lokale Abspeichern aller Weglenkung- und Zoneninformationen in einer Datei oder Macintosh-Resource. Die Weglenkungstabelle in einer Brücke wird manuell verwaltet. Die Zuordnung von Zonennamen zu Netzwerknummer muß in jedem Knoten vorgegeben sein. Nimmt eine neue Brücke den Dienst im Netzwerk auf, so muß diese (eventuell manuell) in die lokalen Tabellen einer jeden Station aufgenommen werden. Sucht ein Knoten nach einer Brücke im Netzwerk, so wird die Information, ob und wo eine Brücke sich im Netzwerk befindet, einer lokalen Tabelle entnommen. Diese Methode hat vor allem folgende Vor- und Nachteile:
+ Es sind keine Broadcast-Pakete und zusätzlichen Verbindungen zur Verwaltung der Tabellen notwendig.
+ Normale Knoten (keine Brücken) verwalten keine Weglenkungstabellen. Sie müssen nur die Nummer des Netzwerkes, in dem sie sich befinden, und die Node-Adresse irgendeiner Brücke im Netzwerk kennen.
+ Intenet-Zonen sind über Brücken normalerweise fest installiert und nur selten Änderungen unterworfen.
- Die Verwaltung der Weglenkungstabellen und der ZIT ist nicht mehr automatisiert.
- Pakete müssen gefiltert oder das RTMP und das ZIP völlig neu implementiert werden.
- Die Aktualität der Weglenkungs- und Zoneninformation ist nur schwer sicherzustellen. Eine neue Brücke oder Zone wird manuell in die Tabellen aufgenommen.
8.4.2 Verwaltung in einer Steuerstation
Wie die Names Table des NBP lassen sich auch Weglenkungstabellen und Zone Information Tables in einer zentralen Steuerstation verwalten. Das RTMP verteilt sowohl bei der Registrierung als auch bei der Suche nach Brücken Broadcast-Pakete (destID $255) an alle Stationen auf dem Netz. Das ZIP sucht mit Query-Paketen nach der Netzwerknummer zu einem Zonennamen. Wie die LkUp-Pakete des NBP werden diese Broadcast-Pakete an eine Steuerstation geleitet und dort bearbeitet. Neue Routing Tuples in RTMP-Request-Paketen werden in eine Tabelle aufgenommen, gefundene Tuples werden als Response-Pakete erwidert. Ähnlich wird eine ZIT in der Steuerstation erstellt.
Dabei sind folgende Punkte zu beachten:
+ Diese Methode ist flexibler und aktueller als eine lokale Weglenkungs- oder Zoneninformationstabelle.
+ Für das RTMP und ZIP wird nur eine minimale Anzahl von zusätzlichen Verbindungen notwendig.
+ Es besteht keine Notwendigkeit zur Änderung der RTMP- und ZIP-Algorithmen.
- Für die Steuerstation ist zusätzliche Implementierungsarbeit zu leisten.
- Um die Tabellen in der Steuerstation zu aktualisieren, ist ein hoher Verwaltungsaufwand erforderlich.
- Die Steuerstation wird zum Schwachpunkt im Netz (Ausfallgefahr).
Broadcast-Pakete des RTMP und des ZIP werden vorläufig noch ignoriert, da diese Protokolle das Interzonen-Konzept in AppleTalk unterstützen und der Bau eines ISDN-AppleTalk-Gateways zur Zeit noch nicht vorgesehen ist. In einer späteren Version ist einen Behandlung der Interzonen-Verwaltungspakete in einer Steuerstation vorgesehen[8].
8.5 Behandlung allgemeiner Broadcast-Pakete
Grundsätzlich steht es jedem Anwenderprogramm als Klient des LAP oder DDP frei Broadcast-Pakete zu senden. Derartige Broadcast-Pakete sind äußerst schwierig zu handhaben. Sie müßten durch sukzessives Anwählen an alle Stationen verteilt werden, was aber einen erheblichen Aufwand an Zeit und Verbindungen erfordert. Dadurch können die vom Sender gewünschten Antwortzeiten meist nicht eingehalten werden. Alternartive Ansätze hierzu sind durchaus denkbar, müssen aber nicht weiter diskutiert werden, da Broadcast-Pakete, die nicht vom LAP, NBP, ZIP oder RTMP ausgehen, für gewöhnlich nicht auftreten. Anwenderprogramme lokalisieren ihre Kommunikationspartner mit Hilfe des NBP über den Namen und Applikationstyp und arbeiten mit den so ermittelten exakten Adressen.
8.6 Das NameServer-Konzept
Da es in einem leitungsvermittelnden Netzwerk nur schwer möglich ist, Meldungen an alle Teilnehmer abzusetzen, wie es z.B. beim Name LookUp oder der dynamischen Node-Adressierung geschieht, wird eine Steuerstation, der sogenannte NameServer, eingeführt (vgl. Abb. 8.6.1). Der NameServer verwaltet ein eindeutiges Verzeichnis aller Nodes mit zugehöriger Rufnummer und aller sichtbaren Netzwerkteilnehmer. Für die dynamische Node-Adressierung bedarf es einer Erweiterung der Prozeduren des LAP zur Unterstützung eines NameServers. Für das Name Binding ist keine Modifikation der bestehenden Protokolle notwendig.
Abb. 8.6.1: NameServer im ISDN-Netz
Die Idee besteht darin, alle Broadcast-Pakete (Zieladresse $FF) an eine zentrale Station zu senden und dort zu behandeln. Der NameServer reagiert nur auf LAP-Pakete vom Typ $81 (ENQ) und $85 (FND) oder auf Name Binding-Pakete vom LAP-Typ $1 (kurze DDP-Pakete) und DDP-Typ $2 (NBP-Pakete). Broadcast-Pakete anderer Verwaltungsprotokolle, wie RTMP- und ZIP-Pakete, werden vorläufig noch ignoriert, da diese Protokolle das Interzonen-Konzept in AppleTalk unterstützen und der Bau eines ISDN-AppleTalk-Gateways zur Zeit noch nicht vorgesehen ist. In einer späteren Version des NamesServers ist eine Behandlung der Interzonen-Verwaltungspakete im NameServer ähnlich den NBP-Paketen erforderlich[9].
Aufgaben
des NameServers:
v Registrieren der Node IDs mit zugehöriger Rufnummer: Beim Öffnen
des .MPP-Treibers wird die Node ID im NameServer auf Eindeutigkeit überprüft
und mit der Rufnummer aus der Anschlußkennung registriert.
v Auskunftgeben über Rufnummern zu Node IDs: Über eine spezielle Anfrage kann vom NameServer die Rufnummer zu einer Node ID erfragt werden. Wird die Node ID nicht gefunden oder antwortet der NameServer nicht, so überträgt der Sender sein Paket an die Rufnummer des NameServers.
v Suchen und Registrieren von Names Table-Einträgen: Namen werden vom
NBP durch LkUp-Pakete am NameServer gesucht und, falls der Eintrag nicht vorhanden
ist (Eindeutigkeit), dort registriert. Existiert der gesuchte Eintrag bereits,
so wird ein LkUpReply-Paket erwidert. Das Löschen geschieht durch eine Task.
v Verwaltung und Löschen der Einträge im NameServer: Im NameServer muß eine Task vorgesehen werden, die das Names Directory und das Verzeichnis der Node IDs auf seine Aktualität überprüft. Das ist notwendig, da ein Knoten das Löschen eines Names Table-Eintrags dem Netz nicht explizit durch ein Kontrollpaket anzeigt[10]. Außerdem kann ein Knoten seinen Betrieb einstellen und sich nicht ordnungsgemäß abmelden. Diese Task des NameServers erspart es uns auch, neue Pakettypen einzuführen, die das Löschen von Einträgen im Names Directory und in der Liste der Node IDs veranlassen. Regelmäßig muß daher durch den NameServer ein Node angewählt und durch Enquiry Control-Pakete die Gültigkeit der Node ID im Verzeichnis überprüft werden. Befinden sich im Names Directory des NameServers Einträge zu einer Node ID, so sendet der Server zusätzlich LkUp-Pakete, um zu prüfen, ob die Einträge noch im lokalen Names Table des Knotens vorhanden sind. Werden Node ID oder Names Table-Eintrag nicht gefunden, so erfolgt die Löschung im NameServer.
Für das Mapping zwischen Node ID und Rufnummer und zur Behandlung von Anfragen nach Rufnummern werden neue Kontrollpakete eingeführt. Das Paketformat der NBP-Pakete muß nicht geändert werden, da es alle Informationen, die für die neuen Name Binding-Strategien notwendig sind, enthält.
Die Funktionen zur Verbindungssteuerung des ISDN-AppleTalk müssen die Existenz eines NameServers berücksichtigen. Es soll aber auch möglich sein, eine Station direkt, ohne den Umweg über den NameServer, anzuwählen.
8.6.1 Node-Adressierung über den NameServer
Um den Verbindungsaufbau zu automatisieren, muß weiterhin gewährleistet sein, daß eine Node ID im Netz eindeutig ist. Andernfalls sind im NameServer unter Umständen derselben Node ID verschiedene Rufummern zugeordnet, so daß sich Konflikte ergeben können. Eine geeignete Verwaltung von Node IDs und Rufnummern in einem zentralen Verzeichnis im NameServer verhindert mehrfache Node IDs im Netz.
Beim Öffnen des .MPP wird ein Enquiry Control Frame (ENQ) mit der Zieladresse (destID) $255 (Broadcast-Paket) an den NameServer übertragen. Dieser bestätigt die Eintragung durch einen Acknowledge Control Frame (ACK) (Abb. 8.6.2). Wurde der Knoten mit Node ID und Rufnummer am NameServer registriert, so enthält das ACK-Paket die Node ID des NameServers. Ist die Node ID im NameServer schon unter einer anderen Rufnummer vorhanden, so enthält das ACK-Paket die Node ID der anrufenden Station. Danach darf die Node ID nicht mehr geändert werden, ohne die Änderung dem NameServer mitzuteilen.
Abb. 8.6.2: Registrierung einer Node ID
Steht ein LAP-Paket zur Übertragung an und ist die Rufnummer zur Zieladresse des Paketes nicht bekannt, so sucht der sendende Knoten durch ein Find Node ID-Paket (FND)[11] an den NameServer nach der Rufnummer, die der Zieladresse (destID) durch die Tabelle im NameServer zugeordnet ist. Findet der NameServer die gesuchte Node ID in seiner Tabelle, so erwidert er ein Return Number Found-Paket (RND)[12] mit der zugehörigen Rufnummer (Abb. 8.6.3). Wird die Nummer nicht gefunden, erhält der Initiator kein Antwortpaket und das LAP-Paket wird direkt an den NameServer übertragen. Wurde die gesuchte Nummer vom NameServer geliefert, so wird die Verbindung zum NameServer unterbrochen, die ermittelte Nummer gewählt und das LAP-Paket an seine Bestimmungsadresse übertragen.
Abb. 8.6.3: Suche nach einer Rufnummer
Zusätzlich wird bei jedem Verbindungsaufbau die Eindeutigkeit der Node ID durch den ENQ-ACK-Handshake noch einmal überprüft. Das dient u.a. dazu die Node ID des anrufenden Gerätes festzuhalten. Dadurch kann der angerufene Knoten erkennen, daß er über eine bestehende Verbindung antworten kann. Außerdem wird die dynamische Node-Adressierung zum Testen der Verbindung verwendet.
Wird der .MPP-Treiber geschlossen, so muß die Node ID eines Gerätes wieder aus der Liste im NameServer entfernt werden. Das geschieht zusammen mit der Task des NameServers, die auch das Names Directory aktualisiert. In regelmäßigen Abständen überprüft der NameServer, ob alle Knoten in seiner Liste, die sich eine bestimmte Zeit nicht mehr gemeldet haben, noch aktiv sind. Ist ein Knoten nicht mehr erreichbar, so wird sein Node ID-Eintrag aus der Liste entfernt.
8.6.2 Name Binding-Funktionen über den NameServer
Der NameServer hält ein zentrales Names Directory, das die lokalen Einträge eines jeden Node (Names Table) enthält. Beim Name LookUp werden die LkUp-Pakete als Broadcast-Pakete direkt zum NameServer geleitet. Daher ist es bei einem Name LookUp nicht mehr notwendig sämtliche Teilnehmer zu konsultieren. Ist der Eintrag eines LkUp-Paketes noch nicht vorhanden, so übernimmt der NameServer den Inhalt dieses LkUp-Paketes in sein Names Directory. Bei der Registrierung und bei der Suche nach Namen verwendet das NBP jeweils LkUp-Pakete. Anhand des Pakettyps allein kann also nicht entschieden werden, ob es sich um eine Registrierung oder um eine Suche handelt. Beim Name LookUp enthalten LkUp-Pakete jedoch meist Wildcards in Namen und können so von Paketen zur Registrierung unterschieden werden. Wildcards in LkUp-Paketen werden daher durch den NameServer auflöst und nicht in das Names Directory aufgenommen.
Im NameServer ist eine Task vorgesehen, die regelmäßig prüft, ob ein Eintrag in der Names Table eines Node noch vorhanden ist. Wurde irrtümlich der Inhalt eines LkUp-Paketes beim Name LookUp in das Names Directory aufgenommen, so wird beim Aufruf der Task der Eintrag in der Names Table des entsprechenden Node nicht vorgefunden und daher aus dem Names Directory gelöscht. Andernfalls bleibt er auch nach der Ausführung der Task in der Tabelle erhalten.
Dadurch wird auch verhindert, daß Einträge von Knoten, die abgeschaltet wurden, ohne sich beim NameServer ordnungsgemäß abzumelden, im Names Directory und der Liste der Node IDs verbleiben. Dies würde bei Klienten des NameServers zu unnötigen Wartezeiten führen, da sie nach erfolgreicher Suche erst bei der direkten Anwahl des inaktiven Knotens erkennen könnten, daß dieser nicht mehr bereit ist. Nicht zuletzt belasten „Leichen“ im Names Directory die Suche und Registrierung.
Die einzelnen Funktionsaufrufe des NBP werden wie folgt behandelt:
FUNCTION NBPRegister (abRecord: ABRecHandle; async: Boolean): OSErr;
• Um anderen Teilnehmern einen neuen Gerätenamen mit Netzwerkadresse bekanntzumachen, sendet ein Node ein LkUp-Paket an den NameServer, der dann den Eintrag, falls er noch nicht vorhanden ist und es sich nicht um ein Wildcard handelt, in sein Names Directory übernimmt.
• Ist der Name schon einmal im Names Directory des NameServers vorhanden, so wird ein LkUpReply-Paket mit dem Eintrag erwidert. Der Name wird nicht registriert.
• Wurde kein LkUpReply-Paket erhalten, so hat der NameServer den Namen in sein Names Directory übernommen und der neue Eintrag kann in die lokale Names Table übernommen werden. Der NameServer überprüft in regelmäßigen Abständen, ob der Eintrag noch in der lokalen Names Table des Knotens vorhanden ist.
FUNCTION NBPRemove (entityName: EntityPtr): OSErr;
• Der Knoten löscht, wie bisher, den spezifizierten Eintrag in der lokalen Names Table.
• Das Löschen eines Eintrags der lokalen Names Table wird den übrigen Knoten im Netz nicht explizit durch ein Kontrollpaket mitgeteilt. Dadurch kann auch der NameServer nicht sofort erkennen, daß ein Eintrag gelöscht wurde. Der Eintrag befindet sich daher auch nach dem Löschen aus der lokalen Names Table im Names Directory des NameServers.
• Sendet der NameServer bei der nächsten Ausführung seiner Task ein LkUp-Paket mit dem gelöschten Eintrag an den Knoten, der den Eintrag zuvor besaß, so ist dieser nicht mehr in der Names Table des Knotens vorhanden.
• Hierauf entfernt der NameServer den Eintrag aus dem Names Directory und der Eintrag ist somit für alle Nodes gelöscht.
FUNCTION NBPLookUp (abRecord: ABRecHandle; async: Boolean): OSErr;
• Zuerst wird die eigene Names Table durchsucht und anschließend ein LkUp-Paket an den NameServer übertragen.
• Der NameServer liefert darauf in LkUpReply-Paketen alle Einträge, die der gesuchten Beschreibung (auch Wildcards) entsprechen.
FUNCTION NBPConfirm (abRecord: ABRecHandle; async: Boolean): OSErr;
Um zu prüfen, ob eine vorhandene Adresse noch gültig ist, wird ein LkUp-Paket direkt an diese Adresse übertragen (Zeitliche Verzögerung zwischen NBPLookUp und Anwählen!).
Die Implementierung eines NameServers wird in Anhang C beschrieben. Da es sich nicht um ein fertiges Produkt, sondern um eine Demonstration des Funktionsprinzips handelt, wurde auf die Implementierung einer aufwendigen Verwaltung der Node ID- und Names Table-Einträge durch eine Task vorerst verzichtet.
Die Verwendung einer Steuerstation ist den übrigen Methoden vorzuziehen, da sich sowohl die dynamische Node-Adressierung und die Verwaltung der Rufnummern als auch das Name Binding des AppleTalk adäquat auf dieses Prinzip abbilden lassen und keine Änderung des ursprünglichen Name Binding-Algorithmus notwendig ist.