-
Die
Erfindung betrifft allgemein die Adressenverwaltung in hierarchischen
PNNI-Netzen und insbesondere die Verwaltung von Adressen entsprechend
ihrer Erreichbarkeit in solchen Netzen.
-
PNNI
(Private Network-to-Network Interface, Schnittstelle zwischen privaten
Netzen) ist ein hierarchisches Routing-Protokoll (Leitweg-Protokoll) für dynamische
Verbindungszustände,
das vom ATM-Forum (Asynchronous Transfer Mode, asynchroner Übertragungsmodus)
zur Verwendung in ATM-Netzen
definiert wurde. Durch die Erweiterung der Hierarchie und die Verwendung
eines einzigen Routing-Protokolls auf allen Hierarchieebenen ist
es möglich,
große
ATM-Netze zu unterstützen.
Ein Hauptmerkmal des Protokolls besteht in der Fähigkeit, Netzknoten zu verwaltbaren
Gruppen zusammenzufassen, die als „Peergruppen" (peer groups, PG)
bezeichnet werden. Ein Knoten in jeder Peergruppe dient als „Peergruppenleiter" (peer group leader,
PGL) und repräsentiert
seine Peergruppe auf der nächsthöheren Hierarchieebene
in Form eines einzigen logischen Knotens als „logischer Gruppenknoten" (logical group node,
LGN). 1 der beiliegenden Zeichnungen veranschaulicht
dieses Konzept schematisch und zeigt ein einfaches hierarchisches Netz
mit zwei Ebenen. Auf der untersten Ebene, in der Hierarchie des
vorliegenden Beispiels auf Ebene 1, stellen die Knoten AA1 bis AA3,
AB1 bis AB3, AC1 und AC2 reale Netzeinheiten wie beispielsweise Switches
(Vermittlungscomputer) dar, die, wie gezeigt, durch Leitungen miteinander
verbunden sind. Diese Knoten sind zu drei Peergruppen zusammengefasst,
die durch die gestrichelten Linien in der Figur voneinander abgegrenzt
sind. In jeder Peergruppe ist ein Knoten, der in der Figur schraffiert
dargestellt ist, als Peergruppenleiter festgelegt. Jeder Peergruppenleiter
wird durch einen vom PNNI vorgegebenen Prozess „ausgewählt" und dient zusätzlich zu seinen normalen Funktionen
als Knoten innerhalb einer Peergruppe dazu, seine Peergruppe auf der
nächsthöheren Hierarchieebene
als logischen Knoten zu vertreten. Beim dargestellten Beispiel bilden
somit die Knoten AA1 bis AA3 eine Peergruppe, die vom Peergruppenleiter
AA3 auf der Hierarchieebene 2 als logischer Knoten AA vertreten
wird. Die Knoten AB1 bis AB3 bilden eine Peergruppe, die vom Peergruppenleiter
AB3 auf der Hierarchieebene 2 als logischer Knoten AB vertreten
wird. Die Knoten AC1 und AC2 bilden eine Peergruppe, die vom Peergruppenleiter AC2
auf der Hierarchieebene 2 als logischer Knoten AC vertreten wird.
-
ATM
ist eine Quellenroutingtechnologie. Um die Quellenroute zu berechnen,
müssen
die Knoten über
Informationen der Netztopologie verfügen. Das PNNI definiert somit
ein System zum Erzeugen und Verteilen von Topologiedaten innerhalb
eines Netzes. Die Topologiedaten werden von PNNI-Topologie-Statuselementen (PNNI
Topology State Element, PTSE) definiert, die von den Knoten erzeugt
und so verteilt werden, dass jeder Knoten eine Topologiedatenbank verwalten
kann, die sein Bild vom Netz definiert. Angaben zur Ressourcenzuordnung
im PNNI sind bekannt aus „Resource
Location in Mobile ATM Networks" von
L. Freléchoux
et al., Proceedings of ICATM '98,
Colmar, Frankreich, Juni 1998, S. 423 bis 430. PTSEs enthalten Daten
von Knoten, Leitungen und Adressen („Präfixe von erreichbaren Adressen"), auf welche Netzeinheiten
zugreifen können.
Präfixe von
erreichbaren Adressen können
Knoten- und/oder Endsystemadressen sein und zusammengefasst werden,
sodass sie eine Ansammlung einzelner Adressen darstellen, die unter
einem einzigen Adresspräfix
zusammengefasst sind, oder sie können
native Adressen sein, welche die Adresse eines Einzelknotens oder
eines Endsystems darstellen. PTSEs werden auf die Knoten in einer
Peergruppe verteilt, sodass jeder Knoten in der Peergruppe über dieselbe Topologiedatenbank
und somit über
dasselbe Bild vom Netz verfügt.
In der nächsthöheren Hierarchieebene
wird die Topologie der Peergruppe in der oben beschriebenen Weise
abstrahiert und als ein einziger logischer Knoten präsentiert.
-
Der
Peergruppenleiter erzeugt für
das PTSE Informationsadressen, die innerhalb seiner Kind-Peergruppe
verfügbar
sind, und verteilt diese an seine Nachbarn in der nächsten Hierarchieebene, allerdings
ohne Details über
die Knoten und Leitungen innerhalb der Peergruppe. Durch diese Abstraktion
der Topologie wird eine Verringerung der Ressourcen erreicht, die
zum Definieren sehr großer
Netze erforderlich sind. Eine Folge dieser Abstraktion der Topologie
besteht jedoch darin, dass die Verfügbarkeit bzw. „Konnektivität" einer Adresse nur
innerhalb der Peergruppe bekannt ist, aus der sie stammt. Somit
kann eine Adresse innerhalb der Peergruppe auch dann von außerhalb
der Peergruppe aufgerufen werden, wenn sie, zum Beispiel durch eine
Leitungsunterbrechung, eigentlich nicht erreichbar ist.
-
PNNI
definiert ein „Zeitlimitsystem" für PTSEs,
bei welchem jedem PTSE eine Lebensdauer, normalerweise eine Stunde,
zugewiesen wird, während
der es gültig
ist. Der Ursprungsknoten eines PTSEs sollte das PTSE alle dreißig Minuten
erneuern, indem er das PTSE wieder an seine Nachbarn verteilt, sodass
das PTSE wieder durch die Peergruppe geleitet wird. Normalerweise
kann ein PTSE nur von seinem Ursprungsknoten geändert werden (oder in manchen
Fällen
von einem Proxyknoten, der stellvertretend für den Ursprungsknoten handelt). Wenn
jedoch die Lebensdauer eines PTSE abläuft, ohne dass es erneuert
wurde, wird es nicht mehr als gültige
Topologieinformation angesehen und aus der Topologiedatenbank entfernt
oder „gelöscht". Das heißt, wenn
ein Knoten erkennt, dass die Lebensdauer eines PTSE abgelaufen ist,
wird das PTSE aus der Topologiedatenbank dieses Knotens entfernt
und das abgelaufene PTSE (als „leeres" PTSE, welches das Ablaufen
des Topologieelements anzeigt) in der gesamten Peergruppe verteilt,
damit es aus der gesamten Peergruppe gelöscht wird. Desgleichen wird
jedes PTSE, das von einem Peergruppenleiter erzeugt wurde, der das
Topologieelement definiert, aus der nächsten Ebene der Hierarchie
und so weiter durch das gesamte Netz hindurch gelöscht. Wenn
durch den Verlust der Konnektivität innerhalb der Peergruppe
auf eine Adresse nicht zugegriffen werden kann, führt somit
das Ungültigwerden
des zugehörigen PTSE
schließlich
dazu, dass die Adresse (sofern die Konnektivität nicht inzwischen wiederhergestellt
wurde) aus dem Netz gelöscht
wird. Bis zu diesem Zeitpunkt können
jedoch weiterhin Anforderungen zum Anrufaufbau für diese Adresse von außerhalb
an die Peergruppe gerichtet werden und werden einfach abgewiesen,
sobald sie den Zugangspunkt zur Peergruppe erreichen.
-
Außer zu überflüssigen Anrufen
für nicht
erreichbare Adressen kann es bei dem vorliegenden Schema auch noch
zu weiteren Problemen kommen. Zum Beispiel können Situationen entstehen,
in denen eine bisher als Knoten mit einer Netzkonfiguration verbundene
Einheit in eine neue Netzkonfiguration übernommen wird. Zu einer solchen
Situation kann es zum Beispiel bei Änderungen der Partitionierung
von Peergruppen in einem Netz kommen, oder wenn sich ein mobiler
Knoten von einem zu einem anderen Zugangspunkt bewegt (Mobiles PNNI). Wenn
der Knoten mit der neuen Netzkonfiguration verbunden wird, muss
er seine Peergruppe an die neue Situation anpassen. Als Teil des
sich daraus ergebenden Austauschprozesses in der Datenbank kann
der Knoten verfügbare
Adresspräfixe
aus der Hierarchie seiner vorigen Peergruppe in die Datenbank einfügen (und
wird dies bei einem mobilen Knoten, dessen Zugangspunkte sich ändern, auch
unbedingt tun). Das kann dazu führen,
dass unbrauchbare Adressen im Netz verteilt werden, und erhöht die Gefahr,
dass die Routenwahl über
einen ungültigen
Pfad führt.
-
Weiterhin
kann es bei dem vorliegenden Schema beispielsweise auch dann zu
einem ernsthaften Problem kommen, wenn ein Sicherungsserver, zum
Beispiel ein LECS (LAN Emulation Client Server), dieselbe verfügbare Adresse
als Primärserver
angibt. Falls der Primärserver
isoliert wird oder nicht mehr funktioniert, werden alle von außerhalb
an diesen Server gerichteten Anrufe so lange weiterhin zu diesem
Server und nicht zum Sicherungsserver in einer anderen Peergruppe
geleitet, bis die Adresse des Primärservers abläuft und
aus dem Netz gelöscht
wird.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird ein Verfahren zur Adressenverwaltung in
einem Knoten bereitgestellt, der für eine Peergruppe von Knoten
in einer Hierarchieebene eines hierarchischen PNNI-Netzes als Peergruppenleiter
fungiert, wobei der Peergruppenleiter die Peergruppe gegenüber einem
oder mehreren Nachbarknoten in der nächsthöheren Hierarchieebene repräsentiert, und
wobei der Peergruppenleiter einen Speicher zum Speichern von Topologiedaten
der Peergruppe, welche Adressdaten umfassen, die dem Peergruppenleiter
von den Knoten der Peergruppe zugeliefert werden und Adressen für den Zugriff
aus dem Netz darstellen, und zum Speichern von Topologiedaten des
Peergruppenleiters aufweist, welche Adressdaten umfassen, die den
Nachbarknoten vom Peergruppenleiter zugeliefert werden und Adressen
darstellen, auf die über
die Peergruppe zugegriffen werden kann, wobei das Verfahren Folgendes
umfasst:
Prüfen,
ob die von den Adressdaten dargestellten Adressen über die
Peergruppe erreichbar sind;
Benachrichtigen der Nachbarknoten
bei Änderungen der
Erreichbarkeit so bezeichneter Adressen; und
Aktualisieren
der Topologiedaten des Peergruppenleiters entsprechend den Änderungen.
-
Gemäß der vorliegenden
Erfindung kann deshalb der Peergruppenleiter prüfen, ob Adressen, d.h. Präfixe von
erreichbaren Adressen, in der Peergruppe tatsächlich erreichbar sind. Änderungen
der Erreichbarkeit oder Konnektivität von so bezeichneten Adressen
können
seinen Nachbarknoten in der nächsten
Hierarchieebene mitgeteilt werden. Da der Peergruppenleiter sich
nicht nur auf die Gültigkeit
der zugehörigen
PTSEs bis zum Ablaufen deren Lebensdauer verlassen muss, sondern
die Konnektivität
der Adressen prüfen
kann, können
bei den Ausführungsarten
der vorliegenden Erfindung die oben erörterten Probleme gemindert
oder beseitigt werden.
-
Zum
Ermitteln, wann und welche Adressen zu prüfen sind, können verschiedene Kriterien
zugrunde gelegt werden. Zum Beispiel können Systeme in Betracht gezogen
werden, bei denen der Peergruppenleiter periodisch Adressen prüft, die
von den Adressdaten in einer oder beiden Topologiedatenbanken dargestellt
werden. Das Intervall zwischen den Prüfungen kann kleiner gewählt werden
als die Lebensdauer der PTSEs oder der Aktualisierungszeitraum,
wobei die Häufigkeit
der Prüfung
von den Anforderungen des jeweiligen Systems abhängt. Dadurch würden einige
der oben erörterten
Probleme gemindert, da die Zeitdauer, während der aus dem Netz nur
scheinbar auf nicht erreichbare Adressen zugegriffen werden kann,
verkürzt
wird.
-
Vorzugsweise
erfolgt die Prüfung
der Adressen jedoch als Reaktion auf das Eintreten eines Ereignisses,
das eine Änderung
der Erreichbarkeit von Adressen in der Peergruppe anzeigen kann,
und dann aus Effizienzgründen
auch nur für
Adressen, deren Erreichbarkeit von diesem Ereignis betroffen sein
kann.
-
Bei
den bevorzugten Ausführungsarten
dient als spezielles Beispiel, dass die Erreichbarkeit einer Adresse
innerhalb der Peergruppe geprüft
wird, wenn der Peergruppenleiter von seiner Kind-Peergruppe Adressdaten
(z.B. in Form eines PTSE) empfängt,
die eine neue Adresse darstellen, d.h. Adressdaten einer Adresse,
die in den Topologiedaten der Peergruppe nicht dargestellt wird.
Nur wenn die Erreichbarkeit der Adresse bestätigt wird, liefert der Peergruppenleiter
diese Adresse darstellende Adressdaten an seine Nachbarn in der
nächsten Hierarchieebene,
zum Beispiel in Form eines PTSE, und aktualisiert die Topologiedaten
des Peergruppenleiters mit den neuen Adressdaten, z.B. durch Speichern
des. neuen PTSE. Auf diese Weise werden neu zu einer Peergruppe
hinzukommende Adressen der nächsten
Hierarchieebene erst mitgeteilt, nachdem die Erreichbarkeit der
Adresse geprüft
worden ist. Dadurch wird verhindert, dass bei einem mobilen Knoten,
der sich zu einem neuen Zugangspunkt des Netzes bewegt, unbrauchbare
Adressen, z.B. aus der Datenbank, mit der alten Topologie im Netz
verbreitet werden, wodurch überflüssige Änderungen der
Netzdatenbanken verhindert und die Größe der Datenbanken für die Topologieänderungen
verringert sowie das Risiko vermieden werden, dass die Routenwahl über einen
ungültigen
Pfad erfolgt, was andernfalls möglich
wäre.
-
Bei
einem weiteren Beispiel kann die Erreichbarkeit einer Adresse geprüft werden,
wenn der Peergruppenleiter erkannt hat, dass eine Verbindungsleitung
zwischen Knoten in der Peergruppe ausgefallen ist. Dabei kann es
sich um eine der Leitungen des Peergruppenleiters selbst handeln,
wobei in diesem Fall der Peergruppenleiter den Leitungsausfall direkt
entdeckt, oder um eine Leitung zwischen anderen Knoten in der Peergruppe,
wobei der Peergruppenleiter in diesem Fall durch ein PTSE in Kenntnis
gesetzt wird, das von dem Knoten gesendet wird, der den Leitungsausfall
zuerst entdeckt hat. Ein Leitungsausfall kann in beiden Fällen eindeutig
dazu führen,
dass zuvor erreichbare Adressen innerhalb der Peergruppe nicht mehr
erreicht werden können. Somit
reagiert der Peergruppenleiter bei bevorzugten Ausführungsarten
auf das Entdecken eines Leitungsausfalls mit der Prüfung der
Erreichbarkeit mindestens einer Klasse von Adressen, welche durch
die Topologiedaten des Peergruppenleiters dargestellt werden. Wenn
sich dabei herausstellt, dass eine Adresse nicht erreichbar ist,
teilt der Peergruppenleiter seinen Nachbarn in der nächsten Hierarchieebene
den Verlust der Erreichbarkeit mit, zum Beispiel in Form eines PTSE,
und aktualisiert die Topologiedaten des Peergruppenleiters durch
Entfernen der diese Adresse darstellenden Adressdaten, zum Beispiel
durch Löschen
des zugehörigen
PTSE. Obwohl in diesem Fall alle Adressen in den Topologiedaten
geprüft
werden können,
ist es günstiger,
nur diejenigen Adressen zu prüfen,
die in den Topologiedaten des Peergruppenleiters dargestellt sind
und deshalb dem übrigen
Netz als erreichbar angezeigt wurden. Außerdem ist es nicht unbedingt
erforderlich, Adressen zu prüfen,
die direkt am Knoten des Peergruppenleiters erreichbar sind, da
diese von einem Leitungsausfall nicht betroffen sind. Somit muss
in diesem Fall von den in den Topologiedaten des Peergruppenleiters dargestellten
Adressen nur die Klasse derjenigen Adressen auf Erreichbarkeit geprüft werden,
die bereits an anderen Knoten in der Peergruppe erreichbar waren,
und für
die deshalb das zugehörige
PTSE in den Topologiedaten der Peergruppe von einem Knoten außerhalb
des Peergruppenleiters stammte.
-
Bei
einem anderen Beispiel entdeckt der Peergruppenleiter, dass eine
Leitung hergestellt worden ist, zum Beispiel, weil eine zuvor ausgefallene Leitung
wieder in Betrieb gegangen ist. Auch in diesem Fall kann es sich
um eine Leitung des Peergruppenleiters selbst oder beliebige andere
Leitung in der Peergruppe handeln. Bei bevorzugten Ausführungsarten
reagiert der Peergruppenleiter auf dieses Ereignis vorzugsweise
durch Prüfen,
ob jetzt mindestens eine Klasse von Adressen, die nicht in den Topologiedaten
des Peergruppenleiters, sondern in den Topologiedaten der Peergruppe
dargestellt sind, erreichbar ist. Bei einer in diesem Beispiel gefundenen Adresse
teilt der Peergruppenleiter die diese Adresse darstellenden Adressdaten
seinen Nachbarn in der nächsten
Hierarchieebene mit und aktualisiert die Topologiedaten des Peergruppenleiters
mit den neuen Adressdaten. Auch in diesem Fall brauchen am Knoten
des Peergruppenleiters erreichbare Adressen nicht geprüft zu werden,
sodass vorzugsweise nur die Klasse der Adressen in den Topologiedaten der
Peergruppe geprüft
werden, die von anderen Knoten in der Peergruppe stammen.
-
Gemäß der obigen
Beschreibung können
die Adressen Sammeladressen sein, die eine Ansammlung ähnlicher,
individueller Adressen von Einheiten darstellen. Der Zusammenfassungsprozess
kann auf allen Ebenen der Hierarchie durchgeführt werden. Wenn also der Peergruppenleiter
eine Anzahl verschiedener PTSEs mit Adressdaten erhält, welche zum
Zusammenfassen geeignete Adressen darstellen, kann er entsprechend
eine Sammeladresse erzeugen. Die Sammeladresse wird dann der nächsten Hierarchieebene
mitgeteilt, und die Adressdaten, welche die Sammeladresse darstellen,
werden in den Topologiedaten des Peergruppenleiters gespeichert.
Falls eine Leitung gemäß der obigen
Beschreibung ausfällt,
eine Adresse in den Topologiedaten des Peergruppenleiters eine vom
Peergruppenleiter erzeugte Sammeladresse ist und nach der Prüfung der
Erreichbarkeit der Einzeladressen festgestellt wird, dass nicht
alle Einzeladressen erreichbar sind, wird im Allgemeinen die Änderung
der Erreichbarkeit einer Einzeladresse der nächsten Hierarchieebene nicht
mitgeteilt, da dieser Ebene nur die Sammeladresse zur Kenntnis gelangt,
welche zumindest noch teilweise gültig ist. Wenn der Peergruppenleiter eine
neue Adresse empfängt
und diese Adresse bereits durch die vom Peergruppenleiter erzeugte
Sammeladresse in den Topologiedaten des Peergruppenleiters dargestellt
wird, ist ebenfalls keine weitere Mitteilung der neuen Adresse an
die nächste
Ebene erforderlich, sodass die Prüfung der Erreichbarkeit in diesen
Fällen
nicht durchgeführt
werden muss.
-
Zur
Prüfung
der Erreichbarkeit von Adressen können verschiedene Verfahren
verwendet werden. Zum Beispiel kann der Peergruppenleiter in manchen Systemen
die Erreichbarkeit prüfen,
indem er eine Nachricht an diese Adresse zu senden versucht, z.B. durch
Auslösen
eines Anrufaufbaus an diese Adresse.
-
Bevorzugte
Ausführungsarten
prüfen
jedoch die Erreichbarkeit von Adressen, indem sie bereits vorhandene
Funktionen des PNNI-Protokolls
nutzen, welche die zur Ermittlung der Erreichbarkeit notwendigen
Informationen liefern. Wie oben erwähnt, definiert das PNNI-Protokoll
insbesondere einen Prozess zum „Auswählen" von Peergruppenleitern, bei welchem
die Knoten in einer Peergruppe entscheiden, welcher konkrete Knoten
als ihr Peergruppenleiter fungieren soll. Die Eignung eines bestimmten Knotens
als Peergruppenleiter hängt
von der Konnektivität
der Knoten in der Peergruppe ab. Der Auswahlprozess ist ein kontinuierlicher
Prozess, sodass bei Änderungen
der Konnektivität
von Knoten in der Peergruppe, zum Beispiel, wenn Knoten oder Leitungen
hinzugefügt
oder entfernt werden, der Prozess wiederholt wird, um sicherzustellen,
dass immer der geeignetste Knoten als Peergruppenleiter ausgewählt wird.
Als Teil des Auswahlprozesses muss jeder Knoten die aktuelle Konnektivität der Knoten
in der Peergruppe ermitteln. Das erfolgt durch Erzeugen von Konnektivitätsdaten
aus den von PTSEs definierten Knoten- und Leitungsstatusparametern,
wobei die Konnektivitätsdaten
den Status der Leitungen und Knoten in der Peergruppe und somit
die Art und Weise der aktuellen Verbindungen zwischen den Knoten
anzeigen. Der Prozess zur Ermittlung der Konnektivität kann durch
verschiedene bekannte Algorithmen implementiert werden, zum Beispiel
durch einen Farbgrafenalgorithmus, bei dem die Konnektivitätsdaten
in Form eines farbigen Grafen dargestellt werden. Die Konnektivitätsdaten
werden zusammen mit den bereits beschriebenen Topologiedaten im Speicher
des Knotens gespeichert. Diese Konnektivitätsdaten dienen bei bevorzugten
Ausführungsarten der
vorliegenden Erfindung zur Prüfung
der Erreichbarkeit von Adressen. Bei bevorzugten Ausführungsarten
beinhalten die im Speicher enthaltenen Adressdaten insbesondere
Knotenkennungen, die genau den Knoten angeben, von welchem die Adressdaten jeweils
stammen. Da das PNNI-Protokoll bereits festlegt, dass PTSEs die
Knotenkennung des Knotens beinhalten, von welchem das PTSE stammt,
kann als Knotenkennung für
eine bestimmte Adresse die Knotenkennung des zugehörigen PTSE
dienen. Somit kann die Erreichbarkeit einer Adresse einfach durch Prüfung der
Konnektivitätsdaten
geprüft
werden, um zu ermitteln, ob der der Knotenkennung in den Adressdaten
entsprechende Knoten erreichbar ist.
-
Es
ist klar, dass für
Merkmale, die hier in Bezug auf ein Verfahren zum Realisieren der
Erfindung beschrieben werden, im Allgemeinen auch Merkmale für eine Vorrichtung
zum Realisieren der Erfindung und umgekehrt bereitgestellt werden
können.
Ein anderer Aspekt der vorliegenden Erfindung stellt zum Beispiel
eine Adressenverwaltungsvorrichtung zur Verwaltung von Adressen
in einem Knoten bereit, der als Peergruppenleiter für eine Peergruppe
von Knoten in einer Hierarchieebene eines hierarchischen PNNI-Netzes
dient, wobei der Peergruppenleiter die Peergruppe gegenüber einem
oder mehreren Knoten in der nächsthöheren Hierarchieebene
repräsentiert und
einen Speicher zum Speichern der Topologiedaten der Peergruppe,
welche Adressdaten umfassen, die dem Peergruppenleiter von den Knoten
in der Peergruppe zugeliefert werden und Adressen darstellen, auf
die vom Netz zugegriffen werden kann, und Topologiedaten des Peergruppenleiters
aufweist, welche Adressdaten umfassen, die den Nachbarknoten vom
Peergruppenleiter zugeliefert werden und Adressen darstellen, auf
die über
die Peergruppe zugegriffen werden kann, wobei die Vorrichtung eine Steuerlogik
zum Zugreifen auf Daten im Speicher umfasst und für Folgendes
konfiguriert ist:
Prüfen,
ob die von den Adressdaten dargestellten Adressen über die
Peergruppe erreichbar sind;
Benachrichtigen der Nachbarknoten
bei Änderungen der
Erreichbarkeit so bezeichneter Adressen; und
Aktualisieren
der Topologiedaten des Peergruppenleiters entsprechend den Änderungen.
-
Ein
weiterer Aspekt der vorliegenden Erfindung stellt eine Einheit bereit,
die als Knoten in ein hierarchisches PNNI-Netz eingebunden wird,
wobei die Einheit so als Peergruppenleiter für eine Peergruppe von Knoten
in einer Ebene der Netzhierarchie fungieren kann, dass die Einheit
die Peergruppe gegenüber
einem oder mehreren Nachbarknoten in der nächsthöheren Hierarchieebene repräsentiert,
wobei die Einheit Folgendes umfasst: einen Speicher zum Speichern
von Topologiedaten der Peergruppe, welche Adressdaten umfassen,
die der Einheit von den Knoten in der Peergruppe zugeliefert werden
und Adressen für
den Zugriff aus dem Netz darstellen, und Topologiedaten des Peergruppenleiters,
welche Adressdaten umfassen, die den Nachbarknoten von der Einheit
zugeliefert werden und Adressen für den Zugriff über die
Peergruppe darstellen; und eine oben beschriebene Adressenverwaltungsvorrichtung.
-
Eine
Einheit zur Realisierung der Erfindung kann ein Switch, ein Router,
eine Bridge, ein Brouter oder eine andere Netzeinheit sein. Die
Erfindung erstreckt sich auch auf ein hierarchisches PNNI-Netz, welches
eine oben beschriebene Adressenverwaltungsvorrichtung umfasst, zum
Beispiel ein Netz, in welchem ein oder mehrere Knoten eine Einheit
umfassen, die die Erfindung realisiert.
-
Im
Folgenden werden anhand von Beispielen bevorzugte Ausführungsarten
der Erfindung unter Bezug auf die folgenden Zeichnungen beschrieben:
-
1 veranschaulicht
ein einfaches Beispiel eines hierarchischen PNNI-Netzes.
-
2 ist
eine schematische Darstellung der Hauptelemente einer Netzeinheit
zum Implementieren von Verfahren zur Realisierung der Erfindung.
-
3 ist
ein Flussdiagramm zur Darstellung eines Prozesses, der vom Knoten
eines Peergruppenleiters zur Realisierung der Erfindung implementiert
wird.
-
4 ist
ein Flussdiagramm zur Darstellung eines anderen Prozesses, der vom
Knoten eines Peergruppenleiters zur Realisierung der Erfindung implementiert
wird.
-
5 veranschaulicht
ein hierarchisches PNNI-Netz, auf welches sich die Beschreibung
der Funktionsweise eines Netzes zur Realisierung der Erfindung bezieht.
-
2 ist
ein schematisches Blockdiagramm einer Ausführungsart einer Netzeinheit,
welches die Hauptelemente zeigt, die beim Implementieren von Adressenverwaltungsverfahren
zur Realisierung der Erfindung beteiligt sind. Die Figur zeigt,
dass die Einheit, zum Beispiel ein ATM-Switch, eine Steuereinheit 1,
einen Speicher 2 und eine Schaltung 3 umfasst, welche
die Schnittstellen (interfaces, I/Fs) und das Koppelnetz darstellt,
die die Einheit über
seine Leitungen mit Nachbarknoten verbinden und über welche die Einheit mit
dem übrigen
Netz kommuniziert. Die Steuereinheit 1 steuert die Funktion
der Einheit im Allgemeinen und enthält eine Adressenverwaltungsvorrichtung
in Form einer (nicht im Einzelnen gezeigten) Steuerlogik, welche
die im Folgenden beschriebenen Adressenverwaltungsfunktionen steuert.
Die Steuerlogik kann als Hardware oder Software (Programmcode) bzw.
als Kombination von beiden implementiert werden, wobei dem Fachmann
aus der folgenden Beschreibung geeignete Implementierungen klar
werden. Insbesondere kann die Steuereinheit 1 durch einen
in geeigneter Weise programmierten Prozessor implementiert werden,
und der Speicher 2 kann ein interner Speicher des Prozessors oder
ein dem Prozessor zugeordneter externer Speicher sein. Bei der Implementierung
der Steuerlogik zur Adressenverwaltung durch Software kann die Software
separat (als Element des Programmcodes für eine Anzahl von Steuerfunktionen
oder auf andere Weise) geliefert werden, um sie in einen Prozessor zu
laden und diesen so zu konfigurieren, dass er in der beschriebenen
Weise arbeitet. Der Speicher 2 wird, wie in der Figur schematisch
dargestellt, zum Speichern diverser Daten benutzt, die bei den Adressenverwaltungsverfahren
zur Realisierung der Erfindung verwendet werden. Im vorliegenden
Fall dient die Einheit als Peergruppenleiter, und folglich umfassen
diese Daten eine Peergruppen(PG)-Topologiedatenbank 4,
eine Peergruppenleiter(PGL)-Topologiedatenbank 5 und ein
PTSE-Repository 6.
Die PG-Topologiedatenbank 4 umfasst eine Reihe von PTSEs,
welche die Knoten und Leitungen definieren, und Präfixe der
erreichbaren Adressen (reachable addresses, RAs) für die Peergruppe,
in welche die Einheit gerade gemäß dem PNNI-Protokoll eingebunden
ist. Die PGL-Datenbank 5 umfasst eine Reihe von PTSEs zur
nächsten
Ebene der PNNI-Hierarchie, in welcher die Peergruppenleitereinheit
ihre Peergruppe als einen logischen Gruppenknoten repräsentiert.
Die PGL-Topologiedatenbank
enthält
somit PTSEs, die vom Peergruppenleiter erzeugt wurden und sich auf
RAs innerhalb seiner Kind-Peergruppe beziehen, welche auf der nächsten Ebene oder
der Peergruppenleiterebene der Hierarchie bekannt gegeben wurden.
Der Inhalt der PG- und PGL-Topologiedatenbanken 4 und 5 stellt
eine Teilmenge aller gemäß dem PNNI-Protokoll
in den Knoten gespeicherten PTSEs dar, wobei die zusätzlichen PTSEs
im PTSE-Repository 6 des Speichers gespeichert werden.
-
In
einer Vorrichtung zur Realisierung der Erfindung wird die Verarbeitung
von PTSEs im Allgemeinen gemäß dem vom
PNNI-Protokoll vorgegebenen
Schema durchgeführt.
Bei Ausführungsarten
der Erfindung implementiert jedoch der Peergruppenleiter ein Adressenverwaltungssystem,
wobei die Verfügbarkeit
oder „Konnektivität" von RAs geprüft wird, wenn
Ereignisse eintreten, die eine Änderung
der RA-Konnektivität
anzeigen können.
Ein solches Ereignis kann durch ein PTSE angezeigt werden, das der
Peergruppenleiter von einem Knoten in seiner Kind-Peergruppe empfängt, oder
in einer direkt vom Peergruppenleiter entdeckten Statusänderung
einer der Leitungen des Peergruppenleiters selbst bestehen. Zur
Prüfung
der Konnektivität
einer RA benutzt der Peergruppenleiter die Konnektivitätsdaten,
die gemäß dem PNNI-Protokoll von den
Knoten verwaltet werden, um für
den oben erwähnten
Prozess zur Auswahl des Peergruppenleiters zur Verfügung zu stehen.
Wenn ein Knoten zur Peergruppe hinzugefügt bzw. aus ihr entfernt wird
oder eine Leitung eingerichtet wird bzw. eine vorhandene Leitung
ausfällt, muss
die Auswahl des Peergruppenleiters aufgrund der neuen Konnektivität der Peergruppe
neu getroffen werden. Daraufhin aktualisiert jeder Knoten seine Konnektivitätsdaten
durch die Änderungen
des Knoten- und Leitungsstatus. Der Prozess der Konnektivitätsaktualisierung
kann auf bekannte Weise implementiert werden, zum Beispiel durch
einen Farbgrafenalgorithmus, und die neuen Konnektivitätsdaten werden
z.B. in Form eines Farbgrafen in der PG-Topologiedatenbank des Knotens
gespeichert. Die Konnektivitätsdaten
zeigen somit die Konnektivität der
Knoten der Peergruppe an, welche jeweils durch eine Knotenkennung
angegeben sind. Zur Prüfung der
Konnektivität
von RAs mit Hilfe von Verfahren zur Realisierung der vorliegenden
Erfindung vergleicht der Peergruppenleiter die im PTSE einer bestimmten RA
enthaltene Knotenkennung (welche den Knoten angibt, von welchem
die RA stammt) mit den im Speicher gespeicherten Konnektivitätsdaten,
um zu ermitteln, ob der Knoten, von welchem die RA stammt, über die
Peergruppe erreicht werden kann. Wenn dies der Fall ist, wird auch
die RA als erreichbar angesehen. Wenn dies nicht der Fall ist, wird
die RA als nicht erreichbar angesehen.
-
Wie
oben erwähnt,
kann die Prüfung
der Konnektivität
einer RA vom Peergruppenleiter ausgelöst werden, der von einem Knoten
in seiner Kind-Peergruppe ein PTSE empfängt. 3 veranschaulicht
den Prozess, den der Peergruppenleiter der vorliegenden Ausführungsart
nach dem Empfangen eines solchen PTSE durchführt, für den speziellen Fall, dass
sich das PTSE auf den Präfix
einer erreichbaren Adresse bezieht. Der Prozess beginnt in Schritt 10,
wo das PTSE über
eine I/F&Vermittlungsschaltung 3 empfangen
und von der Steuerlogik in der Steuereinheit 1 als von
einem Knoten der Kind-Peergruppe stammend erkannt wird. Das empfangene
PTSE kann einen Knoten, eine Leitung oder eine RA betreffen. (Alternativ
kann das empfangene PTSE ein „leeres" PTSE sein, welches
anzeigt, dass ein zuvor empfangenes PTSE aus der Topologiedatenbank
gelöscht
werden soll, jedoch werden solche PTSEs gemäß dem vom PNNI-Protokoll angegebenen
Schema verarbeitet und brauchen hier nicht weiter behandelt zu werden).
In Schritt 11 prüft
die Steuerlogik, ob sich das PTSE auf eine RA bezieht. Wenn dies
nicht der Fall ist, verzweigt die Steuerlogik zu einem Prozess zur
Verarbeitung von Leitungs- oder Knoten-PTSEs in Schritt 12.
Dieser Prozess wird im Folgenden für den Fall von Leitungs-PTSEs
näher beschrieben.
Die Verarbeitung von Knoten-PTSEs ist für Ausführungsarten der vorliegenden
Erfindung von untergeordneter Bedeutung und braucht hier nicht ausführlich beschrieben
zu werden.
-
Wenn
das empfangene PTSE in Schritt 11 als RA-PTSE erkannt wurde,
greift die Steuerlogik in Schritt 13 auf die PG-Topologiedatenbank 4 zu,
um zu ermitteln, ob in dieser Datenbank bereits ein PTSE zu dieser
RA gespeichert ist. Wenn dies der Fall ist, d.h. weil das empfangene
PTSE einfach eine Aktualisierung oder Erneuerung eines früheren PTSE
ist, verzweigt die Steuerlogik zum üblichen Aktualisierungsprozess
in Schritt 14, der hier nicht beschrieben werden muss.
Wenn dies nicht der Fall ist, betrifft das PTSE eine neue RA, und
der Prozess geht weiter zu Schritt 15, in welchem die Steuerlogik
das empfangene PTSE in der PG-Topologiedatenbank 4 speichert. Dann
prüft die
Steuerlogik in Schritt 16, ob die neue RA im Augenblick über die
Peergruppe erreicht werden kann. Somit vergleicht die Steuerlogik,
wie oben beschrieben, die Ursprungsknotenkennung im empfangenen
PTSE mit den im Speicher 2 gespeicherten Konnektivitätsdaten,
um zu ermitteln, ob der Ursprungsknoten über die Peergruppe erreicht
werden kann. Wenn der Ursprungsknoten erreichbar ist, entscheidet
die Steuerlogik in Schritt 17, dass die RA erreichbar ist,
und der Prozess geht weiter zu Schritt 18. Dieser Schritt
stellt den Prozess der PTSE-Verwaltung auf der Hierarchieebene des
Peergruppenleiters dar. Somit erzeugt die Steuerlogik für die neue RA
ein neues PTSE, speichert das PTSE in der PGL-Topologiedatenbank 5 und
teilt die neue PTSE den Nachbarknoten des Peergruppenleiters auf
der nächsten
Hierarchieebene mit. Auf diese Weise wird die neue RA dem übrigen Netz
bekannt gegeben. Wenn jedoch in Schritt 17 festgestellt
wird, dass die neue RA nicht erreichbar ist (da der Ursprungsknoten anhand
der Konnektivitätsdaten
als nicht erreichbar ermittelt wurde), wird der Schritt 18 übersprungen und
der Prozess beendet. Folglich werden nur neue RAs, deren Erreichbarkeit
bestätigt
worden ist, im Netz verbreitet. Die Prüfung der RA-Konnektivität dient
somit als Filterprozess, damit keine unbrauchbaren RAs, zum Beispiel
RAs aus der alten Topologiedatenbank eines Knotens, der mit einer
neuen Netzkonfiguration verbunden wird, durch die Netzhierarchie
verbreitet werden. Dadurch werden wiederum die Größe von Übergangsdatenbanken
und die Bandbreitenanforderungen verringert sowie das Risiko ausgeschlossen,
dass die Routenwahl über
einen ungültigen
Pfad erfolgt.
-
3 veranschaulicht
den Basisprozess zur Verarbeitung neuer RAs, die der Peergruppenleiter aus
der Peergruppe empfängt.
Wenn die PGL-Topologiedatenbank 5 jedoch bereits ein PTSE
enthält, das
eine vom Peergruppenleiter erzeugte Sammeladresse definiert, welche
ebenfalls die neue RA darstellen kann, ist die Prüfung und
erneute Bekanntgabe der neuen RA nur dann erforderlich, wenn die neue
RA als Adresse gekennzeichnet ist, die nicht zusammengefasst werden
soll, zum Beispiel, wenn sie von besonderer Bedeutung ist. Daher
wird in den Prozess von 3, z.B. nach Schritt 15,
ein zusätzlicher
Schritt eingefügt,
mit dem die Steuerlogik für entsprechende
RAs ermittelt, ob in der PGL-Topologiedatenbank 5 bereits
ein PTSE vorhanden ist, das eine solche Sammeladresse definiert.
Wenn dies der Fall ist, kann der Prozess an diesem Punkt beendet werden.
-
Ein
anderes Ereignis, das eine Änderung
der Erreichbarkeit einer RA anzeigen kann, ist eine Änderung
des Leitungsstatus in der Peergruppe. 4 veranschaulicht
den Prozess zur Handhabung dieser Situation in der vorliegenden
Ausführungsart.
Dieser Prozess kann vom Peergruppenleiter ausgelöst werden, wenn er in Schritt 20 der
Figur eine Änderung des
Status einer seiner eigenen Leitungen feststellt. In diesem Fall
implementiert die Steuerlogik in Abhängigkeit davon, ob eine Leitung
eingerichtet wurde oder ausgefallen ist, den üblichen Prozess zum Hinzufügen oder
Löschen
eines Leitungs-PTSE in Schritt 21. Alternativ kann der
Prozess vom Peergruppenleiter ausgelöst werden, wenn er in Schritt 22 von
einem anderen Knoten in seiner Kind-Peergruppe ein PTSE empfängt, das
sich auf eine Änderung des
Leitungsstatus bezieht. Unabhängig
davon, wie der Prozess ausgelöst
wurde, geht er von Schritt 21 oder von Schritt 22 weiter
zu Schritt 23, in welchem der übliche Prozess zur Aktualisierung
der Konnektivitätsdaten
durchgeführt
wird, die zur Auswahl des Peergruppenleiters dienen. Die neuen,
entsprechend der Änderung
des Leitungsstatus aktualisierten Konnektivitätsdaten werden in der oben
beschriebenen Weise in der PG-Topologiedatenbank gespeichert. Falls
in diesem Augenblick keine Änderung
des Peergruppenleiters eingetreten ist, wird in Schritt 24 geprüft, ob eine
neue Leitung eingerichtet ist oder eine Leitung ausgefallen ist.
Wenn eine Leitung ausgefallen ist, geht der Prozess weiter zu Schritt 25,
wo die Steuerlogik auf die PGL-Topologiedaten
der PTSEs für
diejenigen RAs zugreift, die von anderen Knoten in seiner Kind-Peergruppe
empfangen wurden, d.h. PTSEs für
diejenigen RAs, welche nicht unmittelbar beim Peergruppenleiter
selbst erreichbar sind. (Die betreffenden PTSEs können durch
Prüfen
der Knotenkennungen der entsprechenden PTSEs in der PG-Topologiedatenbank
ermittelt werden, wobei die für
diesen Quervergleich benötigten
Daten in der üblichen
Weise im Datenbankrahmen gespeichert worden sind.) Wenn eine solche
RA eine vom Peergruppenleiter erzeugte Sammeladresse ist, entnimmt
die Steuerlogik die durch die Sammeladresse dargestellten RAs der
Sammeladresse ebenfalls der PG-Topologiedatenbank. Für jede so
ermittelte RA prüft
die Steuerlogik in Schritt 26 anhand der in Schritt 23 aktualisierten
Konnektivitätsdaten,
ob die RA noch über die
Peergruppe erreichbar ist. Wenn in Schritt 27 festgestellt
wird, dass alle RAs noch erreichbar sind, braucht nichts mehr unternommen
zu werden, und der Prozess endet hier. Wenn jedoch RAs in der PGL-Topologiedatenbank
in Schritt 27 als nicht erreichbar ermittelt werden (im
Fall der vom Peergruppenleiter erzeugten Sammeladressen bedeutet
dies, dass sämtliche
Einzeladressen einer vom Peergruppenleiter erzeugten Sammeladresse
nicht erreichbar sind), löscht
die Steuerlogik in Schritt 28 die zugehörigen PTSEs auf der PGL-Ebene
in der üblichen
Weise. Das heißt,
die Steuerlogik entfernt die zugehörigen PTSEs aus der PGL-Topologiedatenbank 5 und setzt
die Nachbarknoten in der nächsten
Hierarchieebene davon in Kenntnis, indem sie ein leeres PTSE aussendet.
Auf diese Weise werden RAs, auf die infolge eines Leitungsausfalls
nicht zugegriffen werden kann, sofort aus der Routingdomäne auf der
höheren Ebene
gelöscht,
wodurch sich die Größe der Übergangs-Topologiedatenbanken
sowie das Risiko verringert, dass Anrufe an eine nicht mehr erreichbare Adresse
gesendet werden. Im speziellen Fall der vom Peergruppenleiter zusammengefassten
Adressen erfolgt keine Bekanntmachung, wenn die Nichterreichbarkeit
nur eine oder einige der Sammeladressen betrifft, da die Sammeladresse
zumindest teilweise gültig
bleibt. Das stellt jedoch kein ernsthaftes Problem dar, da wichtige
Adressen generell nicht zusammengefasst werden, sodass wichtige Änderungen
dennoch dem übrigen
Netz bekannt gegeben werden.
-
Wenn
in Schritt 24 in 4 ermittelt
wird, dass eine Leitung eingerichtet wurde, geht der Prozess weiter
zu Schritt 30. Hier greift die Steuerlogik auf den Speicher 2 zu,
um RAs in der PG-Topologiedatenbank 4 zu
ermitteln, die von den PTSEs definiert werden und nicht durch PTSEs
in der PGL-Topologiedatenbank 5 dargestellt werden. Für jede so ermittelte
RA prüft
die Steuerlogik in der oben beschriebenen Weise in Schritt 31,
ob die RA erreichbar ist. Wenn in Schritt 32 keine neu
erreichbaren RAs gefunden werden, braucht nichts mehr unternommen zu
werden, und der Prozess endet. Wenn jedoch neue erreichbare RAs
gefunden werden, erzeugt die Steuerlogik in Schritt 33 für jede RA
ein neues PTSE, speichert das PTSE in der PGL-Topologiedatenbank 5 und
gibt die RA dem Netz bekannt, indem sie das neue PTSE an die Nachbarknoten
in der nächsten Hierarchieebene
verteilt. Auf diese Weise werden Adressen, die beim Einrichten einer
Leitung erreichbar werden, z.B., wenn eine zuvor ausgefallene Leitung
wiederhergestellt wird, sofort dem Netz bekannt gegeben.
-
Aus
den vorangehenden Erläuterungen
ist zu erkennen, dass Ausführungsarten
der vorliegenden Erfindung bedeutende Vorteile gegenüber bereits
existierenden Systemen bieten. Zum Beispiel werden Präfixe nicht
erreichbarer Adressen nicht über
höhere
Ebenen der PNNI-Routingdomäne
weiterverbreitet, und Topologiedatenbanken werden rasch von unbrauchbaren
Topologieelementen gesäubert,
sodass die Größe von Übergangs-Topologiedatenbanken
verringert wird.
-
Adressen,
die nicht mehr erreichbar sind, können sofort aus der Routingdomäne einer
höheren Ebene
entfernt werden, und ein unnötiges „Zurückführen" (wenn ein fehlgeschlagener
Anrufaufbau zum Quellenknoten für
erneutes Routing zurückgesendet wird)
kann in vielen Fällen
vermieden werden. Außerdem
kann das oben erwähnte
Problem des erneuten Routings beim Umleiten auch dann vermieden
werden, wenn das Zurückführen nicht
mehr hilft. Dies wird unter Bezug auf 5 veranschaulicht.
Diese Figur zeigt das Netz von 1, in welchem
ein ATM-Dienst mit dem Präfix
47111 der erreichbaren Adresse am Knoten AA2 angeschlossen ist.
Da der Dienst wichtig ist, wird am Knoten AC1 ein Ausweichdienst
mit derselben erreichbaren Adresse angeschlossen. Angenommen, am
Knoten AB2 wird ein Anruf empfangen, der an die Adresse 47111 adressiert
ist. Der Knoten AB2 berechnet dann ausgehend von seinem Bild der
Netztopologie eine Route in Form einer speziellen Transitliste („Designated
Transit List", DTL).
Somit berechnet der Knoten AB2 die DTL:
AB – AA
AB2 – AB3
-
Das
bedeutet, dass der Anruf auf der Hierarchieebene 1 von AB2 zu AB3
und in der Hierarchieebene 2 von AB zu AA verlaufen soll. AB2 kann
die Details der Knoten und Leitungen innerhalb der Peergruppe von
AA2 nicht erkennen, da diese Peergruppe in der Hierarchieebene 2
zum logischen Knoten AA abstrahiert wurde, sodass AB2 einfach PTSEs von
ihrem auf Ebene 2 als logischer Knoten AB fungierenden Peergruppenleiter
AB2 empfängt,
welche den Knoten AA und die RA 47111 definieren. In einem echten
Netz wird die Anforderung zum Anrufaufbau gemäß 5 von AB2
zu AB3 und von AB3 zu AA3 verlaufen. Ferner wird davon ausgegangen, dass
die Leitung zwischen AA3 und AA2 in der Figur gerade ausgefallen
ist. Beim vorhandenen Schema wird der Knoten AA3 den Anrufaufbau
verweigern, da es keine Route zum Zielknoten (AA2) in der Peergruppe
gibt. Daher kommt hier der Rückführungsmechanismus
zum Tragen, und die Anforderung zur Anrufaufbau wird zusammen mit
dem Ursachencode „Knoten
AA gesperrt" zum
Knoten AB2 zurückgesendet.
Der Knoten AB2 wird dann nicht versuchen, den Anruf umzuleiten,
da entsprechend seinem Bild von der Netztopologie der Knoten AC
nur über
den Knoten AA erreichbar ist, der jedoch gesperrt ist. Dieser Zustand
dauert so lange an, bis die nicht verbundenen Topologieelemente
des Knotens AA2 auf natürliche
Weise aus dem Netz verschwinden.
-
Im
Folgenden soll der Fall betrachtet werden, dass das Netz von 5 ein
die vorliegende Erfindung realisierendes Netz ist, sodass der Knoten
AA3 des Peergruppenleiters in der oben detailliert beschriebenen
Weise arbeitet. In diesem Fall stellt der Knoten AA3 fest, dass
die Leitung zu AA2 ausgefallen ist, und ermittelt, dass die Adresse
RA47111 jetzt nicht erreichbar ist. Der Knoten AA3 löscht daraufhin das
PTSE, welches die Adresse RA47111 darstellt, aus seiner Topologiedatenbank
und teilt dies AB und AC mit. AB und AC löschen das PTSE ebenfalls aus ihren
Datenbanken, sodass es folglich auch aus den Datenbanken aller Switches
in den Kind-Peergruppen von AB und AC gelöscht wird. Eine von AB2 ausgehende
Anforderung zum Anrufaufbau für
die Adresse RA47111 verläuft
dann nach der DTL:
AB – AA – AC
AB2 – AB3
da
RA47111 nicht mehr von AA bekannt gegeben wird. Im echten Netz wird
der Anrufaufbau deshalb über
die Switches AB2, AB3, AA3, AA1, AC2 und AC1 verlaufen, und der
Sicherungsdienst funktioniert wie gewünscht.
-
Obwohl
oben bevorzugte Ausführungsarten der
Erfindung detailliert beschrieben wurden, ist klar, dass an den
beschriebenen Ausführungsarten
viele Änderungen
und Abwandlungen vorgenommen werden können, ohne dass vom Geltungsbereich
der Erfindung abgewichen wird. Obwohl die Arbeitsweise der Ausführungsarten
zur Vereinfachung unter speziellem Bezug auf eine PNNI-Hierarchie
mit zwei Ebenen veranschaulicht wurde, können dieselben Prinzipien natürlich auch
in einem Knoten angewendet werden, der auf einer beliebigen anderen
Ebene einer Mehrebenenhierarchie als Peergruppenleiter fungiert.