-
Die
Erfindung betrifft in erster Linie ein Verfahren zur Verwaltung
und Aktualisierung von Konfigurationsdaten, die bestimmte Operationscharakteristiken
der Elemente eines Kommunikationsnetzwerks festsetzen. Insbesondere
betrifft die Erfindung das Verfahren zur Verwaltung und Aktualisierung
von Konfigurationsdaten von Netzwerkelementen in einem xDSL-Netzwerk.
-
Die
Abkürzung
xDSL steht kollektiv für
eine Reihe verschiedener DSL- (Digital Subscriber Line) Technologien,
die darauf hinzielen, das Übertragungsvermögen normaler
Kupferleitungen in höchstmöglichem
Ausmaß zu
nutzen. Bekannte Variationen, die unter dem Oberbegriff xDSL geführt werden, haben
das Prioritätsdatum
dieser Patentanwendung ADSL (Asymmetric Digital Subscriber Line),
CDSL (Consumer DSL, eingetragenes Warenzeichen der Rockwell International
Corp.), G.Lite (auch bekannt unter DSL Lite, verteilerloses ADSL
und Universal ADSL; offiziell ITU-T Standard G-992.2), HDSL (DSL mit
hoher Bit-Rate), RADSL (DSL mit angepasster Datentransfergeschwindigkeit),
SDSL (symmetrisches DSL), VDSL (DSL mit sehr hoher Datenrate), und
sogar bis zu einem gewissen Ausmaß UDSL (DSL mit Simplexverkehr),
welches lediglich ein Entwurf ist und IDSL (ISDN DSL), welches de
facto näher
am ISDN ((Integrated Services Digital Network) liegt.
-
1 stellt
hier die vertraute hierarchische Struktur eines xDSL-Netzes dar.
In dieser Beschreibung nennen wir die Strukturebenen als Ebene 1, Ebene
2, und Ebene 4. Ebene 1 umfaßt
die Nutzer-Endgeräte,
von denen Gerät 101, 102, 103, 104, 105 und 106 in 1 gezeigt
sind. Die Geräteanzahl
kann in Ebene 1 eines vollkommen ausgebauten xDSL-Netzes sehr hoch
sein, da zumindest für
jeden Abonnenten ein Nutzer-Endgerät vorhanden ist. Aufgabe eines
Nutzer-Endgeräts
ist, als ein Gateway zwischen der xDSL-Route 107 und dem
nutzereigenem lokalen Netzwerk zu fungieren. Der Begriff „lokales
Netzwerk" sollte
im weitesten Sinn so verstanden werden, dass auch ein einzel ner
Rechner beim Nutzer dabei abgedeckt ist. Auf Ebene 2 befinden sich die
xDSL-Schalter der untersten Ebene, die in direktem Kontakt mit den
Nutzer-Endgeräten
stehen und konzentriert die Verbindungen zu und von diesen in ein „Backbone"-Netzwerk. Die xDSL-Schalter 111, 112 und 113 sind
dargestellt. Die Anzahl der xDSL-Schalter der untersten Ebene ist
weiterhin relativ hoch; es können
z. B. je Schalter der untersten Ebene 30 Nutzer-Endgeräte vorhanden
sein.
-
Ebene
3 umfaßt
den xDSL-Schalter der höheren
Ebene 121, der als Multiplexer/demultiplexer zwischen Verbindung 114 zu
verschiedenen xDSL-Schalter der untersten Ebene und einem Hochleistungsverbindungsnetz 122 wie
ein ATM- (Asynchronous Transfer Mode) Netzwerk dient. Die xDSL-Schalter
kennt man auch als DSLAM's
(DSL Access Multiplexer). Die Anzahl der hierarchischen Ebenen,
die xDSL-Schalter enthalten, ist normalerweise nicht beschränkt, ist
jedoch abhängig
von solchen Faktoren wie geographischer Wirkungsbereich des Netzwerks,
Anzahl der Abonnenten und allgemeiner Architektur des Netzwerks.
-
Ebene
4 umfaßt
eine oder mehrere Netzmanagement-Stationen 131, welche
die Aufgabe haben, die Datenbanken 132 der Konfigurationsdaten
aller Netzwerkelemente des xDSL-Netzes zu verwalten. Eine Netzmanagement-Station 131 bietet
auch die Mittel für
den Netzwerkoperator die Operationen des gesamten xDSL-Netzwerks
zu managen und zu kontrollieren. In einem kleinen xDSL-Netzwerk
kann einer der xDSL-Schalter (DSLAM) auch als Netzmanagement-Station
fungieren.
-
Zusätzlich zu
den in 1 gezeigten sogenannten aktiven Netzwerkelementen
kann ein xDSL-Netzwerk auch weitere Geräte, wie Zwischenverstärker und
Verstärker,
beinhalten. Diese sind allerdings in der DSL-Technologie als „passive" Geräte bekannt
und sind aus Sicht der vorliegenden Erfindung nicht von Bedeutung.
-
Konfigurationsdaten
sind ein Allgemeinbegriff, der alle solche Informationen abdeckt,
die ein aktives Netzwerkelement in einem xDSL-Netzwerk erfordert,
um seine Aufgaben im Netzwerk funktionell einwandfrei ausführen zu
können.
Der Wirkungsbereich des Begriffs „Konfigurationsdaten" ist nicht unbedingt
als auf den vorliegenden Patentantrag beschränkt zu verstehen, da die Erfindung
sowohl für am
Prioritätsdatum
der Anwendung bekannte Konfigurationsdaten dieser Patentanwendung
wie auch für
zukünftige
Erweiterungen des Konzepts anwendbar ist. Ein Nutzer-Endgerät z. B.
muß wissen,
wie das lokale Netzwerk des Nutzers mit der Außenwelt verbunden ist und welche
Einschränkungen
sich zur Kommunikation über
den xDSL-Anschluss
eignen. Die xDSL-Schalter der untersten Ebene müssen wissen, welche Abonnenten
angeschlossen sind und welche Dienste und welche Übertragungsraten
zu den einzelnen Abonnenten bereitgestellt werden sollen. Ebenso
müssen
die xDSL-Schalter
höherer
Ebenen wissen, mit welchen Elementen unterer Ebenen sie kommunizieren
und welche Charakteristiken die einzelnen Verbindungen haben.
-
In
einem xDSL-Netz gemäß früherer Verfahren,
wie in 1 dargestellt, war üblich, sämtliche Konfigurationsdaten
zentral in Datenbank 132 abzulegen. Änderungen der Konfigurationsdaten
erforderte den Eingriff durch einen Fachmann, der an der Netzmanagement-Station 131 sitzt
und die Kommandos der Konfigurationsänderungen eingibt. Jedes Mal,
wenn ein Netzwerkelement neu konfiguriert werden muß oder ein
Netzwerkelement zurückgestellt werden
muß zu
einem, vorher vorhandenen, aber zwischenzeitlich nicht verfügbaren Teil
der Konfigurationsdaten, muß das
Netzwerkelement eine Kommunikationsverbindung zur Netzmanagement-Station herstellen.
Im schlimmsten Fall kann die Konfiguration eines Netzwerkelementes
nicht geändert
oder wiederhergestellt werden, bevor eine Person sich der Angelegenheit
an der Netzmanagement-Station angenommen und die erforderlichen
Maßnahmen
ergriffen hat. Ein einfacher Fehler auf Ebene 4 kann das gesamte
xDSL-Netzwerk stillegen, weil die Konfigurationsdaten nicht bereitgestellt
werden können.
-
Frühere Veröffentlichungen
zu diesem technischen Bereich beinhalten S. Sethi, P. Kalyanasundaram,
C.M. Sherwin and D. Zhu: "A
hierarchical management framework for battlefield network management", Milcom 97 Proceedings,
Monterey, Ca., USA, 2–5
Nov. 1997, IEEE New York, USA, pp. 1239–1243; ebenso wie die Patentveröffentlichungen WO-A-9903255,
US-A-6108350 und WO-A-9859462. Von diesen beschreiben die zuerst Aufgeführten eine
ansteigende Anzahl der Ebenen in einem SNMP Kommunikationsnetzwerkmodell
mit einer angeschlossenen Einführung
der Netzwerkmanagement Merkmalen zu den Zwischenebenen in der Netzwerk-Hierarchie.
Die vorliegenden Patentveröffentlichungen
decken entsprechend eine Trennung von lokalen und peripheren Seiten
eines aktiven Anschlußpunktes
auf, Konsolidierung der verwendeten Protokolle in einer Multi-Protokoll-Netzwerkumgebung
und die vorbereitende Öffnung
alternativer Routen durch ein Netzwerk.
-
Es
ist Zielsetzung des vorliegenden Patents, eine Methode und die dazugehörige Hardware
zu bieten, um Konfigurationsdaten eines xDSL-Netzes zu verwalten
und zu aktualisieren ohne die oben aufgeführten Probleme früherer Lösungen.
-
Die
Objekte der Erfindung wurden erreicht durch Distribution von Ablage
der Konfigurationsdaten in hierarchischen Ebenen im xDSL-Netzwerk.
Bestimmte Gesichtspunkte der Erfindung wurden auch erreicht durch
Definierung beschränkte
Zugriffsrechte für
Verwaltung und Aktualisierung der Konfigurationsdaten und Vergabe
solcher beschränkter
Zugriffsrechte an die Netzwerkelemente sowie die Regelung zur Überprüfung solcher
Berechtigungen vor Durchführen
irgendwelcher Änderungen
der Konfigurationsdaten, die bis dahin Gültigkeit hatten.
-
Erster
Gesichtspunkt der Erfindung ist eine Methode, Konfigurationsdaten
in einem xDSL-Netzwerk zu verteilen, das Netz werkelemente in verschiedenen
hierarchischen Ebenen und eine Netzmanagement-Station enthält. Die
Methode gemäß erstem
Gesichtspunkt der Erfindung ist beschrieben im Beschreibungsabschnitt
der unabhängigen
Ansprüche,
die sich auf eine derartige Methode beziehen.
-
Zweiter
Gesichtspunkt der Erfindung ist eine Methode, Konfigurationsdaten
in einem Netzwerkelement eines xDSL-Netzwerks herbeizuführen, das Netzwerkelemente
in verschiedenen hierarchische Ebenen enthält. Die Methode gemäß zweitem
Gesichtspunkt der Erfindung ist beschrieben im Beschreibungsabschnitt
der unabhängigen
Ansprüche, die
sich auf eine derartige Methode beziehen.
-
Dritter
Gesichtspunkt der Erfindung ist eine Methode, Änderungen der Konfigurationsdaten
in einem xDSL-Netzwerk, das Netzwerkelemente in verschiedenen hierarchischen
Ebenen und eine Netzmanagement-Station enthält, herbeizuführen. Die Methode
gemäß drittem
Gesichtspunkt der Erfindung ist beschrieben im Beschreibungsabschnitt
der unabhängigen
Ansprüche,
die sich auf eine derartige Methode beziehen.
-
Vierter
Gesichtspunkt der Erfindung ist ein Netzwerkelement eines xDSL-Netzwerks.
Ein Netzwerkelement gemäß viertem
Gesichtspunkt der Erfindung ist beschrieben im Beschreibungsabschnitt der
unabhängigen
Ansprüche,
die sich auf ein Netzwerkelement beziehen.
-
Fünfter Gesichtspunkt
der Erfindung ist ein xDSL-Netzwerk. Ein Netzwerk gemäß fünftem Gesichtspunkt
der Erfindung ist beschrieben im Beschreibungsabschnitt der unabhängigen Ansprüche, die
sich auf ein Netzwerk beziehen.
-
Im
Sinne der Erfindung gehen wir davon aus, dass für die elektronische Speicherung
von Konfigurationsdaten und Konfigurationsbefehlen ein allgemein
anerkanntes Format besteht. In diesem Format (oder einem Übermittlungsformat
diesem nahe stehendes) ist möglich,
Konfigurationsdaten und Konfigurationsbefehle zwischen aktivem Netzwerkelement
und einem xDSL-Netzwerk
auszutauschen. Jedes Netzwerkelement hat seine eigenen lokal in
einem geeigneten Speicher abgelegten Konfigurationsdaten. Der Erfindung
gemäß speichert
auch eine Anzahl von in der xDSL-Hierarchie oberhalb eines Netzwerkelementes
eines Netzwerkes angeordneten, nicht aber die Funktion des aktuellen
Netzmanagement einbindenden anderen Netzwerkelementen eines Netzwerks,
Konfigurationsdaten bezüglich eines
bestimmten Netzwerkelementes. Dadurch ist für ein Netzwerkelement möglich, Konfigurationsdaten
höherer
Ebenen zu empfangen, ohne überhaupt mit
der Netzmanagement-Station zu kommunizieren.
-
Einem
Gesichtspunkt der Erfindung gemäß ist möglich, Änderungen
der Konfigurationsdaten auch auf anderen Ebenen der xDSL-Hierarchie als der
Netzmanagement-Ebene vorzunehmen. Um die Kontrolle über solche Änderungen
aufrecht zu erhalten, gibt es bestimmte Vollmachten, die festlegen, wer
welche Änderungen
vornehmen darf. Änderungen,
die in einer niedrigeren Ebene vorgenommen sind, werden in alle
erforderlichen Richtungen, die Kommunikationsänderungen zu höheren Ebenen
der Netzwerk-Hierarchie mit einschließen, übertragen. Ein Schutz gegen
unautorisierte Versuche, an anderen Netzwerkelementen Teile der
Konfigurationsdaten zu ändern,
wie Änderungen
der Konfigurationsdaten, die scheinbar ohne ordnungsgemäße Autorisation
vorgenommen sind, ist sehr einfach durch Abweisung gegeben.
-
Empfängt ein
Netzwerkelement der Erfindung gemäß eine Anforderung von Konfigurationsdaten
von einer niedrigeren Ebene der Hierarchie, überprüft es zuerst, ob sich das die
Anforderung stellende Gerät
auf einer Liste bekannter Netzwerkelemente niedrigerer Ebene befindet.
In diesem Fall hat das die Anforderung empfangende Gerät die Möglichkeit,
die Anforderung weiter höher
zu einer Netzmanagement-Station zu übermitteln, oder aus seinem
Speicher einen Satz früher
als vom die Anforderung ausgebenden Gerät, gerätebezogen abgelegter Konfigurationsdaten
auszulesen. Die Zusammenstellung der Erfindung enthält verschiedene
Vorgaben, die ein eine Anforderung empfangendes Gerät für die Entscheidungsfindung
befolgen kann. War das die Anforderung sendende Gerät früher nicht
bekannt, existiert kein Satz früher
gerätespezifisch
abgelegter Konfigurationsdaten. In einem solchen Fall kann eine Ersatzkonfiguration
eingesetzt werden.
-
Das
oben beschriebene System paßt
sich automatisch an sowohl in einer Situation, in der ein Netzwerkelement
nach einer Weile der Inaktivität
einschaltet und lediglich ein Satz früher abgelegter Konfigurationsdaten
neu geladen werden muß,
oder in einer Situation,
in der ein neues Gerät an das
Netzwerk angeschlossen wird ohne frühere Kenntnis seiner Existenz
im Netzwerk. Das System arbeitet einwandfrei sogar im Falle, dass
Netzwerkgerät
von seinem bisherigen Standort im Netzwerk getrennt und an einen
anderen Standort im Netzwerk verlegt wird. Das System ist skalierbar
auf unterschiedliche Netzwerkgrößen und -architekturen
und setzt für
zukünftige
Ergänzungen nur
geringe Einschränkungen
an Inhalte oder Handhabung der Konfigurationsdaten.
-
Die
neuen Eigenschaften, die als charakteristisch für die Erfindung anzusehen sind,
sind im Einzelnen in den beigefügten
Patentansprüchen
vorgebracht. Die Erfindung selbst jedoch ist sowohl in Konstruktion
als auch in Operationsweise, zusammen mit zusätzlichen Objekten und Vorteilen
dieser, am besten verständlich
aus der folgenden Beschreibung im Zusammenhang mit den beiliegenden
Zeichnungen der spezifischen Zusammenstellung:
-
1 zeigt
ein xDSL-Netzwerk bekannter Art;
-
2 zeigt
schematisch die Speicherung der Konfigurationsdaten gemäß der Zusammenstellung
der Erfindung;
-
3 zeigt
ein Verfahren für
die Anforderung der Konfigurationsdaten;
-
4 zeigt
ein Verfahren, Anforderungen der Konfigurationsdaten zu behandeln;
-
5 zeigt
beispielhaft die Struktur einer Mitteilung;
-
6 zeigt
ein weiteres Verfahren für
eine Anforderung der Konfigurationsdaten;
-
7 zeigt
ein weiteres Verfahren für
die Anforderung von Konfigurationsdaten im Beispiel;
-
8 zeigt
ein weiteres Verfahren für
die Anforderung der Konfigurationsdaten;
-
9 zeigt
einen Prozeß der
Handhabung der Konfigurationsdaten; und
-
10 zeigt
beispielhaft eine weitere Struktur einer Mitteilung.
-
Die
in der oben beschriebenen 1 bisheriger
Art zeigt, dass die nachfolgende Beschreibung der Erfindung und
deren vorteilhaften Zusammenstellung ersichtlich wird in den 2 bis 10.
-
2 zeigt
schematisch einen Teil eines xDSL-Netzwerks, in dem die aktiven
Elemente X201, Y202 und Z203, die zu einer bestimmten Ebene N der
Netzwerk-Hierarchie gehören.
Dabei ist N ein positiver Integerwert. An der nächsthöheren Ebene, die (N+1)-Ebene
ist, ist dann das Aktivelement A211, das mit den Elementen X, Y
und Z verbunden ist. Abhängig
vom Wert N können
sich unterhalb der Ebene N niedrigere Ebenen und höhere Ebenen
oberhalb der Ebene N+1 befinden.
-
Jedes
der aktiven Elemente X, Y, Z und A hat einen Konfigurationsspeicher 251, 261, 271 bzw. 281.
In jedem der Konfigurationsspeicher ist ein Eingang 252, 262, 272 oder 282 bzw.
für das
Speichern der eigenen Konfigurationsdaten des jeweiligen aktiven
Netzwerkelementes. Gemäß eines
Gesichtspunkts der Erfindung enthalten die Konfigurationsspeicher
jedes aktiven Netzwerkelementes ferner den Teil 253, 263, 273 oder 283 bzw.
für Speichereingänge, die
Konfigurationsdaten anderer Netzwerkelemente, speziell solcher anderer
Netzwerkelemente, die in der Netzwerk-Hierarchie unter niedriger
als das die Konfigurationsdaten speichernde Netzwerkelement.
-
Am
Prioritätsdatum
dieser Patentanwendung wird als höchst tauglich angesehen, wenn
jedes aktive Netzwerkelement in der Lage ist, zusätzlich zu den
eigenen die Konfigurationsdaten all jener Netzwerkelemente, die
unterhalb dieser in der nächstniedrigen
oder sogar noch niedrigerer Ebene in der Netzwerk-Hierarchie liegen,
zu speichern. Wir könnten
die Zusammenstellung der Erfindung als eine solche „alles
weiter unterhalb" bezeichnen.
Jedoch findet die Erfindung auch eine auch bestimmte, begrenzte
Einsetzbarkeit in einer „nur
die nächstniedrige" Zusammenstellung,
in der jedes aktive Netzwerkelement zusätzlich zu den eigenen die Konfigurationsdaten
all jener Netzwerkelemente, die unterhalb dieser in der unmittelbar
nächstniedrigen
oder noch niedrigerer Ebene in der Netzwerk-Hierarchie liegen, zu
speichern. Variationen zwischen „alles weiter unterhalb" und „nur die
nächstniedrige" sind möglich: z. B.
in einer „nur
N niedriger" Zusammenstellung
jedes aktive Netzwerkelement würde
die Konfigurationsdaten lediglich jener Netzwerkelemente speichern,
die nicht weiter als N Ebenen unterhalb von dieser in der Netzwerk-Hierarchie liegt,
in der N ein positiver Integerwert größer als eins ist. Später in dieser
Beschreibung werden wir de tailliert analysieren, welchen Weiteneffekt
die Speicherung der Konfigurationsdaten auf Netzwerkelemente niedrigerer
Ebene hat.
-
3 ist
ein simplifiziertes Flussdiagramm, das die Operation des Netzwerkelementes
in einer Situation zeigt, in der es sich selbst neu konfigurieren muß. Ein Netzwerkelement,
das die Methode der 3 ausführt, kann irgendwo auf Ebene
1, 2 oder 3 der in 1 gezeigten Netzwerk-Hierarchie
bekannter Art positioniert sein. Bei Schritt 301 stellt
es fest, dass es einige Konfigurationsdaten benötigt. Solch eine Feststellung
tritt typischerweise beim Einschalten auf, wobei das Netzwerkelement
vorübergehend
ausgeschaltet war und beabsichtigt, normal weiter zu arbeiten. Schritt 301 kann
ebenfalls auftreten, wenn in einem Satz lokal abgelegter Konfigurationsdaten
einen z. B. durch eine Fehlfunktion bedingten Fehler auffindet oder
bedingt durch irgendein anderes Ereignis, das Netzwerkelement veranlaßt, ein erneutes
Laden der Konfigurationsdaten zu erwägen. Bei Schritt 302 übermittelt
das Netzwerkelement eine Anforderung für ein Konfigurationselement
an ein Netzwerkelement, typischerweise an das Netzwerkelement, das
in der Netzwerk-Hierarchie sich unmittelbar oberhalb befindet und
mit dem es bei Normalbetrieb des Netzwerks eine Kommunikationsverbindung
hat. Bei Schritt 303 prüft
das Netzwerkelement, ob es vom Netzwerkelement, an das eine Anforderung übermittelt
war, eine Antwort erhalten hat. Steueruhr, Bildzähler und sonstige Einrichtungen,
können als
solche bekannt installiert sein, so dass das Netzwerkelement bezüglich Schritt 303 keine
Entscheidung sofort treffen muß,
sondern nur nach Warten einer bestimmten Wartezeit. Die geeignete
Länge dieser
Wartezeit ist durch Versuche zu bestimmen.
-
Erhält das Netzwerkelement
eine Antwort mit einem neuen Satz Konfigurationsdaten vom oberhalb dessen
befindlichen Netzwerkelement, mit dem kommuniziert hatte, speichert
es lokal diesen neuen Satz Konfigurationsdaten bei Schritt 304.
Wurde ein Antworteingang nicht gefunden, bezieht es sich auf früher gespeicherte
Konfigurationsdaten. Es ist von Vorteil, über einen nichtflüchtige Speicher
in jedem aktiven Netzwerkelement für die Speicherung von Konfigurationsdaten
zu verfügen,
auch in Zeiten in ausgeschaltetem Zustand. Bezogen auf früher abgelegte Konfigurationsdaten
kann in Fällen
von Auftreten von Fehlern in der Betriebsdatei auch die Rückkehr zu
einer Art Sicherheitskopien früherer
Konfigurationsdaten bedeuten. Gleichgültig, ob das Netzwerkelement eine
Anforderung erhalten hat oder nicht, liest es die gespeicherten
Konfigurationsdaten in Schritt 305 und startet diese in
Schritt 306.
-
4 ist
ein simplifiziertes Flussdiagramm, das die Operation des Netzwerkelements
zeigt in einer Situation, in der es von einem Netzwerkgerät niederer
Ebene in der Netzwerk-Hierarchie
eine Anforderung erhält.
Die bekannte Hierarchiestruktur gemäß 1 bedeutet,
dass die Operation eines aktiven Netzwerkelements auf Ebene 2 oder
Ebene 3 in Betracht gezogen wird.
-
In
Schritt 401 erhält
das Netzwerkelement eine Anforderung für die Konfigurationsdaten.
Für den
Zweck, in die Anforderungsmitteilung eine Liste der jener Netzwerkelemente,
die es angewendet haben, zu implementieren, fügt das Netzwerkelement In Schritt 402 in
die Anforderung eine eigene einmalige Identifizierungskennung hinzu.
Ein schematisches Beispiel einer Anforderungsmitteilung ist in 5 gezeigt:
die Mitteilung 500 enthält
eine Mitteilung vom Typ Feld 501, die anzeigt, dass es
sich um eine Anforderung für
Konfigurationsdaten handelt, eine Ausgangsstations-ID Feld 502 für das Enthalten
einer einmaligen Identifizierungskennung des Netzwerkelements, das
die Konfigurationsdaten benötigt und
ursprünglich
eine Anforderung übermittelt
hat, ein „handled
by"-Feld 503 für Innehaltung,
bevorzugt sequentiell, die einmalige Identifizierungskennung der
Geräte,
die die Anforderung bearbeitet haben, seitdem sie ursprünglich übermittelt
wurde, und möglicherweise
das CRC-(Cyclic Redundancy Check) Feld 504 für das Innehalten
einer Kontrollsumme, die ein empfangendes Gerät einsetzen kann in gleicher Weise,
wie bekannt zum Prüfen,
ob Übertragungsfehler
aufgetreten sind. Wird eine Kontrollsumme verwendet, muß diese
jedes Mal neu berechnet werden, wenn eine neue Geräte-Identifizierungszahl
in das „handled
by"-Feld 503 hinzugefügt wurde,
es sei denn, dieses Feld wurde in der Kette ausgelassen, aus der
die Kontrollsumme berechnet wurde. Die Mitteilungsstruktur in 5 ist
beispielhaft und schränkt
den Einsatzbereich oder die Eignung der Erfindung nicht ein: z.
B. keinerlei gesonderte Ausgangsstations-ID oder „handled
by"-Feld benötigt, wenn
wir akzeptieren, dass die erste (oder letzte) Geräte-Identifikation
in einem „handled
by"-Feld stets die
Ausgangsstations-Identifizierung ist. Es kann auch ein Feld für die Identifizierungskennung
des beabsichtigten letzten Empfängers
geben, welcher eine Netzwerkmanagement-Station ist. Solch eine Identifizierungskennung
wird nicht benötigt,
falls in dem Netzwerk eine eindeutig definierte Netzwerkmanagement-Station
für jeden
Zweig der baumartigen Netzwerkstruktur existiert.
-
Im
Schritt 403 übermittelt
das Netzwerkelement die Anforderung, welche jetzt auch die einzigartige
Identifizierungskennung beinhaltet, die ihm im Schritt 403 hinzugefügt wurde,
weiter hoch in der Netzwerkhierarchie. Vorzugsweise übermittelt
das Netzwerkelement die Anforderung im Schritt 403 zu dem
Netzwerkelement, das unmittelbar über ihm in der Netzwerkhierarchie
ist und mit welchem es während
des normalen Betriebs des Netzwerks eine Kommunikationsverbindung
hat. Im Schritt 404 prüft das
Netzwerkelement, ob es eine Antwort von dem Netzwerkelement, zu
welchem es die Anforderung weitergeleitet hat, erhalten hat. Zeitgeber,
Rahmenzähler
oder andere Anordnungen, die für
solches bekannt sind, können
wieder verwendet werden, so dass das Netzwerkelement die auf Schritt 404 bezogene
Entscheidung nicht sofort macht, sondern nur nachdem es für eine bestimmte
Verzögerungszeit gewartet
hat. Die geeignete Länge
für eine
solche Verzögerungszeit
kann wieder durch Experimentieren bestimmt werden.
-
Wenn
das Netzwerkelement von einem Element aus einer höheren Ebene,
mit dem es kommuniziert hat, eine Antwort erhalten hat, die einen
neuen Satz von Konfigurationsdaten für das Element der niedrigeren
Ebene, das die Ausgangsstation der Anforderung war, enthält, speichert
es die neuen Konfigurationsdaten im Schritt 405. Normalerweise
werden die Konfigurationsdaten im Schritt 405 in dem Teil
des Konfigurationsspeichers des Netzwerkelements gespeichert, der
gespeicherte Kopien der Konfigurationsdaten der anderen Netzwerkelemente enthält (siehe 253, 263, 273 und 283 in 2).
Die gespeicherten Konfigurationsdaten werden markiert (indiziert)
mit der einzigartigen Identifizierungskennung des Netzwerkelements
der niedrigeren Ebene, das die Ausgangsstation der Anforderung war.
Das Netzwerkelement, dessen Betrieb in 4 beschrieben
ist, hat diese Identifizierungskennung ursprünglich mit der Anforderung
erhalten, die es im Schritt 401 von einer niedrigeren Ebene
erhalten hat. Dieselbe Identifizierungskennung sollte auch in der
Antwort erscheinen, deren Empfang einen Übergang vom Schritt 404 zu
Schritt 405 verursacht. Im Schritt 406 liest das
Netzwerkelement die gespeicherten Konfigurationsdaten und im Schritt 407 übermittelt
es sie weiter herunter in der Netzwerkhierarchie zu dem Netzwerkelement,
das ursprünglich
nach neuen Konfigurationsdaten gefragt hat.
-
Wenn
das Netzwerkelement im Schritt 404 keine Antwort von einer
höheren
Ebene empfängt, prüft es im
Schritt 408, ob die einzigartige Idientifizierungskennung
in dem Ausgangsstations-ID-Feld der Anfrage bekannt war in dem Sinne,
dass ein Satz von Konfigurationsdaten vorher abgespeichert wurde
und indiziert wurde mit dieser Identifizierungskennung. Sofern das
Ergebnis dieser Überprüfung positiv
ist, liest das Netzwerkelement die vorher gespeicherten Element-spezifischen
Konfigurationsdaten aus dem Speicher im Schritt 406 und übermittelt
sie in Schritt 407, wie es es getan hätte mit Konfigurationsdaten, die
es in einer Antwort empfangen hätte.
-
Falls
im Schritt 408 herausgefunden wurde, dass das Ausgangsstations-ID-Feld
der Anfrage eine zuvor unbekannte Element-Identifizierungskennung enthält, liest
das Netzwerkelement im Schritt 409 vorgegebene Konfigurationsdaten
von einem geeigneten Speicherort und verwendet diese als die Konfigurationsdaten,
die es im Schritt 407 nach unten übermittelt.
-
6 ist
ein vereinfachtes Flußdiagramm, das
den Betrieb einer Netzwerkmanagement-Station in einer Situation
darstellt, in welcher sie eine Anforderung bezüglich Konfigurationsdaten von
einem Netzwerkelement erhält,
das sich in der Netzwerkhierarchie unter ihr befindet. Im Schritt 601 empfängt die Netzwerkmanagement-Station
eine Anfrage nach Konfigurationsdaten. Im Schritt 602 überprüft sie,
ob die einzigartige Identifizierungskennung in dem Ausgangsstations-ID-Feld der Anfrage
bekannt ist in dem Sinn, dass ein Satz von Konfigurationsdaten zuvor
gespeichert wurde und indiziert wurde in der Datenbank der Netzwerkmanagement-Station
mit dieser Identifizierungskennung, das heißt, ob die Ausgangsstation
der Anfrage ein bekanntes Element ist, das schon jemals irgendwo
in dem xDSL-Netzwerk aktiv gewesen ist, das von der Netzwerkmanagement-Station
gesteuert wird. Sofern das Ergebnis der Überprüfung positiv ist, liest die
Netzwerkmanagement-Station die zuvor gespeicherten Element-spezifischen
Konfigurationsdaten aus der Datenbank im Schritt (603)
und übermittelt
sie im Schritt 604 abwärts
in der Netzwerkhierarchie in einer Mitteilung, die Konfigurationsdaten-Antwort-Mitteilung genannt werden
kann. Eine beispielhafte Form dieser Mitteilung ist schematisch
in 7 dargestellt.
-
Die
Mitteilung 700 der 7 umfasst
ein Mitteilungstyp-Feld 701 zum
Aufnehmen einer Typ-Identifizierung, die besagt, dass die Mitteilung
eine Konfigurationsdaten-Antwort-Mitteilung
ist. Sie umfaßt auch
ein Quell-ID-Feld 702 zur Aufnahme der einzigartigen Identifizierungkennung
des Netzwerkelements, das die Mitteilung erzeugt hat, das heißt, von der
Datenbank, von welcher die Konfigurationsdaten, die in der Mitteilung übermittelt
werden, gelesen wurden. Es gibt auch ein Ziel-ID-Feld 703 zur
Aufnahme der einzigartigen Identifizierungskennung des Netzwerkelements,
das als letzter Empfänger
der Konfigurationsdaten vorgesehen ist. Die eigentlichen Konfigurationsdaten
sind in einem eigenen Feld 704 enthalten. Zum Zweck des
richtigen Routings der Mitteilung zu ihrem letzen Empfänger ist
es vorteilhaft, in der Mitteilung ein Laufweg-ID-Liste-Feld 705 zu
haben, dass sequentiell die einzigartigen Identifizierungskennungen
der Netzwerkelemente enthält, durch
welche die Mitteilung übermittelt
wird. Die Netzwerkmanagement-Station kann den Inhalt des Laufweg-ID-Liste-Felds 705 am
einfachsten erhalten, indem sie die Identifizierungskennungen aus
dem „bearbeitet
von"-Feld in der
Anforderungsmitteilung, die sie erhalten hat, liest. Jedoch ist
es auch möglich, dass
sie eine Element-spezifischen Antwort-Route für die Übermittlung von Konfigurationsdaten-Antwort-Mitteilungen
für jedes
Netzwerkelement abgespeichert hat. In solch einem Fall muß der Inhalt
des Laufweg-ID-Liste-Felds 705 nicht
dieselbe Route definieren, durch welche die Anforderungsmitteilung kam.
Es ist auch möglich,
ein CRC (Cyclic Redundancy Check)-Feld 706 als einen Teil
der Mitteilung 700 zu verwenden, um eine Prüfsumme aufzunehmen,
die ein Empfangselement in einer dafür bekannten Weise verwenden
kann, um zu überprüfen, ob
irgendwelche Übermittlungsfehler
aufgetreten sind. Die Mitteilungsstruktur, die in 7 gezeigt
ist, begrenzt nicht den Bereich und die Anwendbarkeit der Erfindung,
da viele andere alternative Strukturen verwendet werden können, um
den gleichen technischen Effekt zu erzielen.
-
Die
Netzwerkmanagement-Station kann im Schritt 602 herausfinden,
dass das Netzwerkelement, das nach den Konfigurationsdaten gefragt
hat, ein „neues" Netzwerkelement
ist. Dies bedeutet, dass die Netzwerkmanagement-Station keine vorher gespeicherten
Konfigurationsdaten findet, die mit der Element-Identifizierungskennung indiziert worden wären, die
in dem Ausgangsstations-ID-Feld der Anforderungsmitteilung erschei nen.
In diesem Fall tritt ein Übergang
vom Schritt 602 zum Schritt 605 auf, bei welchem
die Netzwerkmanagement-Station vorgegebene Konfigurationsdaten aus
einem geeigneten Speicherort ausliest. Im Schritt 606 kopiert
die Netzwerkmanagement-Station die vorgegebenen Konfigurationsdaten
in die Datenbank und indiziert sie mit der „neuen" Element-Identifizierungskennung. In anderen
Worten erzeugt die Netzwerkmanagement-Station einen neuen Datenbankeintrag
für das Netzwerkelement,
das nach den Konfigurationsdaten gefragt hat. Danach liest sie die
gespeicherten Konfigurationsdaten im Schritt 603 und übermittelt
sie im Schritt 604, wie sie es getan hätte mit Konfigurationsdaten,
die in der Datenbank schon vorhanden waren, als die Anforderung
eintraf.
-
Bevor
die Netzwerkmanagement-Station fortfährt, vorgegebene Konfigurationsdaten
für ein neues
Netzwerkelement auszugeben, kann sie bestimmte Überprüfungen durchführen, um
sicherzugehen, dass das neue Netzwerkelement in dem Netzwerk akzeptiert
werden kann. Zum Beispiel kann die Netzwerkmanagement-Station überprüfen, ob
die gleiche Element-Identifizierungskennung, die in dem Ausgangsstations-ID-Feld
der Anforderungsmitteilung erscheint, schon von einem anderen, offensichtlich
aktiven Netzwerkelement reserviert wurde. Mit „offensichtlich aktiv" meinen wir, dass
das besagte Auftauchen der Element-Identifizierungskennung in der Datenbank
der Netzwerkmanagement-Station nicht bedeutet, dass tatsächlich das
gleiche Netzwerkelement, das die Ausgangsstation der Anforderung ist,
zuvor an einem anderen Ort (location) in dem Netzwerk war, von welchem
es jetzt entfernt sein sollte, weil es Konfigurationsdaten an einem
neuen Ort anfordert. Zusätzlich
oder alternativ kann die Netzwerkmanagement-Station überprüfen, ob
die Element-Identifizierungskennung zu einer bestimmten vorgegebenen
Gruppe von erlaubten Identifizierungskennungen gehört, das
heißt,
ob die Element-Identifizierungkennung die Definitionen eines akzeptierbaren
Element-Identifizierungskennungs-Raums
befolgt. Es können
auch Beschränkungen
vorhanden sein, welche vorgeben, welche Netzwer kelemente an welchen
Orten in dem Netzwerk erlaubt sind, so dass die Überprüfungen, die von der Netzwerkmanagement-Station durchgeführt werden,
eine Überprüfung beinhalten,
in welcher sie überprüft, ob es
dem Netzwerkelement, das die Konfigurationsdaten anfordert, um an
einem bestimmten Ort zu operieren, gestattet ist, an diesem Ort
zu operieren. Falls irgendeine dieser Überprüfungen fehlschlägt, sollte
die Netzwerkmanagement-Station sich weigern, die Konfigurationsdaten
zu dem Netzwerkelement, das sie angefordert hat, zu übermitteln.
-
Das
Routen der Konfigurationsdaten-Antwort-Mitteilung von der Netzwerkmanagement-Station
zu dem Netzwerkelement, das nach den Konfigurationsdaten gefragt
hat, findet in der Reihenfolge der Identifizierungskennungen in
dem Laufweg-ID-Liste-Feld 705 statt. Ein sehr geradliniger
weg zum Updaten des Inhalts des Laufweg-ID-Liste-Felds 705 beinhaltet,
dass jedes Netzwerkelement, das auf dem Weg die Mitteilung empfängt und
das nicht der beabsichtigte letze Empfänger ist, seine eigene Identifizierungskennung
von dem Laufweg-ID-Liste-Feld 705 entfernt und die Mitteilung
an das Netzwerkelement weiterleitet, das durch die nächste Identifizierungskennung
in dem Feld identifiziert ist. Wenn eine Prüfsumme benutzt wird, muss sie
jedes Mal durch eine erneut berechneten Prüfsumme ersetzt werden, wenn
eine Element-Identifizierungskennung von dem Laufweg-ID-Liste-Feld 705 entfernt
wurde, es sei denn, dass dieses Feld aus dem Bereich ausgelassen
wurde, über
welchem die Prüfsumme
berechnet wird.
-
In
einem Fall, in welchem ein Netzwerkelement, das nicht eine Netzwerkmanagement-Station ist,
entscheidet, aus seinen eigenen Speichern „abzuzapfen", das heißt, Konfigurationsdaten
aus seinem eigenen Konfigurationsspeicher zu lesen und abwärts zu übermitteln,
zum Beispiel weil es keine Antwort von einer höheren Ebene empfangen hat, kann
die Mitteilungsstruktur, die in 7 gezeigt
ist, immer noch verwendet werden. Es kann vorteilhaft sein, zwei
unterschiedliche Mitteilungs typ-Identifizierungskennungen zu definieren,
um einen Unterschied zu machen zwischen einer Konfigurationsdaten-Antwort-Mitteilung, die den
ganzen Weg von einer Managementstation herunterkommt, und einer Konfigurationsdaten-Antwort-Mitteilung aus einer niedrigeren
Ebene, aber dies ist nicht zwingend: Der Inhalt des Quell-ID-Felds 702 dient
ohnehin dazu, dass Netzwerkelement zu identifizieren, das ursprünglich die
Konfigurationsdaten-Antwort-Mitteilung zusammengestellt hat. Ein
Netzwerkelement, das nicht eine Netzwerkmanagement-Station ist, kann ähnliche Überprüfungen anstellen,
die oben in Verbindung mit der Tätigkeit
einer Netzwerkmanagement-Station
diskutiert wurden, um sicherzustellen, dass die Konfigurationsdaten
nur zu solchen Netzwerkelementen geliefert werden, die sich durch
eine akzeptierbare Identifizierungskennung in geeigneter Weise identifiziert
haben und die angefordert haben, an einem erlaubten Ort innerhalb
des Netzwerks konfiguriert zu werden.
-
In
dem Vorangehenden haben wir uns auf die „alles unterhalb"-Ausgestaltung der Erfindung konzentriert,
in welcher jedes aktive Netzwerkelement die Konfigurationsdaten
aller anderen aktiven Netzwerkelemente, die unter ihm in der baumartigen hierarchischen
Struktur des Netzwerks sind, abspeichert, ohne dass dabei ihre Entfernungen
an Ebenen beachtet würden.
Die gegebene Beschreibung kann in einfacher Weise generalisiert
werden, um auch die „nur
nächst
niedrigere"-Ausgestaltung
abzudecken, in welcher jedes aktive Netzwerkelement nur die Konfigurationsdaten
der Netzwerkelemente in der unmittelbar niedrigeren Ebene abspeichert.
Die einzige Veränderung
ist, dass in den Verfahren, das in 4 dargestellt
ist, die Schritte 405 und 406 nur dann ausgeführt werden,
falls das Netzwerkelement, das einen Teil der Konfigurationsdaten
bearbeitet, bemerkt, dass die Konfigurationsdaten ein Netzwerkelement
betreffen, das sich unmittelbar unter ihm in der Netzwerkhierarchie
befindet, das heißt,
das zu der Gruppe von Netzwerkelementen gehört, für welche es Konfigurationsdaten
im Speicher haben sollte. Ansonsten folgt das Netzwerkelement nur
dem Fluss, welcher in 4 dargestellt ist, durch besagte Schritte,
ohne sie auszuführen.
-
Ein
Faktor, der eine „nur
nächst
niedrigere"- oder „nur N
niedrigere"-Ausgestaltung
der Erfindung bevorzugt würde,
ist die Erzielung einer Einsparung an Speicherfläche. In einem sehr aufwendigen „alles unterhalb"-Netzwerk, in welchem
die Anzahl der Ebenen groß ist
und jede Ebene eine große
Anzahl von Netzwerkelementen beinhaltet, benötigt ein Netzwerkelement, das
sich relative hoch in der Netzwerkhierarchie befindet, eine große Anzahl
von Speichern, um die Konfigurationsdaten von allen Netzwerkelementen,
die sich unterhalb von ihm in der Netzwerkhierarchie befinden, zu
speichern. Indem die Anzahl der niedrigeren Ebenen, für welche
Konfigurationsdaten gespeichert werden müssen, begrenzt werden, werden
die Speicheranforderungen begrenzt.
-
Jedoch
hat die „alles
unterhalb"-Ausgestaltung
bestimmte Vorteile, die beispielsweise die Redundanz der Netzwerkverbindungen
betreffen. In vielen Netzwerkarchitekturen ist es möglich, ein schlecht
funktionierendes Netzwerkelement zu umgehen und zum Beispiel ein
Netzwerkelement in einer nächst
höheren
Ebene zu kontaktieren, oder eine Kommunikationsverbindung durch
eine unterschiedliche Route zu einer niedrigeren Ebene zu steuern, jedoch
so, dass die Umleitung mit der ursprünglichen Route in einer höheren Ebene
konvergiert. In einem „alles
unterhalb"-Netzwerk
ist es sehr wahrscheinlich, dass sogar falls eine alternative Route
zu einer niedrigeren Ebene genommen werden muss, die alternative
Route durch bestimmte Netzwerkelemente führt, die zuvor nicht mit dem
Netzwerkelement der niedrigeren Ebene kommuniziert haben, für welche die
Konfigurationsdaten benötigt
werden, sodass früher
oder später
eine Ebene erreicht werden wird, in welcher die alternative Route
mit der ursprünglichen Route
zusammenfällt.
Das Netzwerkelement, das als Konvergenzpunkt dient, besitzt und
kann die geeigneten Konfigurationsdaten benutzen, unab hängig von
der Route, durch welche die Anforderungsmitteilung zu den niedrigeren
Ebenen kam.
-
In
Verbindung mit 4 war angenommen worden, dass
das Netzwerkelement nur dann aus seinen eigenen Speichern „abzapft", falls es keine Antwort
von einer höheren
Ebene in dem Netzwerk empfängt
(Alternative Nein im Schritt 404). Jedoch ist es möglich, auch
andere Arten von Regeln zu definieren, welche ein Netzwerkelement
veranlassen, die angeforderten Konfigurationsdaten von einem lokalen
Speicher zu lesen, anstatt Daten, die von höheren Ebenen empfangen wurden,
weiterzuleiten. Diese Art von Regeln beruht typischerweise auf einer
Annahme, dass sich die Konfigurationsdaten selbst nicht geändert haben:
Ein Netzwerkelement geht davon aus, dass die Konfigurationsdaten,
die es in seinem Speicher hat, gültig
sind, so dass der Grund, der das Netzwerkelement der niedrigeren
Ebene veranlasst hat, die Konfigurationsdaten anzufordern, mehr damit
in Beziehung steht, dass Daten der niedrigeren Ebene verloren wurden,
anstelle von veränderten Konfigurationsbedingungen.
Zum Beispiel kann jedes Stück
der gespeicherten Konfigurationsdaten einen Zeitstempel, der damit
verbunden ist, aufweisen, so dass der Zeitstempel die Zeit anzeigt,
zu welcher die Konfigurationsdaten zuletzt modifiziert wurden. Wir
können
definieren, dass jedes Netzwerkelement inhärent alle solchen Konfigurationsdaten
als gültig betrachtet,
für welche
der Zeitstempel anzeigt, dass sie nicht älter sind als ein bestimmtes
Zeitlimit. Ein Fachmann kann auf einfache Weise andere Regeln aufstellen,
die das Konzept der inhärenten
Verläßlichkeit
definieren.
-
Angenommen,
dass die inhärente
Verläßlichkeit
der Konfigurationsdaten gemäß bestimmter Regeln
definiert wurde. In diesem Fall überprüft ein Netzwerkelement
jedes Mal, wenn es eine Anforderungsmitteilung von einem Netzwerkelement
einer niedrigeren Ebene erhält,
welches es anhand der Element-Identifizierungskennung
erkennt, ob die zuvor gespeicherten Konfigurationsdaten für dieses
bestimmte Netzwerkelement aus einer niedrigeren Ebene immer noch
inhärent
gültig
ist. Falls sie das sind, versucht das fragliche Netzwerkelement
nicht einmal, Antworten von irgendwelchen höheren Ebenen in der Netzwerkhierarchie
zu erhalten, sondern stellt einfach die Konfigurationsdaten-Antwort-Mitteilung selbst
zusammen. Nicht einmal eine Benachrichtigungsmitteilung muss zu
den höheren
Ebenen versandt werden, es sei denn, das Netzwerk zielt darauf ab,
die Frequenz, mit welcher Anforderungsmitteilungen auftreten, zu
dokumentieren. Nur falls es keine zuvor gespeicherten, inhärent gültigen Konfigurationsdaten,
die bei dem Netzwerkelement gespeichert sind, gibt, übermittelt
es die Anforderungsmitteilung an höhere Ebenen gemäß dem, was
zuvor in Verbindung mit 4 beschrieben wurde.
-
Als
Nächstes
werden wir die Anwendbarkeit der Erfindung auf eine Situation analysieren,
in welcher ein Netzwerkelement seinen logischen Ort (location) in
dem Netzwerk verändert.
Unter einer Änderung
des logischen Orts verstehen wir, dass nach der Änderung die Route zwischen
dem Netzwerkelement und der Netzwerkmanagement-Station durch andere Netzwerkelement
höherer
Ebenen als vorher verläuft.
Eine Veränderung
des logischen Orts ist oft, aber nicht notwendigerweise, mit einer
Veränderung des
physikalischen Orts verbunden.
-
Wenn
eine Änderung
des logischen Orts aufgetreten ist und das fragliche Netzwerkelement
das erste Mal in seinen neuen logischen Orts angeschaltet wird,
findet es sich in einer Situation wieder, in welcher es Konfigurationsdaten
benötigt.
Es beginnt, das zuvor in 3 dargestellte Verfahren auszuführen, das
heißt,
es übermittelt
eine Anforderungsmitteilung zur Anforderung von Konfigurationsdaten. Keine Änderungen
des Verfahrens von 3 werden benötigt bis auf die Tatsache,
dass das Netzwerkelement den logischen Ort geändert hat. Auch die Netzwerkelemente
höherer
Ebenen, durch welche die Anforderungsmitteilung läuft, können genauso
handeln, wie es oben in Verbindung mit 4 beschrieben wurde.
Jedoch können
be stimmte Hinzufügungen
zu dem zuvor beschriebenen Betrieb der Netzwerkmanagement-Station
notwendig sein.
-
8 ist
ein vereinfachtes Ablaufdiagramm, das den Betrieb der Netzwerkmanagement-Station zeigt,
wenn es möglicherweise
auftretende Änderungen
der logischen Orte berücksichtigt.
Schritte 601, 602, 603, 604, 605 und 606 sind
im Wesentlichen die gleichen wie in 6. Jedoch überprüft im Schritt 801 die
Netzwerkmanagement-Station als eine Antwort auf ein positives Ergebnis
im Schritt 602, ob das Netzwerkelement, das Konfigurationsdaten
anfordert, seinen logischen Ort geändert hat. Die Überprüfung basiert
auf der Kette von sequentiellen Element-Identifizierungskennungen,
die in dem „bearbeitet
von"-Feld der Anforderungsmitteilung
erscheint. Die Netzwerkmanagement-Station hat zuvor mit den eigentlichen
Konfigurationsdaten dieses Netzwerkelements die Kette von Element-Identifizierungskennungen,
welche die Verbindung zwischen dem Netzwerkelement und der Netzwerkmanagement-Station
durch die Netzwerkhierarchie beschreibt, gespeichert. Falls die
Element-Identifizierungskennungen in dem neu empfangenen „bearbeitet
von"-Feld von der
abgespeicherten Sequenz abweichen, ist eine Veränderung eines logischen Orts aufgetreten.
Ein negatives Ergebnis würde ähnlich wie
in 6 direkt zu Schritt 603 führen.
-
Ein
positives Ergebnis im Schritt 801 führt zu Schritt 802,
bei welchem die Netzwerkmanagement-Station automatisch einen Satz
neuer Konfigurationsdaten erzeugt, welche den neuen logischen Ort
des Netzwerkelements berücksichtigen.
Die Bedingung, dass die Generierung neuer Konfigurationsdaten automatisch
erfolgt, ist nicht zwingend, aber sie hilft außerordentlich, den Bedarf an
manueller Rekonfiguration bei der Netzwerkmanagement-Station zu
verringern. Die Tatsache, dass das Netzwerkelement den logischen
Ort verändert
hat, bedeutet, dass bestimmte Veränderungen an den Konfigurationsdaten
benötigt
werden können,
welche sowohl die Netzwerkelemente, die zu der neuen „Route" gehören, das
heißt,
durch welche das fragliche Netzwerkelement jetzt mit der Netzwerkmanagement-Station kommuniziert,
als auch die Netzwerkelemente, die zu der alten „Route", das heißt, durch welche das fragliche
Netzwerkelement vor der Veränderung
mit der Netzwerkmanagement-Station kommuniziert hat, betreffen.
Die benötigten
neuen Sätze
von Konfigurationsdaten werden jeweils in den Schritten 803 und 804 erzeugt.
-
Alle
erzeugten Sätze
mit neuen Konfigurationsdaten müssen
von der Netzwerkmanagement-Station zu den entsprechenden Netzwerkelementen übermittelt
werden. Diese Übermittlung
ist schematisch in dem Flussdiagramm von 8 dargestellt,
so dass die neu erzeugten Sätze
von Konfigurationsdaten für
die Übermittlung
im Schritt 805 markiert werden und die Schleife, die aus
den Schritten 603, 604 und 806 besteht,
so lange durchlaufen wird, bis alle markierten Sätze von Konfigurationsdaten übermittelt
wurden.
-
Die Übermittlung
von neuen Konfigurationsdaten auch zu solchen Netzwerkelementen,
die eigentlich nicht angefragt hatten, bringt uns zu dem Thema,
welches erzwungene Veränderungen
der Konfigurationsdaten durch Netzwerkmanagement-Handlungen betrifft. Ein sehr geradliniger
Weg, um solche erzwungenen Veränderungen
zu definieren, ist anzugeben, dass jedes Mal, wenn ein Netzwerkelement
eine Mitteilung des Typs, der in 7 gezeigt
ist, erhält,
es behandelt sie auf ähnliche
Art unabhängig
davon, ob eine entsprechende Anforderungsmitteilung existierte oder
nicht. In anderen Worten werden alle Mitteilungen dieser Art durch
das Netzwerk zu dem Empfänger
weitergeleitet, welcher in dem Ziel-ID-Feld angegeben ist, unabhängig davon,
ob eine Anforderungsmitteilung zuvor in die entgegengesetzte Richtung
gelaufen ist, und jedes Mal, wenn eine Mitteilung dieser Art ihr
angegebenes Zielelement erreicht, akzeptiert das Zielelement die
darin enthaltenen Konfigurationsdaten und speichert sie ab, auch
wenn es keine Veränderungen
an seiner Konfiguration angefordert hat.
-
Das,
was oben bezüglich
einer Nezzwerkmanagement-Station, die auf eine Veränderung
eines logischen Orts reagiert, gesagt wurde, kann in einfacher Weise
verallgemeinert werden, um solche Situationen abzudecken, in welchen
ein Netzwerkelement, das nicht eine Netzwerkmanagement-Station ist,
aus seinen eigenen Speichern „abzapft", besonders falls
die Veränderung
eines logischen Orts von einem Zweig zu einem anderen Zweig der
baumartigen Netzwerkstruktur sich heruntererstreckend von dem besagten
Netzwerkelement stattgefunden hat. Eine der Regeln, die ein Netzwerkelement
dazu verwendet, um zu entscheiden, ob eine Anforderungsmitteilung
weiter aufwärts übermittelt
wird oder ob sie von ihm selbst beantwortet wird, kann so sein,
dass alle solchen Veränderungen
der logische Orte, die nur Unterbäume des fraglichen Netzwerkelements einbeziehen,
lokal behandelt werden können,
wohingegen Veränderungen
der logischen Orte, bei welchen ein Netzwerkelement entweder von
einem unbekannten Teil des Netzwerks erscheint oder von dem fraglichen
Unterbaum verschwindet, weiter aufwärts zu einer höheren Ebene
in der Netzwerkhierarchie verwiesen werden müssen.
-
Eine Änderung
des logischen Orts bezieht immer Veränderungen der Konfigurationsdaten
mit ein, zumindest in der Liste der Element-Identifizierungskennungen,
welche die Route zwischen dem Netzwerkelement, das seinen logische
Ort geändert hat,
und einer Netzwerkmanagement-Station definiert (in einem weiten
Sinn ist diese Liste auch ein Teil der Konfigurationsdaten). Oben
haben wir angemerkt, wie eine Veränderung eines logischen Orts von
einem Netzwerkelement einer höheren
Ebene, das aus seinen eigenen Speichern „abzapft", behandelt werden kann anstelle einer
Netzwerkmanagement-Station. Dies setzt voraus, dass das Netzwerkelement
der höheren
Ebene dazu autorisiert ist, Veränderungen
an den Konfigurationsdaten vorzunehmen. Das Prinzip der Verteilung
der Speicherung von Konfigurationsdaten gemäß der Erfindung macht es möglich, auch
Rechte zum Ändern
von Konfigurationsdaten zu verteilen. Hier müssen wir die Diskussion nicht
auf Änderungen
der Konfigura tion beschränken,
die eine Veränderung
des logischen Orts beinhaltet: Im Prinzip ist es möglich, irgendein
Netzwerkelement dazu zu autorisieren, irgendeine Art von Veränderung
zu machen.
-
Gemäß einer
vorteilhaften Ausgestaltung der Erfindung beinhaltet ein Satz von
gespeicherten Konfigurationsdaten einige Angaben, die besagen, wem es
gestattet ist, welche Art von Änderungen
an den Konfigurationsdaten vorzunehmen. Irgendein Netzwerkelement
kann eine Benutzerschnittstelle oder sogar eine Anzahl von Benutzerschnittstellen
umfassen, durch welche ein menschlicher Bediener Änderungen
an den Konfigurationsdaten eines bestimmten Netzwerkelements vornehmen
kann, genauso wie an den Konfigurationsdaten von Netzwerkelementen,
die in der Netzwerkhierarchie unter dem bestimmten Netzwerkelement
angeordnet sind – diese werden
nach allem in dem Konfigurationsspeicher des bestimmten Netzwerkelements
abgespeichert. Die Änderungen,
die auf diese Weise vorgenommen werden, müssen natürlich so sein, dass eine richtige Autorisierung
existiert, um sie an dem bestimmten Netzwerkelement und/oder an
der bestimmten Ebene in der Netzwerkhierarchie vornehmen zu können. Autorisierungen,
um Änderungen
vorzunehmen, können
generell so sein, dass zum Beispiel jeder, der ein bestimmtes Passwort
kennt, alle Arten von Veränderungen
vornehmen darf, oder sie können
sehr speziell sein, so dass für
jeden Konfigurationsparameter eigene exakte Definitionen dafür vorhanden
sind, wem es wie und wann gestattet ist, Veränderungen vorzunehmen. Der
zuletzt genannte Ansatz wird zu dem Prioritätszeitpunkt dieser Patentanmeldung
als vorteilhafter angesehen.
-
Veränderungen
der Konfigurationsdaten, die irgendwo anders als in der Netzwerkmanagement-Station
vorgenommen werden, dürfen
natürlich nicht
zu einer Situation führen,
in welcher sich inkonsistente Sätze
von Konfigurationsdaten für
ein bestimmtes Netzwerkelement an verschiedenen Speicherorten in
dem Netzwerk befinden. Um solche Inkonsistenzen zu vermeiden, muss
ein Mechanismus existieren, um die Veränderungen an alle Orte zu kommunizieren,
an den gespeicherte Kopien der Konfigurationsdaten, die geändert wurden,
existieren. 9 ist ein schematisches Mitteilungs-Austausch-Diagramm,
das die Kommunikation von Veränderungen
veranschaulicht. Im Schritt 901 werden die Konfigurationsdaten
eines Netzwerkelements aus Ebene 1 geändert; die Änderung wird durchgeführt von
einem Netzwerkelement aus Ebene 3, das sich zwei Ebenen in der Netzwerkhierarchie
oberhalb des Elements, dessen Konfigurationsdaten geändert werden,
befindet. Im Schritt 902 speichert das Netzwerkelement
aus Ebene 3 die geänderten
Konfigurationsdaten in dem Teil seines eigenen Konfigurationsspeichers,
in welchem es die Konfigurationsdaten der Netzwerkelemente aus niedrigeren
Ebenen hat, die unter ihm in der Netzwerkhierarchie liegen. Im Schritt 903 übermittelt
das Netzwerkelement aus der Ebene 3 eine Informationsmitteilung
nach oben in der Netzwerkhierarchie. Da die nächst höhere Ebene bereits durch eine
Netzwerkmanagement-Station repräsentiert
wird, geht die Informationsmitteilung direkt zu ihr.
-
Die
Form der Informationsmitteilung, die in der Netzwerkhierarchie nach
oben übermittelt
wird, kann zum Beispiel so wie die sein, die in 10 gezeigt
ist. In der Mitteilung 1000 ist ein Mitteilungstyp-Feld 1001 enthalten,
dessen Inhalt anzeigt, dass die Mitteilung eine Informationsmitteilung
ist. Eine einzigartige Element-Identifizierungskennung in dem Quell-ID-Feld 1002 zeigt
das Netzwerkelement an, von welchem die Veränderung vorgenommen wurde,
und eine andere einzigartige Element-Identifizierungskennung in
dem Objekt-ID-Feld 1003 zeigt das Netzwerkelement an, dessen
Konfigurationsdaten geändert
wurden. Der neue Satz von Konfigurationsdaten ist in einem geeigneten
Feld 1004 enthalten, und da die Mitteilung eine von denen
ist, die in der Netzwerkhierarchie nach oben übermittelt werden, gibt es
ein „bearbeitet
von"-Feld 1005,
in welches alle die Netzwerkelemente ihre eigene einzigartige Identifizierungskennung
hinzufügen,
durch welche die Mitteilung auf ihrem Weg zu der Netzwerkmanagement-Station
läuft.
Eine Prüfsumme
kann in einem geeigneten Feld 1006 hinzugefügt werden. Ähnlich wie
die Anforderungsmitteilung, die in 5 gezeigt
ist, kann die Informationsmitteilung aus 10 eine
Identifizierungskennung des beabsichtigten letzten Empfängers enthalten,
es sei denn, die Verwendung einer solchen Identifizierungskennung
wird dadurch unnötig,
dass nur eine eindeutig definierte Netzwerkmanagement-Station existiert,
welche der letzte Empfänger
für alle
Mitteilungen ist, die nach oben übermittelt
werden.
-
Im
Schritt 904 überprüft die Netzwerkmanagement-Station,
dass die Veränderungen
nicht irgendwelche Regeln verletzt haben, die Autorisierung benötigen. Falls
keine Verletzungen gefunden wurden, speichert die Netzwerkmanagement-Station
die neuen Konfigurationsdaten mit einer geeigneten Indizierung in
ihre Datenbank im Schritt 905. Falls die Veränderung
unautorisiert war, wird sie von der Netzwerkmanagement-Station nicht
akzeptiert.
-
Im
Schritt 906 übermittelt
das Netzwerkelement aus Ebene 3 die neuen Konfigurationsdaten in der
Netzwerkhierarchie abwärts.
Die gegenseitige Reihenfolge der Schritte 903 und 906 ist
nicht wichtig und sie könnten
auch in einer unterschiedlichen Reihenfolge ausgeführt werden.
Die Mitteilung, die im Schritt 906 übermittelt wurde, kann exakt
die gleiche sein wie in 7. Das Netzwerkelement aus Ebene 3
hat den Inhalt des Laufweg-ID-Liste-Felds aus seinem eigenen Konfigurationsspeicher
gelesen. Die Schritte 907 und 908 sind ähnliche
Prüf- und
Speicherschritte in dem Netzwerkelement aus Ebene 2 wie die Schritte 904 und 905 in
der Netzwerkmanagement-Station.
Im Schritt 909 leitet das Netzwerkelement aus Ebene 2 die
Mitteilung zu dem letzten Empfänger
weiter, nachdem es seine eigene Identifizierungskennung aus dem
Laufweg-ID-Liste-Feld
entfernt hat. Nach einer Autorisierungsüberprüfung im Schritt 910,
speichert das Netzwerkelement aus Ebene 1 die neuen Konfigurationsdaten
im Schritt 911 und nimmt sie in Gebrauch im Schritt 912.
-
Es
ist möglich
und oft sogar notwendig, die Netzwerkelemente so zu programmieren,
dass, falls notwendig, sie selbstversorgend sind, ohne auf Konfigurationsbefehle
aus höheren
Netzwerkebenen zurückgreifen
zu müssen.
Das Merkmal der Selbstversorgung kann zum Beispiel in kleinen Netzwerken benötigt werden,
in welchem nur Netzwerkelemente aus Ebene 1 miteinander kommunizieren,
ohne dass irgendwelche Netzwerkelemente aus Ebene 2 oder einer höheren Ebene überhaupt
beteiligt sind. In diesem Fall muss jedes Netzwerkelement es erlauben, alle
Konfigurationsänderungen
in Ebene 1 durchzuführen.
Dieses Merkmal kann dadurch automatisiert sein, dass für jede positive
ganze Zahl K definiert ist, dass falls ein Netzwerkelement der Ebene
K herausfindet, dass es gerade mit einem anderen Netzwerkelement
der Ebene K anstelle eines Netzwerkelements der Ebene K+1 kommuniziert,
es unmittelbar erlaubt, dass alle Konfigurationsänderungen auf seiner eigenen
Ebene durchgeführt
werden.
-
In
der vorangehenden Beschreibung wurden nur manuell eingegebene Änderungen
der Konfigurationsdaten behandelt. Die Erfindung erlaubt es auch,
dass Änderungen
automatisch von geeigneten autorisierten Netzwerkelementen durchgeführt werden.
Bestimmte Teile der Konfigurationsinformationen können beispielsweise
zeitabhängig
sein, sodass ein Netzwerkelement solche Teile ändert, nachdem ein Zeitlimit
abgelaufen ist, wiederholend in bestimmten Zeitintervallen oder
auf andere zeitabhängige
Art und Weise. Veränderungen
der Konfigurationsdaten können
auch notwendig werden aufgrund der beobachteten Leistung von bestimmten
Netzwerkelementen: Zum Beispiel kann einem Netzwerkelement, bei
dem herausgefunden wurde, dass es wiederholt bei der Kommunikation
aufgrund von einem unzulänglichen
Bedienungslevel versagt, ein höherer vorgegebener
Bedienungslevel eingeräumt
werden, indem die geeigneten Konfigurationsdaten geändert werden.
-
Das
Verb „umfassen" wird in dieser Patentanmeldung
als offene Limitierung verwendet, welche nicht die Existenz anderer nicht
genannter Merkmale ausschließt.
Die Merkmale, die in den abhängigen Ansprüchen wiedergegeben
sind, sind untereinander frei kombinierbar, es sei denn, etwas anderes
ist explizit angegeben.