-
Gebiet der Erfindung
-
Die
Erfindung betrifft Einrichtungsprotokolle (start up protocols) für Vorrichtungen
in Kommunikationsnetzwerken und insbesondere betrifft die Erfindung
Systeme, die es ermöglichen,
dass eine Maschine ohne eine konfigurierte Protokolladresse einer höherliegenden
Schicht eine solche Adresse ohne eine eindeutige Maschinenidentifizierung
erhält.
-
Hintergrund der Erfindung
-
Das
OSI-Modell ist das international anerkannte Standardmodell für Netzwerkarchitekturen (siehe
im allgemeinen Tannenbaum "Computer
Networks", 2. Auflage,
1988, Prentice-Hall). Gemäß diesem
Modell werden Netzwerkkommunikationen in eine Vielzahl von Protokolle
innerhalb von Schichten des Modells unterteilt. Lokale Netze (local
area netwoks; LANs) arbeiten unter Verwendung von Mediumzugriffsprotokollen
(medium access protocols) innerhalb der tieferliegenden Schichten,
d. h. den Schichten 1 und 2, des OSI-Modells, wie beispielsweise
carrier sense multiple access with collision detection CSMA/CD,
IEEE Standard 802.3, ebenfalls als ETHERNET bekannt, sowie das Token
Ring Zugriffsverfahren des IEEE Standards 802.5. Diese zwei Schichten
werden üblicherweise
in die physikalische Schicht und die Datenverbindungsschicht (data
link layer) unterteilt, wobei die Datenverbindungsschicht wiederum
in eine Mediumzugriffssteuerschicht (media access control layer;
MAC layer) und eine logische Verbindungsschicht (logical link layer) unterteilt
ist.
-
Systeme,
wie beispielsweise PCs, Arbeitsplatzrechner und Großrechner,
die mit einem LAN verbunden sind, weisen jeweils eine eindeutige
Protokollidentifizierung einer tieferliegenden Schicht auf, die
als die physikalische Netzwerkadresse oder MAC-Adresse bekannt ist.
LAN-Frames, die
unter diesen Protokollen einer tieferliegenden Schicht an ein Zielsystem
in dem Netzwerk weitergeleitet werden, enthalten die MAC-Adresse
des Zielsystems oder andere physikalische Netzwerkadressen als ein Ziel.
LAN-Frames, die von einem Ausgangssystem im Netzwerk weitergeleitet
werden, enthalten die MAC-Adresse des Ausgangssystems oder andere physikalische
Netzwerkadressen als eine Ausgangsadresse. Systeme kommunizieren,
indem zusätzliche
Protokolle (OSI-Schichten 3 bis 7) innerhalb der LAN-Frames der tieferliegenden
Schichten eingekapselt werden. Diese Protokolle höherliegender Schichten
sind in Suiten unterteilt, wie beispielsweise die TCP/IP-Protokollsuite
und die XNS-Protokollsuite. Zahlreiche LANs enthalten Gruppen von
Endsystemen, die andere Protokollsuiten höherliegender Schichten verwenden.
Diese Protokollsuiten höherliegender
Schichten weisen ebenso Systemen eindeutige Protokollidentifizierungen
einer höherliegenden
Schicht bzw. höherliegender
Schichten zu, die Frames in dem Netzwerk senden oder empfangen.
-
Beispielsweise
wird eine Internetprotokolladresse (IP-Adresse) jedem System zugewiesen, das
innerhalb eines Internetprotokollnetzwerkes arbeitet. Die Internetprotokolladresse
umfasst einen Netzwerkadressenabschnitt und einen Hostadressenabschnitt.
Der Netzwerkadressenabschnitt identifiziert ein Netzwerk, innerhalb
dessen sich das System befindet, und der Hostadressenabschnitt identifiziert
eindeutig das System in diesem Netzwerk. Prozessoren, die Pakete
in einem Internetprotokollnetzwerk leiten bzw. routen, verwenden
den Netzwerkadressenabschnitt der IP-Adresse in einem Frame, um das
lokale Netz der Zielmaschine zu finden. Sobald das lokale Netz des
Ziels lokalisiert worden ist, wird das Frame zu dem Netzwerk weitergeleitet,
wo der Hostadressenabschnitt verwendet wird, um dem Paket eine MAC-Adresse
für die
Zielmaschine zu zuweisen. Somit platziert eine Protokolladresse
einer höherliegenden
Schicht die Vorrichtung in einem bestimmten Netzwerk oder Teilnetzwerk,
so dass das Protokoll einer höherliegenden
Schicht wirksam das Routen von Paketen zwischen den Netzwerken organisieren
kann, ohne eine Tabelle der eindeutigen Identifizierungen der physikalischen
Zugangsschicht für
alle Terminals in dem Netzwerk aufzubewahren.
-
Um
in einem solchen Netzwerk zu kommunizieren, muss die Maschine zunächst seine
Protokolladresse einer höherliegenden
Schicht erhalten. Diese Adresse wird üblicherweise durch eine zentrale Verwaltung,
beispielsweise dem Internet Activities Board, oder durch einen Netzwerkmanager
zugewiesen. Normalerweise lernt eine bestimmte Maschine ihre IP-Adresse mittels eines
Konfigurationsvorgangs, wobei ein Techniker ein lokales Terminal
verwendet, um die Maschine zu konfigurieren. In einem zentral verwalteten
Netzwerk kann dies eine aufwendige Aufgabe darstellen, die das Reisen
von fachkundigem Personal weg von dem Ort der zentralen Verwaltung
umfasst. Für
Netzwerke, wie beispielsweise TCP/IP- oder SNMP-Protokolle, ist jedoch ein
umgekehrtes Adressenauflösungsprotokoll
(reverse address resolution protocol; RARP) entwickelt worden. Das
RARP ermöglicht,
dass eine Maschine ohne eine konfigurierte IP-Adresse eine IP-Adresse von
einem entfernten Server (remote server) erhält. Die Maschine sendet eine
Anfrage per Rundruf und wartet bis ein RARP-Server antwortet. In
dieser Anfrage muss die anfragende Maschine ihre physikalische Netzwerkadresse
(MAC-Adresse) bereitstellen, um sich eindeutig zu identifizieren
und um zu ermöglichen,
dass der Server diese in eine IP-Adresse überträgt.
-
Dieses
RARP-Protokoll arbeitet zufriedenstellend, so lange wie die zentrale
Verwaltungsstelle die physikalischen Netzwerkadressen der Vorrichtungen
kennt, die dem Netzwerk hinzugefügt
werden. Um die physikalische Netzwerkadresse herauszufinden, müssen alle
Systeme, die dem Netzwerk hinzugefügt werden, durch die zentrale
Verwaltungsstelle geführt
werden, so dass die Adressen dieser Maschinen eingelesen werden
können,
oder ein Techniker vor Ort muss die physikalische Netzwerkadresse
an der Maschine ablesen und dies der zentralen Verwaltungsstelle
telephonisch mitteilen. Dieser Vorgang erschwert das Verbinden einer
neuen Vorrichtung mit dem Netzwerk. Ferner ist der Vorgang, physikalisch die
physikalische Netzwerkadresse einzulesen, anfällig für menschliche Fehler. Derartige
Adressen sind üblicherweise
sehr lang (MAC-Adressen sind 48 Bit lang) und können fehlerhaft gelesen werden
oder falsch eingegeben werden.
-
Es
ist wünschenswert,
so genannte "Plug-and-Play"-Netzwerkvorrichtungen
zu haben. Derartige Vorrichtungen können durch Personal ohne Fachkenntnisse
angeschlossen und eingeschaltet werden. Die Notwendigkeit jedoch,
die physikalische Netzwerkadresse der Vorrichtung herauszufinden,
schmälert
diese Attraktivität.
-
Somit
ist es wünschenswert,
eine Technik zum Auflösen
von Protokolladressen höherliegender Schichten
bereitzustellen, ohne dass auf die Protokolladressen tieferliegender
Schichten zurückgegriffen
wird.
-
Zusammenfassung der Erfindung
-
Die
Erfindung ist in den unabhängigen
Ansprüchen
definiert.
-
Der
Stand der Technik wird durch die Druckschrift XP000577250, Proceedings
of the IEEE Workshop on Future Trends of Distributed Computing,
14. April 1992, Seiten 150 bis 157 repräsentiert, in der Merkmale beschrieben
werden, die denen im Oberbegriff des unabhängigen Anspruchs 11 entsprechen.
Die Druckschrift beschreibt ein Adressenauflösungsprotokoll, bei dem ein
Frame mit einer Quellen- und einer Ziel-Internetadresse eine Antwort
in Form eines Frames erzeugt, das die angefragte physikalische Adresse
der Zielstation einschließt.
Die physikalische Adresse ist eine Protokollidentifizierung einer
tieferliegenden Schicht bzw. tieferliegender Schichten. Die Druckschrift
beschreibt ferner ein erweitertes Auflösungsprotokoll, das eine MAC-Adresse
einholt.
-
Die
vorliegende Erfindung stellt ein umgekehrtes Adressenauflösungsprotokoll
(reverse address resolution protocol; RARP) zur Verwendung in einem
Kommunikationsnetzwerk bereit, was der Auflösungslogik erlaubt, eine Protokolladresse
einer höherliegenden
Schicht bzw. höherliegender
Schichten oder andere Informationen einer Quelle einer Anfrage nach
einer solchen Adresse unabhängig
von der physikalischen Netzwerkadresse einer solchen Quelle bereitzustellen.
Das Protokoll gemäß der vorliegenden
Erfindung wird in einem Prozessor mit einer Vielzahl von Anschlüssen verwendet,
wobei wenigstens einer dieser Anschlüsse über einen Punkt-zu-Punkt-Kanal
(point-to-point channel) mit einer entfernten Netzwerkvorrichtung
verbunden ist. Das umgekehrte Adressenauflösungsprotokoll antwortet auf
eine Auflösungsanfrage
von der entfernten Netzwerkvorrichtung über den Punkt-zu-Punkt-Kanal, um die
Protokolladresse einer höherliegenden Schicht
bzw. höherliegender
Schichten bereitzustellen, basierend vielmehr auf dem Anschluss, über den die
Auflösungsanfrage
empfangen wird, als auf der physikalischen Netzwerkadresse der anfragenden Vorrichtung.
Somit kann eine entfernte Vorrichtung mit einem Netzwerk und mit
einer zentralen Verwaltungsstelle über eine Punkt-zu-Punkt-Kommunikationsverbindung
in einem "Plug and
Play"-Modus verbunden
werden. Die Person, die die Vorrichtung mit dem entfernten Netzwerk
verbindet, braucht nicht, die physikalische Netzwerkadresse der
Vorrichtung zu bestimmen oder die Vorrichtung mit einem Adressprotokoll
einer höherliegenden
Schicht bzw. höherliegender
Schichten zu konfigurieren. All dies kann automatisch erledigt werden.
-
Somit
kann die vorliegende Erfindung als eine Vorrichtung zum Auflösen von
Protokolladressen höherliegender
Schichten in Reaktion auf Auflösungsanfragen
von einer Quelle von Auflösungsanfragen
in einem Kommunikationsnetzwerk bezeichnet werden. Die Vorrichtung
umfasst einen zentralen Prozessor mit einer Vielzahl von Anschlüssen für die Verbindung
mit dem Kommunikationsnetzwerk sowie Auflösungslogik, die mit dem Kommunikationsnetzwerk
verbunden ist und in Kommunikation mit dem zentralen Prozessor steht.
Die Auflösungslogik
stellt eine Protokollidentifizierung einer höherliegenden Schicht bzw. höherliegender
Schichten bereit in Reaktion auf einen bestimmten Anschluss aus
der Vielzahl von Anschlüssen,
durch den die Auflösungsanfrage
von dem zentralen Prozessor erhalten wird, unabhängig von der Protokollidentifizierung
einer tieferliegenden Schicht bzw. tieferliegender Schichten der Quelle
der Auflösungsanfrage.
Die Auflösungslogik kann
eine Routine sein, die von dem zentralen Prozessor ausgeführt wird,
oder eine Routine, die von einem Netzwerkmanagementprozessor ausgeführt wird,
der mit dem Kommunikationsnetzwerk verbunden ist und in Kommunikation
mit dem zentralen Prozessor steht.
-
Gemäß einem
Aspekt umfasst die Auflösungslogik
eine Auflösungstabelle,
die unabhängig von
den Protokollidentifizierungen tieferliegender Schichten konfiguriert
werden kann, die Protokollidentifizierungen höherliegender Schichten bestimmten
Anschlüssen
des zentralen Prozessors zuweist, durch die die Auflösungsanfragen
empfangen werden können.
-
Die
Protokollidentifizierung einer höherliegenden
Schicht bzw. höherliegender
Schichten kann eine Internetprotokoll IP-Adresse umfassen, die eine Netzwerkadresse
für die
Quelle der Auflösungsanfrage
und eine Hostadresse für
die Quelle der Auflösungsanfrage
umfasst. Ferner kann das Protokoll höherliegender Schichten von
einem Netzwerkmanagementsystem verwendet werden, das über das
gesamte Netzwerk kommuniziert, während
das Protokoll tieferliegender Schichten ein Mediumzugriffsprotokoll
umfasst.
-
Die
Auflösungslogik
gemäß der vorliegenden Erfindung
verlässt
sich darauf, dass die Quelle der Auflösungsanfrage über einen
Punkt-zu-Punkt-Kommunikationskanal mit dem bestimmten Anschluss des
Prozessors verbunden ist, der die Anfrage empfängt. Auf diese Art und Weise
dient der Anschluss als eine virtuelle Identifizierung für die Quelle
der Anfrage.
-
Somit
kann die vorliegende Erfindung ebenso als eine Vorrichtung zum Verbinden
eines ersten Netzwerkes mit einem zweiten Netzwerk bezeichnet werden.
Diese Vorrichtung umfasst eine Kommunikationsverbindung, einen ersten
Prozessor sowie einen zweiten Prozessor. Der erste Prozessor weist
ein erstes Interface auf, das mit dem ersten Netzwerk verbunden
ist, sowie ein zweites Interface, das mit der Kommunikationsverbindung
verbunden ist. Der zweite Prozessor weist eine Protokollidentifizierung
einer tieferliegenden Schicht bzw. tieferliegender Schichten auf
und ist mit dem zweiten Netzwerk und der Kommunikationsverbindung
verbunden. Die Auflösungslogik
ist mit dem ersten Netzwerk verbunden, um dem zweiten Prozessor
in Antwort auf eine Auflösungsanfrage
durch das zweite Interface des ersten Prozessors unabhängig von
der Protokollidentifizierung einer tieferliegenden Schicht bzw.
tieferliegender Schichten des zweiten Prozessors eine Protokollidentifizierung
einer höherliegenden
Schicht bzw. höherliegender
Schichten bereitzustellen. Auf diese Art und Weise kann der erste
Prozessor die Protokolladressen höherliegender Schichten für Vorrichtungen
in dem System unabhängig
von den Protokolladressen tieferliegender Schichten konfigurieren.
-
Gemäß einem
weiteren Aspekt der Erfindung umfasst der erste Prozessor Mittel,
um Netzwerkdienste Datenframes in dem ersten und dem zweiten Netzwerk über das
erste und das zweite Interface bereitzustellen, und der zweite Prozessor
umfasst Mittel, um das zweite Interface des ersten Prozessors transparent
auf das zweite Netzwerk zu erweitern.
-
Die
Auflösungslogik
kann eine Routine umfassen, die von dem ersten Prozessor ausgeführt wird,
oder einer Routine, die von einem Netzwerkmanagementprozessor ausgeführt wird,
der in dem ersten Netzwerk angeordnet ist.
-
Somit
ist eine Technik bereitgestellt worden, die bedeutend die "Plug and Play"-Fähigkeiten
einer Netzwerkvorrichtung verbessert. Entfernte Netzwerke können unter
Verwendung dieses Systems eingerichtet werden, ohne die Notwendigkeit
für fehleranfällige und
umständliche
Techniken zur Beschaffung der physikalischen Netzwerkadresse von
jeder Vorrichtung, die dem Netzwerk hinzugefügt wird.
-
Andere
Aspekte und Vorteile der vorliegenden Erfindung ergeben sich aus
den Figuren, der detaillierten Beschreibung sowie der Ansprüche.
-
Kurze Beschreibung der
Figuren
-
1 zeigt
ein schematisches Diagramm eines Systems einschließlich der
umgekehrten Adressenauflösungslogik
gemäß der vorliegenden
Erfindung.
-
2 zeigt
eine herkömmliche
Sequenz des Paketaustausches für
umgekehrte Adressenauflösung über LAN-Medien.
-
3 zeigt
eine Sequenz des Paketaustausches über ein WAN-Medium, wie es
gemäß der vorliegenden
Erfindung erweitert ist.
-
4 zeigt
den Auflösungsanfragenerzeugungsprozess,
der in der Sequenz nach 3 verwendet wird.
-
5 zeigt
den Auflösungsanfragenantworterzeugungsprozess,
der in der Sequenz nach 3 verwendet wird.
-
6 zeigt
den Auflösungsanfragenantwortakzeptanzprozess,
der in der Sequenz nach 3 verwendet wird, der zu einer
Anfrage für
eine Teilnetzmaske in IP-Netzwerken führt.
-
7 zeigt
ein Diagramm des Teilnetzmaskenantworterzeugungsprozess, der in
der Sequenz nach 3 verwendet wird.
-
8 zeigt
ein Diagramm des Teilnetzmaskenantwortakzeptanzprozess, der in der
Sequenz nach 3 verwendet wird.
-
9 zeigt
ein schematisches Diagramm, das eine Netzwerkumgebung darstellt,
in der die vorliegende Erfindung verwendet werden kann.
-
Detaillierte Beschreibung
der bevorzugten Ausführungsformen
-
Eine
detaillierte Beschreibung der bevorzugten Ausführungsformen der vorliegenden
Erfindung wird unter Bezugnahme auf die 1 bis 9 bereitgestellt. 1 zeigt
eine Anwendung der vorliegenden Erfindung in einer bevorzugten Ausführungsform.
Die 2 bis 8 zeigen das erweiterte Protokoll
für eine
umgekehrte Adressenauflösung,
die in einer bevorzugten Ausführungsform
der vorliegenden Erfindung verwendet wird. 9 zeigt
eine Übersicht
eines Netzwerkes, in dem die vorliegende Erfindung angewendet werden
kann.
-
1 zeigt
ein schematisches Diagramm einer Vorrichtung zum Verbinden eines
ersten Netzwerkes 10 mit einem zweiten Netzwerk 11 unter
Verwendung von Adressenauflösungslogik 25 gemäß der vorliegenden
Erfindung. Das erste Netzwerk 10 umfasst ein erstes LAN 9,
das eine Vielzahl von Endsystemen und einen Server umfasst, und
kann mit anderen LANs unter Verwendung von Zwischensystemen (nicht
gezeigt) auf bekannte Art und Weise verbunden sein. Ein Grenzrouter
(boundary router) 12 ist mit dem LAN 9 verbunden.
Der Grenzrouter 12 ist ein Zwischensystem in dem Netzwerk,
das Netzwerkmittel bereitstellt, die Protokollsuiten höherliegender
Schichten dienen, die in einer bestimmten Ausführungsform Routingmittel darstellen.
Als solcher unterhält
der Grenzrouter 12 Endsystemverzeichnisse 13 für das lokale
LAN 9 und globale Routinginformation 14, um den
Routingfunktionen gemäß den Protokollsuiten
höherliegender
Schichten zu dienen. Folglich enthalten die Endsystemverzeichnisse DEC-Endsystemtabellen,
IPX-Endsystemtabellen, IP-Endsystemtabellen und andere, um anderen
Protokollsuiten zu dienen, die in dem Netzwerk 10 operieren.
Der Grenzrouter 12 kann auch mit anderen Teilen des Unternehmensdatennetzwerkes
verbunden sein, wie dies schematisch mittels des Pfeils 15 dargestellt
ist.
-
Der
Grenzrouter 12 umfasst ein lokales Interface 16,
das dem lokalen LAN 9 dient, den Endsystemen in dem LAN 9 Zugang
zu den Netzwerkmitteln innerhalb des Grenzrouters bereitzustellen.
Der Grenzrouter kann ebenso Interfaces zu anderen LANs aufweisen.
Zusätzlich
umfasst der Grenzrouter 12 ein entferntes Routinginterface 17,
das ein Interface zu den Netzwerkmitteln für Endsysteme in dem entfernten
Netzwerk 11 bereitstellt. In Unterstützung des entfernten Interfaces 17 unterhält der Grenzrouter
Endsystemverzeichnisse 18, die den Protokollsuiten höherliegender
Schichten in dem entfernten Netzwerk 11 dienen.
-
Wie
dies durch das gestrichelte Symbol 19 dargestellt ist,
erscheint das entfernte Netzwerk 11 den Endsystemen in
dem lokalen LAN 9 als ob es ein LAN wäre, das lokal mit dem Grenzrouter 12 verbunden
ist. Diese Erscheinung wird über
eine Kommunikationsverbindung 20, die Telephon- oder andere Einwählverbindungen,
gemietete Verbindungen, Satelliten, drahtlose Medien oder andere
Kommunikationsmedien verwenden kann, die als Punkt-zu-Punkt-Kanal konfiguriert
sind, zu einem Routingadapter 21 aufrecht erhalten, der
mit dem entfernten Netzwerk 11 verbunden ist. Das entfernte Netzwerk 11 umfasst
ein entferntes LAN 22, an das eine Vielzahl von Endsystemen
und Server bekanntermaßen
verbunden werden kann. Zusätzlich
kann das LAN 22 mit anderen LANs in dem entfernten Netzwerk 11 über Zwischensysteme
(nicht gezeigt) bekanntermaßen
verbunden sein. Der Routingadapter 21 stellt Mittel zum
transparenten Erweitern des entfernten Routinginterfaces 17 auf
das entfernte Netzwerk 11 über die Kommunikationsverbindung 20 bereit.
Aus der Sicht des entfernten Netzwerkes 11 stellt der Routingadapter 21 dieselbe
Funktionalität wie
ein Router bereit, während
der Routingadapter selbst unabhängig
von den Protokollsuiten höherliegender
Schichten operiert.
-
Das
System stellt somit eine wirksame Kommunikation zwischen entfernten
Netzwerken und einem Unternehmensnetzwerk über einen Grenzrouter bereit
(beispielsweise Netz 11, Routingadapter 21, Verbindung 20,
Grenzrouter 12, Netz 9).
-
Der
Routingadapter 21 umfasst Hardware, die physikalische Netzwerkzugangsprotokolle
zur Verbindung mit den Netzwerk 22 bereitstellt. Ebenso ist
einer solchen Hardware eine physikalische Netzwerkadresse oder MAC-Adresse
zugewiesen, um das System eindeutig für die Protokollsuiten tieferliegender
Schichten zu identifizieren. Um jedoch bei den Protokollsuiten höherliegender
Schichten teilzunehmen, die von dem Grenzrouter 12 oder
anderswo in dem zentralen Netzwerk 10 verwaltet werden,
wird eine Identifizierung für
den Routingadapter 21 benötigt, die solchen Protokollen
höherliegender
Schichten dient. Somit umfasst der Grenzrouter 12 Auflösungslogik 25,
um eine solche Identifizierung in Antwort dem Interface 17 bereitzustellen, über das
eine Anfrage für
eine solche Identifizierung empfangen wird.
-
Die 2 bis 8 zeigen
das umgekehrte Adressenauflösungsprotokoll,
das von der Auflösungslogik 25 in
dem Grenzrouter von 1 gemäß einer bevorzugten Ausführungsform
ausgeführt
wird, in der die Protokolladresse höherliegender Schichten eine
Internetprotokoll IP-Adresse umfasst, wie diese von SNMP (Simple
Network Management Protocol; Einfaches Netzwerkmanagementprotokoll)
Standardnetzwerkmanagementservern verwendet werden.
-
2 zeigt
das bekannte Verfahren, das in dem bevorzugten System auf Anschlüssen des
Routingadapters verwendet wird, der mit LAN-Medien verbunden ist.
Die Struktur von 2 umfasst ein erstes Interface 100,
das dem RARP-Clientanschluss des Routingadapters 21 entspricht,
sowie ein zweites Interface 101, das einem RARP-Server
in dem lokalen Netzwerk 11 entspricht. Der Routingadapter
umfasst den RARP-Anfrageerzeugungsprozess 102, einen RARP-Antwortakzeptanzprozess 103 und
einen ICMP-Teilnetzmaskenantwortakzeptanzprozess 104. Die
Auflösungslogik 25 in
dem RARP-Server umfasst einen RARP-Antworterzeugungsprozess 105 und
einen ICMP-Teilnetzmaskenantworterzeugungsprozess 106.
-
Unter
Verwendung des in der Industrie standardmäßig verwendeten RARP-Anfrageerzeugungsprozess,
wie dieser in RFC 903 mit dem Datum Juni 1984 spezifiziert
ist, erzeugt der RARP-Anfrageerzeugungsprozess 102 in dem
Client eine RARP RFC 903 Anfrage 107, die die
MAC-Adresse des Clients umfasst. Diese Anfrage 107 wird
an dem Serverinterface 101 empfangen und der RARP-Antworterzeugungsprozess 105 erzeugt
eine Antwort 108, indem auf eine Datenbank oder eine andere
Logik zugegriffen wird, die basierend auf der MAC-Adresse in der Anfrage 107 eine
IP-Adresse zuweist. Der RARP-Antwortakzeptanzprozess 103 in
dem Client empfängt
die IP-Adresse von der Antwort 108, speichert diese, wie
erforderlich, im Client und erzeugt eine ICMP-Teilnetzmaskenanfrage 109.
Der Server 101 empfängt
die Anfrage 109 und der ICMP-Teilnetzmaskenantworterzeugungsprozess 106 liefert
dem Client 100 eine Teilnetzmaskenantwort 110.
Der ICMP-Teilnetzmaskenantwortakzeptanzprozess 104 konfiguriert
sodann den Client mit der IP-Adresse und der Teilnetzmaske und weist
die Adresse des Servers 101 als die Standardgatewayadresse
(default gateway address) zu.
-
3 zeigt
diesen Prozess als gemäß der vorliegenden
Erfindung zur umgekehrten Adressenauflösung erweitert unabhängig von
der physikalischen Netzwerkadresse des Clients. In diesem Aspekt
entspricht das Interface 120 dem Routingadapter 21,
der als ein RARP-Client arbeitet. Das Interface 121 entspricht
dem Interface 17 des Grenzrouters 12, der als
ein RARP-Server arbeitet. Der RARP-Server 121 braucht nicht,
in dem Grenzrouter 12 angeordnet sein. Vielmehr kann dieser
in jedwedem System oder Zwischensystem angeordnet sein, das mit
den Netzwerken verbunden ist, die von dem Grenzrouter 12 bedient
werden.
-
In
der erweiterten Sequenz, wie diese in 3 dargestellt
ist, umfasst der Routingadapter ferner einen RARP-Anfrageerzeugungsprozess 122 (4),
einen RARP-Antwortakzeptanzprozess 123 (6)
sowie einen ICMP-Teilnetzmaskenantwortakzeptanzprozess 124 (8).
Der RARP-Server in dem Grenzrouter umfasst einen RARP-Antworterzeugungsprozess 125 (5)
und einen ICMP-Teilnetzmasknantworterzeugungsprozess 126 (7).
-
Wie
bei bekannten Systemen, erzeugt der RARP-Anfrageerzeugungsprozess 122 in
dem Client 120 eine RARP RFC 903 Anfrage 127.
Außerdem
erzeugt der Prozess 122 eine erweiterte Anfrage 128, die
dem Empfänger
anzeigt, dass die Adressenauflösung
unabhängig
von der MAC-Adresse durchgeführt
werden muss.
-
Der
RARP-Antworterzeugungsprozess 125 empfängt sowohl die RFC 903 Anfrage 127 als
auch die MAC unabhängige
Anfrage 128. Wenn die Antwort mit der RFC 903 Anfrage
geliefert werden kann, dann fährt
der Antworterzeugungsprozess 125 auf diesem Wege fort.
Wenn jedoch die MAC-Adresse des Clients 120 vorher nicht
dem Antworterzeugungsprozess 125 kommuniziert worden ist,
dann muss die MAC unabhängige
Anfrage 128 verwendet werden.
-
Der
RARP-Antworterzeugungsprozess 125 ist mit einer Mediumadressen-/IP-Adressen-Datenbank 135 und
mit einer Kanalnummer-/IP-Adressen-Datenbank 136 verbunden.
Diese Datenbanken werden von dem Netzwerkmanager konfiguriert, um IP-Adressen über das
gesamte Netzwerk zuzuweisen. Auf die Kanalnummer-/IP-Adressen-Datenbank wird
zugegriffen, wenn die Mediumadresse (MAC-Adresse) des Clients 120 nicht
zu der Zeit erhältlich
ist, wenn die IP-Adresse konfiguriert wird.
-
In
beiden Fällen
erzeugt der RARP-Antworterzeugungsprozess 125 eine RARP
RFC 903 Antwort 129, die eine IP-Adresse einschließt. Der RARP-Antwortakzeptanzprozess 123 in
dem Client 120 akzeptiert die IP-Adresse und generiert
eine ICMP-Teilnetzmaskenanfrage 130. In dem Server 121 liefert
der ICMP-Teilnetzmaskenantworterzeugungsprozess 126 eine
ICMP-Teilnetzmaskenantwort 131. Der Client 120 empfängt diese
Antwort und führt
den ICMP-Teilnetzmaskenakzeptanzprozess 124 aus.
-
4 zeigt
den RARP-Anfrageerzeugungsprozess gemäß dem Block 122 von 3.
Diese Routine ist als Schleife über
alle Interfaces oder Anschlüsse
auf dem entfernten Knoten, gleichfalls Blattknoten (leaf node) genannt,
ausgestaltet, um dessen IP-Adresse zu bestimmen. Der Algorithmus
startet mit einer Nachricht, dass das Interface betriebsbereit bzw.
aktiv ist 400. Nach dieser Nachricht, dass das Interface
betriebsbereit ist, testet der Algorithmus, ob die IP-Adresse in
einem lokalen Speicher erhalten werden kann (Schritt 401).
Wenn die Adresse im lokalen Speicher erhalten werden kann, dann
ist die Routine fertig, wie dies bei Schritt 402 angezeigt
ist. Wenn die IP-Adresse nicht erhalten werden kann, dann wird ein
Index für
die Interfaces auf das erste Interface gesetzt (Schritt 403).
Anschließend
testet der Algorithmus, ob das interface betriebsbereit ist (Schritt 404).
Wenn das Interface betriebsbereit ist, dann wird die RFC 903 RARP
Anfrage über
das Interface gesendet (Schritt 405). Anschließend testet der
Algorithmus, ob es sich bei dem Interface um ein Fernnetzinterface
bzw. WAN-Interface (wide area network WAN interface) handelt (Schritt 406).
Wenn es sich um ein WAN-Interface handelt, dann wird die erweiterte
RARP-Anfrage gesendet,
die eine Antwort erfordert, die unabhängig von der MAC-Adresse ist (Schritt 407).
-
Wenn
bei Schritt 404 das Interface nicht betriebsbereit ist,
oder wenn bei Schritt 406, es sich bei dem Interface nicht
um ein WAN-Interface handelt, oder nachdem die erweiterte RARP-Anfrage bei Schritt 407 gesendet
wird, springt der Algorithmus zu Schritt 408. Bei Schritt 408 testet
der Algorithmus, ob der Index anzeigt, dass das letzte Interface
gestestet worden ist. Wenn dies nicht der Fall ist, dann wird der Index
bei Schritt 409 inkrementiert und der Algorithmus kehrt
zu Schritt 404 zurück.
Wenn das letzte Interface abgearbeitet worden ist, dann testet der
Algorithmus, ob irgendwelche Anfragen erfolgreich ausgesendet worden
sind und immer noch anhängig
sind (Schritt 410). Wenn keine Anfragen anhängig sind, weil
keine Anfrage erfolgreich gesendet worden ist, dann wird ein Sendeanfragealarm
eingestellt (Schritt 411) und der Algorithmus ist fertig.
Wenn bei Schritt 410 Anfragen anhängig sind, weil eine oder mehre Anfragen
erfolgreich gesendet worden sind, dann wird bei Schritt 412 ein
Anfragenwiederübertragungsalarm
eingestellt und der Algorithmus ist fertig.
-
Der
Anfragewiederübertragungsalarm
führt zu
einer erneuten Ausführung
der Schleife, die bei Schritt 413 beginnt und direkt bei
Schritt 401 fortfährt. Der
Sendeanfragalarm, der bei Schritt 411 eingestellt wird,
führt zu
einer erneuten Ausführung
der Schleife, die bei Schritt 414 beginnt. Nach dem Schritt 414 testet
der Algorithmus bei Schnitt 415, ob irgendwelche Anfragen
immer noch anhängig
sind. Wenn anhängige
Anfragen vorliegen, dann ist der Algorithmus fertig. Wenn es keine
anhängigen
Anfragen gibt, dann wird in die Schleife eingetreten, indem bei
Schritt 401 fortgefahren wird.
-
Somit
sendet der RARP-Anfrageerzeugungsprozess 122, wie in 4 gezeigt,
sowohl die standardmäßige RFC 903 RARP-Anfrage,
die eine Antwort basierend auf der MAC-Adresse erfordert, als auch
eine erweiterte RARP-Anfrage über WAN-Interfaces,
die eine von der MAC-Adresse unabhängige Antwort erfordert. Das
WAN-Interface in dem bevorzugten System ist der Punkt-zu-Punkt Kommunikationskanal 120 zwischen
dem Grenzrouter und dem Routingadapter von 1.
-
Somit
erstellt das erweitere RARP-Interface eine Nachricht unter Verwendung
des standardmäßigen Nachrichtenformats
gemäß RFC 903.
Die Nachricht wird in dem Datenabschnitt eines Ethernetframes übertragen.
Ein Ethernetframe, das eine RARP-Anfrage trägt, weist die übliche Präambel, d. h.
Ethernetquellenadresse und Ethernetzieladresse, sowie Pakettypenfelder
vor dem Frame auf. Der Frametyp enthält den Wert 0 × 8035,
um die Inhalte als eine RARP-Nachricht zu identifizieren. Der Datenabschnitt
des Rahmens enthält
die 28-Oktett-RARP-Nachricht.
-
Der
RARP-Client erhält
die physikalische Netzwerkadresse des Interfaces, über das
die RARP-Anfrage gemäß bekannter
Standardverfahren ausgesendet wird. Die RARP-Anfrage enthält die physikalische
Netzwerkadresse (MAC-Adresse) des RARP Clients als das Quellenhardwareadressenfeld und
0 × FFFFFFFFFFFF
als die Zielhardwareadresse. Die Protokolladressen höherliegender
Schichten sowohl der Quelle als auch des Ziels sind undefiniert und
somit 0. Der RARP-Anfrage-Befehlscode ist 3 für die standardmäßige RARP
RFC 903. Das Protokoll gemäß der vorliegenden Erfindung
verwendet Befehlscode 16 für die erweiterte Anfrage, die
eine MAC-Adressen unabhängige
Auflösung
erfordert. Selbstverständlich
kann auch irgendein anderer geeigneter Befehlscode verwendet werden.
-
Wenn
der RARP-Client seine erste Rundrufanfrage zur Adressenauflösung aussendet,
wird gemäß einer
Ausführungsform
gleichfalls ein Wiederübertragungszeitgeber
bei 5 Sekunden eingestellt (Schritt 412). Diese große Verzögerung stellt
sicher, dass der Server ausreichend Zeit hat, die Anfrage zu bearbeiten
und eine Antwort zurückzuschicken. Wenn
der Zeitgeber abläuft,
löscht
der Client, falls dieser schon eine IP-Adresse aufweist, den Zeitgeber
und der RARP-Client wechselt in den Schlafmodus (idle mode). Andernfalls
sendet dieser für
jedes Interface das betriebsbereit bzw. aktiv ist, eine weitere
Rundrufanfrage aus und stellt den Zeitgeber erneut ein. Er wird
solange Senden, bis er eine Antwort erhält. Bei jedem erneuten Senden
wird sich der Zeitgeber verdoppeln, bis dieser einen Maximalwert
von 15 Minuten erreicht. Von diesem Punkt an wird er unter Verwendung
dieses Wertes fortfahren.
-
Der
RARP-Client akzeptiert lediglich eine Antwort und verwirft jedwede
doppelten Antworten. Bevor der Client irgendeine Antwort akzeptiert,
stellt dieser somit zunächst
sicher, dass ihm noch keine IP-Adresse zugewiesen worden ist.
-
5 zeigt
den RARP-Antworterzeugungsprozess, der dem Block 125 von 3 entspricht. Dieser
Algorithmus startet, indem bei Schritt 500 die RARP-Anfrage 127 oder 128 empfangen
wird. Nach Schritt 500 testet der Algorithmus, ob es sich
um eine standardmäßige RFC 903 Anfrage
handelt (Schritt 501).
-
Wenn
es sich bei Schritt 501 um eine standardmäßige Anfrage
im RFC 903 Format handelt, dann durchsucht der Algorithmus
bei Schritt 502 die Mediumzugangs-/IP-Adressen-Datenbank 135.
-
Wenn
die Anfrage nicht im standardmäßigen RFC 903 Format
vorgelegen hat, dann testet der Algorithmus bei Schritt 503,
ob diese im erweiterten Format (beispielsweise Befehlscode 16)
vorliegt. Wenn sie im erweiterten Format vorliegt, dann wird bei
Schritt 504 die Kanalnummer-/IP-Adressen-Datenbank durchsucht.
Wenn die Anfrage in keinem der beiden Formate vorliegt, dann ist
der Algorithmus fertig, wie dies bei Schritt 505 angedeutet
ist.
-
Nachdem
bei Schritt 502 oder bei Schritt 505 die Datenbank
durchsucht worden ist, testet der Algorithmus bei Schritt 506,
ob ein passender Eintrag gefunden worden ist. Wenn kein passender
Eintrag gefunden worden ist, dann ist der Algorithmus bei Block 505 fertig.
Wenn ein passender Eintrag gefunden worden ist, dann formatiert
und sendet der Algorithmus ein RFC 903 RARP-Antwortpaket,
die dem Client eine IP-Adresse liefert (Schritt 507).
-
6 zeigt
den RARP-Antwortakzeptanzprozess 123 von 3.
Dieser Algorithmus beginnt damit, dass bei Schritt 600 die
RARP-Antwort empfangen wird, die bei Schritt 507 von 5 erzeugt worden
ist. Zunächst
bestimmt der Algorithmus, ob die Antwort bei Schritt 601 erwartet
wird. Wenn diese nicht erwartet wird, dann wird die RARP-Antwort
bei Schritt 602 verworfen und der Algorithmus ist bei Schritt 603 fertig.
Wenn die Antwort erwartet wird, dann testet der Algorithmus, ob
eine IP-Adresse bereits im lokalen Speicher erhältlich ist (Schritt 604). Wenn
die Adresse bereits erhältlich
ist, dann fährt
der Prozess bei Schritt 602 fort. Wenn die IP-Adresse bei Schritt 604 nicht
erhältlich
ist, dann wird die IP-Adresse von der RARP-Antwort im lokalen Speicher
gespeichert (Schritt 605). Nach Schritt 605 werden
alle anhängigen
Alarme in dem Client gelöscht
(Schritt 606) und eine ICMP-Teilnetzmaskenanfrage wird über das
Netzwerk gesendet (Block 607). Nachdem bei Schritt 607 die
Teilnetzmaskenanfrage ausgesendet worden ist, wird bei Schritt 608 ein
ICMP-Teilnetzmaskenanfragewiederübertragungsalarm
eingestellt und der Algorithmus ist fertig.
-
Sobald
der Client oder der Blattknoten die IP-Adresse erhalten hat, wird
somit eine ICMP-Adressenmaskenanfrage
zu der antwortenden Partei gesendet und ein Wiederübertragungszeitgeber
von 5 Sekunden eingestellt (Schritt 608). Die Anfrage spezifiziert
den RARP-Server,
der die IP-Adresse als das Ziel bereitgestellt hat. Wenn der Blattknoten
keine erfolgreiche Antwort erhält
und sein Wiederübertragungszeitgeber
ausläuft,
dann wird er eine weitere ICMP-Teilnetzmaskenanfrage auf allen zugänglichen
Interfaces per Rundruf aussenden und den Zeitgeber auf 5 Sekunden
zurückstellen.
Die maximale Anzahl von wieder holten Sendungen in einer Ausführungsform
beträgt
10. Wenn die zehnte erneute Übertragung
fehl schlägt,
dann wird die natürliche Teilnetzmaske
der IP-Adressenklasse zugewiesen. Dies stellt sicher, dass die Software
das Netzwerk nicht unendlich mit unnötigem Verkehr verstopft.
-
7 zeigt
den ICMP-Teilnetzmaskenantworterzeugungsprozess, der dem Block 126 von 3 entspricht.
Dieser Prozess beginnt damit, dass die ICMP-Teilnetzmaskenanfrage
bei Schritt 700 empfangen wird. Nach dem Empfang der Anfrage wird
bei Schritt 701 eine Antwort erzeugt und dem Client gesendet.
Nach dem Senden der Antwort, die eine Teilnetzmaske für die vorher
gesendete IP-Adresse einschließt,
ist der Algorithmus fertig (Schritt 702).
-
8 zeigt
den ICMP-Teilnetzmaskenantwortakzeptanzprozess, der dem Block 124 von 3 entspricht.
Dieser Algorithmus wird eingeleitet, sobald die ICMP-Antwort bei
Schritt 800 empfangen worden ist. Wenn die Antwort empfangen
wird, dann wird bei Schritt 801 die Teilnetzmaske gespeichert. Anschließend werden
jedwede anhängige
Alarme bei Schritt 802 gelöscht. Nachdem bei Schritt 802 die Alarme
gelöscht
worden sind, wird bei Schritt 803 der RARP-Server, der
die Antworten auf die vorhergehenden Anfragen geliefert hat, als
das Standardgateway bzw. voreingestelltes Gateway definiert. Nachdem
das Standardgateway definiert worden ist, ist der Algorithmus fertig,
wie dies bei Schritt 804 angedeutet ist.
-
Wenn
ein ICMP-Wiederübertragungsalarm bestätigt wird,
dann empfängt
diese Routine bei Schritt 805 eine Anzeige. Zunächst bestimmt
der Algorithmus bei Schritt 806 in Reaktion auf diesen Alarm,
ob eine maximale Anzahl von erneuten Versuchen überschritten worden ist. Wenn
diese überschritten
worden ist, dann wird, wie bei Schritt 807 angedeutet,
die natürliche
Maske für
die IP-Adresse verwendet, und der RARP-Server wird bei Schritt 803 als
das Standardgateway voreingestellt. Wenn die maximale Anzahl erneuter
Versuche nicht überschritten
worden ist, dann wird bei Schritt 807 eine ICMP-Teilnetzmaskenanfrage
erzeugt und die ICMP-Anfragewiederübertragungsalarm wird bei Schritt 808 zurückgesetzt.
Schließlich
ist der Algorithmus fertig, wie dies bei Schritt 804 angedeutet
ist.
-
Somit
erweitert eine bevorzugte Ausführungsform
der vorliegenden Erfindung das RARP-Standardprotokoll für die umgekehrte Adressenauflösung, um
eine spezielle Anfrage unabhängig von
der MAC-Adresse des Clients bereitzustellen. Der RARP-Server verwendet
die standardmäßige ARP-Tabelle
zum Abbilden physikalischer Netzwerkadressen auf IP-Adressen. Er
schließt
ferner eine Anschluss-zu-IP-Adressen-Tabelle (Kanalnummer/IP Adresse)
ein, die verwendet wird, auf die erweiterten RARP-Anfragen für eine MAC
unabhängige Auflösung zu
antworten. Diese Tabelle bildet eine Anschlussnummer oder Kanalnummer
auf eine IP-Adresse ab. Dieses Verfahren, IP-Adressen zuzuweisen,
vermeidet die Unannehmlichkeiten, die damit verbunden sind, die
MAC-Adresse des RARP-Clients von vornherein kennen zu müssen.
-
Diese
Technik kann auf andere Protokolltypen erweitert werden, wie beispielsweise
das BootP-Protokol, das Händlererweiterungen
bereitstellt. Gemäß diesem
Aspekt können
die Händlererweiterungen
außerdem
für andere
Funktionen verwendet werden, die basierend auf der Kanalnummer oder
dem Anschluss initialisiert werden können, über den die Anfrage von dem
Server empfangen wird. Folglich kann die BootP-Anfrage eine IP-Adresse, eine
Konfigurationsmanager-ID und Konfigurationsinformation unabhängig von
deren MAC-Adresse oder
physikalischer Netzadresse anfragen.
-
9 zeigt
eine Netzwerkkonfiguration, in der die vorliegende Erfindung verwendet
werden kann. Gemäß der Konfiguration
von 9 umfasst ein zentraler Knoten 900 eine
Vielzahl von Anschlüssen,
die 1, 2, 3, 4, 5 und 6 gekennzeichnet
sind. Die Anschlüsse 2, 4 und 5 sind
mit jeweiligen LANs 901, 902 bzw. 903 verbunden.
Das LAN 903 umfasst ein System, das als ein Netzwerkmanagementprozessor 904 operiert,
der solche Protokolle, wie das SNMP-Protokoll oder ein Telnet-Protokoll
ausführen kann,
die von IP-Adressen Gebrauch machen, um auf Endsysteme und Zwischensysteme
in dem Netzwerk zuzugreifen.
-
Der
Anschluss 1 ist über
eine Punkt-zu-Punkt-Kommunikationsverbindung 905 mit einem
Blattknoten (leaf node) 906 verbunden. Der Blattknoten 906 ist
mit dem LAN 907 verbunden.
-
Ebenso
ist der Knoten 3 über
einen Punkt-zu-Punkt-Kanal 908 mit dem Blattknoten 909 verbunden.
Der Blattknoten 909 ist mit einem LAN 910 verbunden.
-
Der
Anschluss 6 ist über
einen Punkt-zu-Punkt-Kanal 911 mit dem Blattknoten 912 verbunden.
Der Blattknoten 912 ist mit dem LAN 913 verbunden.
-
Wie
in der Figur dargestellt, werden das LAN 913, die Verbindung 911,
das LAN 903 und das LAN 902 alle als ein einzelnes
IPX-Netzwerk, IPX 1, verwaltet. Das LAN 907 und
das LAN 901 werden als ein einzelnes IPX-Netzwerk, IPX 2,
verwaltet. Das LAN 910 wird als ein AppleTalk-Netzwerk
verwaltet. Die gesamte Konfiguration wird als ein einzelnes IP-Netzwerk
für die
Zwecke des Netzwerkmanagementprozessors 904 verwaltet.
Somit benötigen
alle Blattknoten 906, 909, 912 eine IP-Adresse
für die Zwecke
des Netzwerkmanagementprozessors 904. Diese IP-Adressen
können
gemäß der vorliegenden Erfindung
unabhängig
von der physikalischen Netzwerkadresse des Blattknotens unter Verwendung
der MAC-Adressen unabhängigen
IP-Adressen-Auflösungslogik 914 gemäß der vorliegenden
Erfindung verwendet werden.
-
Gleichfalls
kann der Netzwerkmanagementprozessor 904 einen Server umfassen,
um die IP-Adressenkonfiguration gemäß der vorliegenden Erfindung
zu verwalten. Beispielsweise könnte
eine BootP-Protokollhändlererweiterung
verwendet werden, um ein Anfragepaket, das eine IP-Adresse für einen
Blattknoten (z. B. Knoten 906) anfragt, mit einer Kanalnummer
für die
Verbindung 905 und Knotennummer für den zentralen Knoten 900 zu
markieren. Der zentrale Knoten 900 würde dann das markierte Anfragepaket
an den entfernten Netzwerkmanagementprozessor 904 weiterleiten.
Der Netzwerkmanagementprozessor 904 könnte sodann auf das Anfragepaket
reagieren mit einer Datenbank, basierend auf der Kanalnummer und
der Knotennummer in dem markierten Anfragepaket.
-
In
der vorstehend beschriebenen Implementierung, die auf dem modifizierten
RARP-Protokoll basiert, wurden die Punkt-zu-Punkt-Kanäle unter Verwendung
einer PPP-Verbindung implementiert, so dass der physikalische Anschluss
an dem zentralen Knoten 900 als eine Basis für das Konfigurieren von
IP-Adressen verwendet werden kann. Diese Knotennummer wird zusammen
mit dem Paket an den Prozessor in dem zentralen Knoten auf bekannte Art
und Weise weitergegeben.
-
Andere
Systeme können
mehr als einen Kanal für
einen gegebenen physikalischen Anschluss auf dem zentralen Knoten
implementieren. Beispielsweise kann ein Frameverzögerungssystem
auf einer gegebenen Verbindung verwendet werden. In einem solchen
System wird die DLCI (Datenlinkkommunikationsidentifizierung; data
link communication identifier) mit jedem Paket auf jeder logischen
Verbindung zwischen zwei Punkten in dem Netzwerk getragen. Ein Netzwerk
des Typs X.25, das virtuelle Wählschaltungen
verwendet, kann ebenso über
einen bestimmten physikalischen Anschluss auf dem zentralen Knoten 900 verbunden
werden. In einem solchen System kann die X.25-Adresse der anrufenden
Vorrichtung als Basis für
die Spezifizierung des Punkt-zu-Punkt-Kanals verwendet werden. Ebenso könnte ein
ISDN-Anschluss die eindeutige Identifizierung für den anrufenden Knoten (Q.931-Adresse) verwenden,
die für
eine Einleitung des Anrufs verwendet wird.
-
Folglich
stellt die vorliegende Erfindung die Fähigkeit bereit, neue Blattknoten
einem Netzwerk hinzuzufügen,
ohne dass es für
den Netzwerkmanager nötig
ist, die physikalische Netzwerkadresse des Blattknotens zu kennen,
bevor dieser mit dem Netzwerk verbunden wird. Dies erleichtert den
Vorgang, neue Blattknoten dem Netzwerk hinzuzufügen, bedeu tend, minimiert die
Möglichkeit
eines Fehlers bei der Kommunikation der physikalischen Netzwerkadressen
an den Netzwerkmanager und trägt
andernfalls zu dem erwünschten "Plug and Play"-Aspekt der Blattknotenhardware
bei.