DE60118143T2 - Verfahren und Vorrichtung zur Re-Synchronisierung einer Netzwerkstruktur-Datenbank in einem Kommunikationsnetz mit Topologie-Zustand Leitweglenkung-Protokollen - Google Patents

Verfahren und Vorrichtung zur Re-Synchronisierung einer Netzwerkstruktur-Datenbank in einem Kommunikationsnetz mit Topologie-Zustand Leitweglenkung-Protokollen Download PDF

Info

Publication number
DE60118143T2
DE60118143T2 DE60118143T DE60118143T DE60118143T2 DE 60118143 T2 DE60118143 T2 DE 60118143T2 DE 60118143 T DE60118143 T DE 60118143T DE 60118143 T DE60118143 T DE 60118143T DE 60118143 T2 DE60118143 T2 DE 60118143T2
Authority
DE
Germany
Prior art keywords
network
state
information
node
routing unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60118143T
Other languages
English (en)
Other versions
DE60118143D1 (de
Inventor
Shawn P. Manotic McAllister
Carl Nepean Rajsic
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Canada Inc
Original Assignee
Alcatel Canada Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Canada Inc filed Critical Alcatel Canada Inc
Application granted granted Critical
Publication of DE60118143D1 publication Critical patent/DE60118143D1/de
Publication of DE60118143T2 publication Critical patent/DE60118143T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/021Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/028Dynamic adaptation of the update intervals, e.g. event-triggered updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/03Topology update or discovery by updating link state protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/32Flooding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/58Association of routers
    • H04L45/586Association of routers of virtual routers

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft im Allgemeinen das Gebiet der Datenbasisresynchronisation für Netztopologien in Kommunikationsnetzen, die Routingprotokolle für den Topologiezustand aufweisen, und insbesondere auf ein Verfahren und eine Vorrichtung zur Durchführung einer Datenbasisresynchronisation für Netztopologien in solchen Netzen. Beispielsweise ist die vorliegende Erfindung für eine Datenbasisresynchronisation im Kontext einer Redundanzwiederherstellung im Anschluss an ein Knotenversagen oder ein Zurücksetzen gut geeignet, das eine zu einem Netzknoten gehörige aktive Routingeinheit betrifft.
  • Allgemeiner Stand der Technik
  • Routingprotokolle für den Topologiezustand werden in Kommunikationsnetzen verwendet, um Topologiezustandsinformation unter Knoten und Knotengruppen in solchen Netzen zu verbreiten oder bekannt zu machen. Die bekannt gemachte Topologiezustandsinformation wird wiederum verwendet, um optimierte Pfade für Kommunikationen über ein gesamtes gegebenes Netz zu berechnen. Wie sie in der vorliegenden Anmeldung verwendet wird, bedeutet eine Bezugnahme auf eine Topologiezustandsinformation Zustandsinformation für den gesamten Netzbereich als Ganzes. In bestimmten Netzprotokollen beinhaltet eine Topologiezustandsinformation sowohl Verbindungszustandsinformation als auch Knotenzustandsinformation. Zum Beispiel beinhaltet eine Verbindungszustandsinformation solche Attribute wie Verbindungseigenschaften, Betriebszustand der Verbindung, Portidentifikatoren und dezentrale Information über Nachbarn, die direkt benachbarte Nachbarknoten betrifft. Knotenzustandsinformation beinhaltet solche Attribute, wie Knotenidentifikatoren, Teilnehmergruppenidentifikatoren, Wahlzustand ausgezeichneter Knoten, Führungszustand ausgezeichneter Knoten und Information über lokal erreichbare Adressen.
  • Während Topologiezustandsinformation Zustandsinformation für einen Netzbereich als Ganzes betrifft, nimmt die vorliegende Anmeldung Bezug auf lokale Zustandsinformation, wenn sie sich mit von einem bestimmten Netzknoten lokal erzeugter Zustandsinformation befasst. Lokale Verbindungszustandsinformation gibt das an, wie ein gegebener Knoten den Status einer Kommunikation mit seinen Teilnehmerknoten versteht. Somit beinhaltet lokale Verbindungszustandsinformation ähnlich wie Verbindungsstatusinformation der Topologie ebenfalls solche Attribute wie Verbindungseigenschaften, Betriebszustand der Verbindung, Portidentifikatoren und dezentrale Information über Nachbarn, die direkt benachbarte Nachbarknoten betrifft, aber diese bezieht sich auf einen gegebenen Knoten im Gegensatz zu einer Vielfalt von Knoten, die Teil eines Netzbereichs bilden. Ebenso beinhaltet lokale Knotenzustandsinformation solche Attribute, wie Knotenidentifikatoren, Teilnehmergruppenidentifikatoren, Wahlzustand ausgezeichneter Knoten, Führungszustand ausgezeichneter Knoten und Information über lokal erreichbare Adressen. Diese betrifft wieder einen gegeben Knoten, wenn auf lokale Knotenzustandsinformation Bezug genommen wird, anstatt den Netzbereich als Ganzes zu betreffen, wenn auf Knotenzustandsinformation für die Topologie Bezug genommen wird. In der vorliegenden Anmeldung wird auf Zustandsinformation Bezug genommen, die sowohl Topologiezustandsinformation als auch lokale Zustandsinformation betrifft.
  • Bei einigen bekannten Topologiezustandsprotokollen können bestimmte Knoten in einem Kommunikationsnetz ausgezeichnete oder zusätzliche Verantwortung übernehmen, um die Routingfunktion für das Netz richtig arbeiten zu lassen. Zum Beispiel übernimmt bei dem IP-Routingprotokoll Open-Shortest-Path-First (OSPF), wie es in J. Moy: "OSPF Version 2", STD 54, RFC 2328, April 1998, beschrieben ist, ein Knoten, der als designierter Router (DR) identifiziert wurde, solche Verantwortlichkeiten. Ebenso werden im Protokoll für private Netz-Knoten-Schnittstellen oder Private Netz-Netz-Schnittstellen (PNNI) Verantwortlichkeiten dieser Art von einem Knoten übernommen, der Teilnehmergruppenführer (PGL) genannt wird. Das PNNI-Protokoll ist in den Druckschriften mit den Titeln: (i) "Private Network Interface Specification Version 1.0", Druckschrift Nr. af-pnni-0055.000 des ATM-Forums, März 1996, (ii) "Private Network-Network Interface Specification Version 1.0 Addendum (Soft PVC MIB)", Druckschrift Nr. af-pnni-0066.000 des ATM-Forums, September 1996, und (iii) "Addendum to PNNI V 1.0 for ABR parameter negotiation", Druckschrift Nr. af-pnni-0075.000 des ATM-Forums, Januar 1997, zusammen mit den Nachträgen, die in (iv) "PNNI V 1.0 Errata and PICS, Dokument Nr. af-pnni-0081.000, Mai 1997, gefunden wurden, spezifiziert (nachfolgend wird auf alle vorhergehenden Druckschriften (i) bis (iv) einschließlich kollektiv als "PNNI-Spezifikation" Bezug genommen).
  • Ein gegebener physikalischer Knoten in einem Netzraum kann ausgezeichnete Netzverantwortlichkeiten des oben genannten Typs durch einen Vorgang übernehmen, der als verteilte Wahl bekannt ist. In einem Plan der verteilten Wahl kommunizieren alle Knoten auf einer bestimmten Ebene einer Netzhierarchie, um den Knoten auszuwählen, der zusätzliche Aufgaben oder Verantwortlichkeiten in Bezug auf das Topologiezustandsprotokoll übernehmen soll. Fachleute auf dem Gebiet werden verstehen, dass die Durchführung des Vorgangs der verteilten Wahl abhängig von der speziellen Netzumgebung veränderliche Zeitbeträge brauchen werden. Wenn auf Grund von Ausfallzeiten die auszeichnende Position nicht von einem gegebenen Netzknoten ausgefüllt wird, können die Routingfunktionen eines Teils des Netzes oder des Netzbereiches als Ganzes auch verringerte Fähigkeiten oder Ineffizienz während des Ausfallzeitintervalls zeigen. Somit kann erwartet werden, dass bei Kommunikationsnetzen, die Topologiezustandsprotokolle verwenden, ein Wiederherstellungsintervall vom Routingsystem des Netzes nach einem Ausfall eines Netzknotens hingenommen werden muss. Zum Beispiel kann dies in veränderlichen Graden an Härte auftreten, wann immer der ausgefallene Knoten auf die Funktionen eines gewählten Netzknoten mit den zusätzlichen Verantwortlichkeiten trifft, auf die früher Bezug genommen wurde.
  • Einige Routingprotokolle spezifizieren einen gegebenen Grad an Knotenredundanz. Diese Redundanz soll die Wiederherstellungszeit des Routingsystems des Netzes im Falle eines Ausfalls verringern, der einen Knoten betrifft, der ausgezeichnete Protokollfunktionen der vorher genannten Art ausführt. Beispielsweise wird im OSPF-Protokoll die Verwendung eines designierten Sicherungsrouters (BDR) spezifiziert. Der designierte Sicherungsrouter wird beauftragt, einen Ausfall zu erfassen, der den gegenwärtig festgesetzten designierten Router betrifft. Bei Erfassung eines solchen Ausfalls wird der designierte Sicherungsrouter aufgefordert, Wiederherstellungsschritte zu unternehmen, um sich selbst an Stelle des ausgefallenen früheren designierten Routers als der neue designierte Router zu erklären. Allen weiteren Routern im betroffenen Abschnitt des gemeinsamen Netzes wird danach das Vorhandensein des neuen designierten Routerknotens gemeldet. Folglich wird, obwohl es unter dem OSPF-Protokoll nicht notwendig ist, einen dynamischen Wahlvorgang nach einem Ausfall, der einen designierten Routerknoten trifft, erneut auszuführen, ein Netzroutingausfall von einiger Dauer dennoch von allen Routern und Hosts im gemeinsamen Netz erfahren, die ursprünglich von dem ausgefallenen designieten Routerknoten bedient wurden. Dies ist so, weil die betroffenen Router und Hosts an der Wiederherstellung der Funktionen des Netzroutingsystems nach einem Ausfall teilnehmen, der ihren zugehörigen designierten Routerkonten trifft.
  • Andererseits wird beim PNNI-Protokoll gegenwärtig keine Vorkehrung für eine Redundanz des designierten Knotens getroffen. Als solches muss bei jedem Ausfall, der einen ausgezeichneten Netzknoten betrifft, der Vorgang der verteilten Wahl und seine zugehörigen Protokollaktionen erneut ausgeführt werden.
  • Beim PNNI-Protokoll kann ein physikalischer Knoten, der die Funktion eines Teilnehmergruppenführers auf einer Ebene der Topologiehierarchie ausführt, diese Funktion auf verschiedenen weiteren Ebenen der Hierarchie ausführen. Somit kann ein Ausfall, der einen solchen physikalischen Knoten betrifft, sehr wohl einen großen Teil des gesamten Netzes treffen. Ferner gibt es keine Vorkehrung im gegenwärtigen PNNI-Protokoll für einen Sicherungs-Teilnehmergruppenführer. Somit muss ein Ausfall der oben beschriebenen Art, der einen Teilnehmergruppenführer für mehrere Ebenen betrifft, von allen logischen Knoten erfasst werden, die einen Teil der verschiedenen Teilnehmergruppen bilden, die von dem Teilnehmergruppenführer für mehrere Ebenen repräsentiert werden. Diese logischen Knoten auf verschiedenen Ebenen der Netzhierarchie müssen danach einen neuen Teilnehmergruppenführer wählen. Wie bei dem vorher in Bezug auf das OSPF-Protokoll gegebene Beispiel kann der Ausfall des Teilnehmergruppenführers vielen Knoten bekannt sein und somit müssen sich solche Knoten im Allgemeinen alle an der Wiederherstellung der betroffenen Funktionen des Routingsystems beteiligen. Unter dieser Voraussetzung kann ein Ausfall eines Teilnehmergruppenführers in einem PNNI-Netz begreiflicherweise einen großen Abschnitt des Netzes treffen und kann unter vielen Umständen eine Unterbrechung des Routingverhaltens des Netzes für eine Zeitdauer bewirken, die für Diensteanbieter und Endnutzer unannehmbar sein kann.
  • Die obige Erörterung bezog sich auf die Auswirkungen eines Ausfalls, der einen Netzknoten betrifft, der ausgezeichnete Verantwortlichkeiten hat. Es wird jedoch von Fachleuten auf diesem Gebiet erkannt, dass ein Ausfall, der einen gewöhnlichen physikalischen oder logischen Knoten betrifft, der keine ausgezeichneten Verantwortlichkeiten hat, auch zu einem gewissen Maß an Unterbrechung der Routingfähigkeiten der benachbarten Knoten oder Einrichtungen führt, die von dem ausgefallenen gewöhnlichen Knoten bedient werden. Obwohl es bei einigen Knotenarchitekturen möglich sein kann, bestimmte Netzfunktionen, wie Paketweiterleitung oder Anrufverarbeitung, im Falle eines Routingfunktionsausfalls beizubehalten, erfordern Topologiezustandsprotokolle, wie OSPF und PNNI, dass jeder Netzknoten eines Bereichs eine Topologiedatenbasis mit seinen Nachbarn synchronisiert, bevor er zum Routingsystem zugelassen wird. Eine solche Synchronisation der Topologiedatenbasis muss bei diesen Netzprotokollen stattfinden, um sich wieder zu erholen.
  • Der Synchronisationsvorgang kann im Gesamtplan der Wiederherstellung abhängig von den Umständen Sekunden oder Minuten in Anspruch nehmen. Während der Synchronisation sind Netzeinrichtungen, die von dem ausgefallenen Knoten bedient werden, betroffen, und somit kann die Routingfunktion sehr wohl eine Unterbrechung erleiden. Während sich die obige Erörterung auf die Herausforderungen konzentrierte, die die Wiederherstellung aus einem Knotenausfall umgeben, werden Fachleute auf diesen Gebiet verstehen, dass analoge Probleme auftreten, die von anderen Ereignissen stammen, die erfordern würden, dass ein Knoten eine Synchronisation seiner Topologiedatenbasis unternimmt, beispielsweise ein Zurücksetzen des zu einem Netzknoten gehörigen Routingprozessors.
  • Im Stand der Technik wurden bestimmte Mechanismen entwickelt, um ein Umschalten zwischen verschiedenen Knoten in einer Weise sicherzustellen, die für Hosts, die einen ausgefallenen Router nutzen, transparent ist. Das Protokoll für einsatzbereite Reserverouter, das in T. Li, B. Cole, P. Morton und D. Li: "Cisco Hot Standby Router Protocol (HSRP)", RFC 2281, März 1998, beschrieben wurde, und das IP-Reserve-Protokoll nach P. Higginson und M. Shand: "Development of Router Clusters to Provide Fast Failover in IP Networks", 9 Digital Technical Journal, No. 3, Winter 1997, sind zwei Beispiele solcher transparenter Routerumschaltpläne. Wie unten ausführlicher erläutert wird, stellen jedoch Umschaltmechanismen dieses Typs nicht allgemein sicher, dass das Umschalten für die Router oder Knoten im Netz über die bestimmten Hosts oder Knoten hinaus, die dem ausgefallenen Knoten direkt benachbart sind, allgemein transparent ist. Im Stand der Technik wird der Ausfall eines Knotens typischerweise mittels eines gesonderten und anderen Knotens wiederhergestellt. Es wäre daher vorteilhaft, einen Mechanismus bereitzustellen, der gestattet, dass der Ausfall einer Routingkomponente eines Knotens durch eine weitere Routingkomponente desselben Knotens in einer Weise wiederhergestellt wird, die für alle Knoten außer seinen direkten Nachbarn transparent ist.
  • Folglich bieten die Topologiezustandsroutingprotokolle aus dem Stand der Technik Probleme und Herausforderungen, wenn sie einer Situation der Wiederherstellung aus einem Knotenausfall oder anderen Situationen gegenüberstehen, die erfordern können, dass ein Knoten seine Topologiedatenbasis synchronisiert, wenn er dies einmal vorher getan hat, und diese Probleme und Herausforderungen treten auf, ob der direkt vom Ausfall betroffene Knoten ausgezeichnete Verantwortlichkeiten hat oder nicht. Erstens unterbrechen bekannte Wiederherstellungsmechanismen die Routingfunktionen von wenigstens einem Teil eines Netzes und verursachen Auswirkungen auf einige der Einrichtungen, die das Netz nutzen. Der betroffene Anteil des Netzes variiert mit den Umständen. Beispielsweise kann erwartet werden, dass der betroffene Anteil des Netzes für einen Knoten, der ausgezeichnete Funktionen ausführt, ausgedehnter ist, als es für einen Knoten der Fall ist, der keine solchen Funktionen ausführt. Ebenso kann erwartet werden, dass der betroffene Anteil für einen Ausfall, der einen PNNI-Teilnehmergruppenführer betrifft, umfassender ist als für einen, der einen designierten OSPF-Router beeinflusst. Zweitens wird die Zeit, die erforderlich ist, um sich von einem Knoten- oder Verbindungsausfall zu erholen, variieren, kann jedoch in der Größenordnung von bis zu einigen Minuten oder länger liegen. Wie oben erwähnt, kann dieser Zeitrahmen direkt vom Ausfall betroffen sein, der ausgezeichnete Verantwortlichkeiten aufweist. Erstens unterbrechen bekannte Wiederherstellungsmechanismen die Routingfunktionen von wenigstens einem Teil eines Netzes und verursachen Auswirkungen auf einige der Einrichtungen, die das Netz nutzen. Der betroffene Anteil des Netzes variiert mit den Umständen. Beispielsweise kann erwartet werden, dass der betroffene Anteil des Netzes für einen Knoten, der ausgezeichnete Funktionen ausführt, ausgedehnter ist, als es für einen Knoten der Fall ist, der keine solchen Funktionen ausführt. Ebenso kann erwartet werden, dass der betroffene Anteil für einen Ausfall, der einen PNNI-Teilnehmergruppenführer betrifft, umfassender ist als für einen, der einen designierten OSPF-Router beeinflusst. Zweitens wird die Zeit, die erforderlich ist, um sich von einem Knoten- oder Verbindungsausfall zu erholen, variieren, kann jedoch in der Größenordnung von bis zu einigen Minuten oder länger liegen. Wie oben erwähnt, kann dieser Zeitrahmen für bestimmte Diensteanbieter oder Endnutzer unannehmbar sein. Drittens werden Netzressourcen in Form von Bandbreite und Verarbeitungszeit umdisponiert, da viele Knoten vom Ausfall in Kenntnis gesetzt werden müssen und es daher erforderlich ist, dass sie am Wiederherstellungsvorgang teilnehmen. Dies lenkt von anderen Netzaktivitäten im Allgemeinen ab und kann die Leistung und Stabilität des Netzroutingsystems im Besonderen verringern.
  • Es ist daher im Allgemeinen eine Aufgabe der vorliegenden Erfindung anzustreben, ein Verfahren und eine Vorrichtung zur erneuten Synchronisation einer Datenbasis in einem Netz mit einem Topologiezustandsroutingprotokoll bereitzustellen, das bzw. die für den Kontext einer Redundanzwiederherstellung nach einem Knotenausfall, der mit der Routingeinheit eines Netzknotens in Zusammenhang steht, besonders gut geeignet ist, und gemäß welchem bzw. welcher einige der von alternativen Techniken und Vorrichtungen aus dem Stand der Technik gezeigten Probleme in einigen Fällen gemildert oder überwunden werden können.
  • Die Abhandlung von Li, Cole, Morton mit dem Titel "RFC – Cisco Hot Standby Router Protocol (HSRP)", IETF, 'Online', März 1998 (1998-03), das bereits oben auf Seite 5 genannt wurde, offenbart ein Protokoll, das es Hosts gestattet, so zu erscheinen, als ob sie einen einzigen Router verwenden, und eine Verbindungsfähigkeit aufrechtzuerhalten, sogar wenn der tatsächliche erste Hoprouter, den sie verwenden, ausfällt. Mehrfache Router nehmen an diesem Protokoll teil und erscheinen zusammen als ein einziger virtueller Router. Das Protokoll stellt sicher, dass einer und nur einer der Router Pakete im Namen des virtuellen Routers weiterleitet. Die Endhosts leiten ihre Pakete zum virtuellen Router weiter.
  • Die Abhandlung aus dem ATM FORUM mit dem Titel "PNNI routing specification version 1.0 afpnni-0055.0, paragraph 5.8.3' PNNI ROUTING SPECIFICATION", 1. März 1996 (1996-03-01), Seiten 107–112, XP002196800, offenbart Fließalgorithmen, um eine zuverlässige Verteilung von PTSEs über eine ganze Teilnehmergruppe bereitzustellen, wodurch jeder Knoten der Teilnehmergruppe eine synchronisierte Topologiedatenbasis aufweist.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Die Erfindung ist ausgeführt, wie in den unabhängigen Ansprüchen 1 und 22 angegeben.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist eine schematische Darstellung einer hierarchischen Netztopologie, die zu einem Netzbereich gehört, der gemäß dem PNNI-Routingprotokoll arbeitet, in welcher das Verfahren und die Vorrichtung der vorliegenden Erfindung implementiert werden können, und die eine Eltern-Kind-Beziehung zwischen Gruppen von Knoten zeigt, die einen Teil der Netztopologie bilden;
  • 2 ist ein Automatendiagramm, das verschiedene Zustände und Übergangsereignisse für einen endlichen Automaten eines benachbarten Teilnehmers des PNNI-Routingprotokolls darstellt, wie im Stand der Technik bekannt;
  • 3 ist ein Automatendiagramm, das verschiedene Zustände und Übergangsereignisse für einen endlichen Automaten eines benachbarten Teilnehmers des PNNI-Routingprotokolls darstellt, wie es modifiziert ist, um die vorliegende Erfindung zu implementieren;
  • 4 ist ein Blockdiagramm eines einsatzbereiten redundanten Netzelements, bei dem das Verfahren der vorliegenden Erfindung implementiert werden kann.
  • AUSFÜHRLICHE BESCHREIBUNG VON AUSFÜHRUNGSFORMEN DER ERFINDUNG
  • Redundanztechniken für Netzkomponenten oder -einrichtungen, wie einssatzbereite, Redundanztechniken, sind Fachleuten auf dem Gebiet im Allgemeinen wohlbekannt. Unter Bezugnahme auf 1 werden diese Techniken unter Verwendung des darstellenden Beispiels eines Kommunikationsnetzes in Form eines PNNI-Netzbereiches 30 erläutert. Fachleute auf dem Gebiet werden jedoch verstehen, dass die vorliegende Erfindung ebenfalls auf andere Arten von Netzen angewendet oder angepasst werden kann, zum Beispiel Netze mit Internetzprotokoll (IP), für welche eine intermittierende Bekanntmachung von Information über den lokalen Zustand durch das Routingprotokoll Open Shortest Path First (OSPF) erreicht wird. Ebenso ist die vorliegende Erfindung nicht nur für Situationen der Wiederherstellung aus Ausfällen, die mit einer Routingeinheit eines Netzknotens in Zusammenhang stehen, sondern auch für andere Kontexte geeignet, wo es notwendig oder wünschenswert sein kann, dass ein Netzknoten seine Topologiedatenbasis erneut synchronisiert.
  • Topologiezustandsroutingprotokolle und Synchronisation der Topologiedatenbasis
  • Das Kommunikationsnetz 2 weist einen Netzbereich 30 auf, der aus einer Vielzahl von Netzknoten 32 bis 41 besteht, die typischerweise Verteilungssysteme sind. Die Netzknoten 32 bis 41 sind mittels physikalischer oder logischer Verbindungen 42 bis 53, untereinander verbunden, die jeweils zwei gegebene Verteilungssysteme des Netzbereichs verbinden. Das Netzelement oder der Knoten 56 (auch mit "A.1.2" bezeichnet) des PNNI-Netzbereichs 30 ist so gezeigt, dass er die Rolle des Teilnehmergruppenführers für die mit "PG(A)" bezeichnete Elternteilnehmergruppe angenommen hat, und das Vorhandensein des Knotens 36 auf der Ebene der Elternteilnehmergruppe ist die Folge des Führerstatus des Knotens 56. Der Knoten 36 stellt einen Netzbereich in Form der Tochterteilnehmergruppe 55 (auch mit "PG(A.1)" bezeichnet) dar, die die Netzknoten 56 bis 60 einer niedrigeren Ebene umfasst. Die Netzknoten 56 bis 60 der niedrigeren Ebene sind mittels physikalischer oder logischer Verbindungen 62 bis 67 untereinander verbunden, die jeweils zwei gegebene Verteilungssysteme der niedrigeren Ebene verbinden. Die Funktionen, die den Teilnehmergruppenführer von PG(A.1) definieren, sind auf dem Verteilungssystem implementiert, der den Knoten 56 (auch mit "A.1.2") der niedrigeren Ebene enthält. PG(A.1) ist eine Tochterteilnehmergruppe von PG(A) und ist in PG(A) als logischer Knoten 36 dargestellt, der im physikalischen Verteilungssystem 56 implementiert ist. Ebenso kann die mit "PG(A)" bezeichnete Elternteilnehmergruppe selbst eine Tochterteilnehmergruppe sein, die auf einer höheren Ebene der Routinghierarchie durch einen einzelnen logischen Knoten (nicht gezeigt) repräsentiert wird.
  • Gemäß der bekannten Redundanztechniken stellt der spezielle Knoten, Verteiler oder andere Netzeinheit, für die ein Fehlertoleranzschutz erwünscht ist, wenigstens zwei Routingprozessoren in einem einzigen Netzelement bereit. Ein Routingprozessor führt die Funktion des Aufrechterhaltens der Verbindungsfähigkeit mit seinen direkt benachbarten Nachbarknoten und des Teilens von Topologiezustandsinformation mit jenen Knoten aus. Vorzugsweise sind die Routingprozessoren mittels getrennter physikalischer Komponenten konfiguriert. Zum Beispiel können die physikalischen Komponenten jeweils in Form von getrennten Hardwarekarten vorliegen, die im selben Netzverteiler, wie im Netzknoten 56 ("A.1.2") bereitgestellt sind. Wenn für Redundanzzwecke zwei Prozessoren bereitgestellt sind, nimmt eine der betreffenden physikalischen Komponenten die Rolle der aktiven Routingeinheit für das redundante Netzelement an, und die andere der physikalischen Komponenten ist somit eine inaktive Routingeinheit dafür.
  • Bei Erfassen eines Ausfalls der aktiven Routingeinheit wird die inaktive Routingeinheit in Dienst gerufen, um die Funktionen der ausgefallenen aktiven Routingeinheit zu übernehmen. Diese Prozedur wird Aktivitätsumschaltung genannt. Weil beide dieser Routingeinheiten mit demselben Knoten (z.B. dem Netzknoten 56) verbunden sind, muss der Knoten selbst keine seiner ausgezeichneten Verantwortlichkeiten aufgeben. Ebenso müssen nur direkt benachbarte Knoten des ausgefallenen Knotens in Form von direkt benachbarten Knoten von Elternteilnehmergruppen (z.B. die Netzknoten 34, 35, 37, 38) und jegliche direkt benachbarten Knoten von Tochterteilnehmergruppen (z.B. die Netzknoten 57, 59, 60) aufgefordert oder anderweitig herangezogen werden, um an der Netzwiederherstellung teilzunehmen. Wie unten erörtert können jedoch Topologiezustandsprotokolle dennoch bewirken, dass mehr Knoten als die dem ausgefallenen Knoten direkt benachbarten während des Wiederherstellungsvorgangs betroffen sind (z.B. die Netzknoten 32, 33, 39, 40, 41, 58), wodurch die für das Stattfinden einer Wiederherstellung erforderliche Zeit sowie die bei diesem Vorgang verbrauchten Netzressourcen erhöht werden.
  • Es können bestehende Fähigkeiten und Techniken verwendet werden, um einen Plan des Redundanzschutes bei einer gegebenen Netzarchitektur, wie dem PNNI-Netzbereich 30, zu implementieren. Diese Fähigkeiten und Techniken können zum Beispiel die Verwaltung von Aktivitätszuständen in den verschiedenen Netzknoten und die Synchronisation von Zustandsinformation zwischen den aktiven und inaktiven Routungkomponenten beinhalten. Diese Zustandsinformation für eine Netztopologie ist typischerweise in einer Synchronisationsdatenbasis, auch Topologiedatenbasis genannt, gespeichert, die zu jedem Netzkonten eines Routingbereichs gehört. Typischerweise wird die Synchronisationsdatenbasis in den zur Debatte stehenden Netzknoten gespeichert. Die Datenbasissynchronisation ist ein bestehender Routingprotokollmechanismus für den Topologiezustand, der sicherstellt, dass benachbarte Knoten in einem Netz einen gemeinsamen Blick auf die gesamte Topologie des Netzes teilen. Einige Signalisierungsprotokolle, zum Beispiel ITU-T Q.2931, weisen Mechanismen auf, wie Status-Enquiry-Schemata, um eine Synchronisation des Anrufzustands zwischen zwei Netzknoten auszuführen.
  • Ein Problem bei solchen bekannten Redundanzschemata ist, dass wenn ein Ausfall bei einem Netzknoten auftritt, wie Knoten 56, der einen Knoten 36 der höheren Ebene implementiert, werden die betroffenen Verbindungen in PG(A) 44, 45, 47 und 51 zu und vom ausgefallenen Knoten nach einiger Zeit oder während ein neuer PGL in PG(A.1) anfängt, die Verantwortung zu übernehmen, um den Knoten 36 der höheren Ebene zu implementieren, nicht mehr bekanntgemacht. Mit anderen Worten, wenn der neu aktive Routingprozessor eine Datenbasissynchronisation mit seinen Teilnehmern startet, verlangt das laufende PNNI-Protokoll, dass die Bekanntmachung von lokaler Zustandsinformation von jedem der an der Synchronisation beteiligten Knoten entfernt oder entzogen wird, bis zu der Zeit, wenn die Synchronisation stattgefunden hat. Somit hört ein ausgefallener Knoten auf, seine lokale Zustandsinformation bekanntzumachen, und die Knoten, die dem ausgefallenen Knoten benachbart sind, hören ebenfalls auf, ihre jeweilige lokale Zustandsinformation bekanntzumachen. Dies gilt für jede Synchronisation, die unter dem gegenwärtig bekannten Protokoll ausgeführt wird, bei der nach einer Aktivitätsumschaltungs- oder einer Prozessorzurücksetzungssituation eine Synchronisation erforderlich ist. Bei dem bestehenden PNNI-Protokoll ist es für einen ausgefallenen Knoten, der eine einsatzbereite Redundanzfähigkeit bereitstellt, erforderlich, seine Topologiedatenbasis mit benachbarten Knoten zu synchronisieren. Dies ist so, weil der aktive und der inaktive Routingprozessor eines solchen Knotens im Allgemeinen vor dem Ausfall intern Topologiezustandsinformation ausgetauscht haben werden und dieser Austausch periodisch stattgefunden haben wird. Als solches kann es sehr wohl einen Verlust an Topologiestatusinformation in dem Intervall zwischen dem letzten Austausch von Zustandsinformation und dem Ausfall geben, welcher Informationsverlust von dem inaktiven Routingprozessor bei einer Aktivitätsumschaltung von dem vorher aktiven und ausgefallenen Routingprozessor her erfahren wird.
  • Wenn ein ausgefallener Knoten, wie der Knoten 56, der auch den Knoten 36 einer höheren Ebene implementiert, der gemäß dem Stand der Technik mit einer Redundanzfähigkeit versehen ist, über eine Aktivitätsumschaltung neu gestartet wird, muss die neu aktive Routingeinheit, die sich aus der Aktivitätsumschaltung ergibt, daher die betroffenen Verbindungen 62, 63 und 64 zu und vom Knoten 56 und die betroffenen Verbindungen 44, 45, 47 und 51 zu und vom Knoten 36 der höheren Ebene wieder aufbauen. Wenn ein ausgefallener Knoten, wie der Knoten 56, ein Teilnehmergruppenführer für eine gegebene Anzahl von Tochterteilnehmergruppenknoten 56, 57, 58, 59 und 60 ist, müssen weitere Verbindungen in der Tochterteilnehmergruppe ebenfalls wieder aufgebaut werden. Um ihre Existenz als Teil der Netztopologie wieder aufzubauen, müssen ein ausgefallener Knoten und seine Nachbarn zuerst vom Vorhandensein jedes anderen erfahren. Im PNNI-Protokoll erfüllen im Falle von Teilnehmergruppen der untersten Ebene, die durch physikalische Verbindungen oder VPCs verbunden sind, Zwei-Wege-Gruß-Pakete diese Funktion der Entdeckung von Nachbarn. Als nächstes tauschen der ausgefallene Knoten und jeder seiner Nachbarn zusammengefasste Information über die Topologiedatenbasis miteinander aus. Typischerweise tauschen im PNNI-Protokoll die neuerdings wieder bekannt gemachten Knoten zuerst Köpfe von PNNI-Topologiezustandselementen (PTSEs) aus, um zu ermitteln, ob die Konten synchron sind oder nicht. Falls nicht, findet eine Synchronisation statt. Wenn ein Knoten eine PTSE-Kopf-Information empfängt, die ein PTSE bekannt macht, das er noch nicht aufweist, fordert er das bekanntgemachte PTSE an und aktualisiert seine Topologiedatenbasis mit dem angeforderten PTSE, wenn es empfangen wurde.
  • Wenn die Synchronisation einmal abgeschlossen ist, wird lokale Zustandsinformation zwischen dem ausgefallenen Knoten und seinen Nachbarknoten in der Netztopologie des Netzbereichs 30 bekannt gemacht, wodurch jeder Knoten seine Erreichbarkeit allen anderen Nachbarknoten bekannt macht. Im PNNI-Protokoll findet diese Bekanntmachung beispielsweise mittels eines regelmäßigen Vorgangs statt, der als Flooding bekannt ist. Wie vorher erläutert wirkt sich dieser bekannte Vorgang des Wiederaufbauens nachteilig auf die Routingfunktionen des Netzes aus. Darüber hinaus werden während des Wiederaufbaus des ausgefallenen Knotens 56 gemäß bekannter Techniken Netzressourcen verbraucht.
  • Modifikationen an bekannten endlichen Automaten für benachbarte Teilnehmer, der Datenstruktur benachbarter Teilnehmer und der Paketstruktur der Datenbasiszusammenfassung
  • Gemäß einer darstellenden Ausführungsform kann die Erfindung in den Kontext des PNNI-Protokolls übernommen werden, indem verschiedene Modifikationen an dem bestehenden Protokoll von 2 vorgenommen werden. Wie im folgenden ausführlicher beschrieben betreffen diese Modifikationen im Allgemeinen einen bekannten endlichen Automaten (FSM) 5 für benachbarte Teilnehmer und ihre zugehörigen Übergangsereignisse, weitere Aspekte der Datenstruktur benachbarter Teilnehmer und die Paketstruktur der Datenbasiszusammenfassung. Unter Bezugnahme auf 3 werden für den modifizierten endlichen Automaten 10 für benachbarte Teilnehmer zwei zusätzliche Zustände für das Ausführen einer Neusynchronisation der Datenbasis definiert. Die zusätzlichen Zustände werden mit Zustand 22 Vollständiger Austausch und Zustand 24 Vollständiges Laden bezeichnet. Der Zustand 22 Vollständiger Austausch, der Zustand 24 Vollständiges Laden und ihre zugehörigen Zustandsübergänge sind unten ausführlicher beschrieben.
  • Neue Übergangsereignisse, die eine Zustandsänderung für benachbarte Teilnehmer bewirken, werden den in Abschnitt 5.7.3 der PNNI-Spezifikation gefundenen bestehenden Zustandsübergängen ebenfalls hinzugefügt. Diese neuen Zustandsübergänge können mit Ereignis DS (Neusynch) Fehlanpassung und Ereignis 25 (Neu)synch erledigt bezeichnet werden. Weitere zusätzliche Zustandsübergänge, wie 28 Verhandlung (vollständig) erledigt, 27 Laden (vollständig) erledigt und 26 Austausch (vollständig) erledigt, werden mit den neuen Zuständen der vorliegenden Erfindung verwendet. Diese zusätzlichen Zustandsübergänge spiegeln jeweils die bestehenden Zustandsübergänge 15 Verhandlung erledigt, 21 Laden erledigt und 17 Austausch erledigt wider. Dies ist unten ausführlicher unter Bezugnahme auf Tabelle 1 beschrieben. Mit Ausnahme der hinzugefügten Zustände und Zustandsübergänge, die sich auf sie beziehen, sind die verschiedenen Zustände, die die endlichen Automaten 10 umfassen, sonst wie gewöhnlich in der PNNI-Spezifikation in Abschnitt 5.7.2 davon definiert.
  • Die Datenstruktur benachbarter Teilnehmer, die normalerweise im PNNI-Protokoll vorhanden ist und in Abschnitt 5.7.1 der PNNI-Spezifikation definiert ist, ist erfindungsgemäß durch die Definition eines zusätzlichen Zeitgebers und eines zugehörigen Zeitgeberintervalls ebenfalls modifiziert, wenn sie mit dem bestehenden Protokoll verglichen wird. Der zusätzliche Zeitgeber und das Intervall können für die Bequemlichkeit der Beschreibung mit Inaktivitätszeitgeber für die Neusynchronisation bzw. Inaktivitätsintervall für die Neusynchronisation bezeichnet werden. Wenn dieses neue zeitlich festgelegte Intervall ausläuft, signalisiert es ein mögliches Problem mit einer Neusynchronisation der Datenbasis. In einem solchen Fall wird von der Neusynchronisation des Knotens gefordert, eine Datenbasissynchronisation aus dem Verhandlungszustand 14 heraus auszuführen, wie es normalerweise aufgetreten wäre, wenn die Datenbasissynchronisation ursprünglich im bestehenden PNNI-Protokoll stattgefunden hätte.
  • Zuletzt wird gemäß einer Implementierung der vorliegenden Erfindung für die Paketstruktur der Datenbasiszusammenfassung ein hinzugefügtes Bit bereitgestellt. Das zusätzliche Bit ist unten vollständiger beschrieben und kann mit Bit Vollständige Synchronisation (SF) bezeichnet werden. Dieses hinzugefügte Bit zur Paketstruktur der Datenbasiszusammenfassung soll benachbarten Knoten signalisieren, dass eine Neusynchronisation stattfindet, beispielsweise auf Grund eines Ausfalls einer Routingeinheit, so dass diese Neusynchronisation nicht gemäß dem bestehenden PNNI-Protokoll folgt.
  • Unter Bezugnahme auf 2 wird der bekannte endliche Automat 5 für benachbarte Teilnehmer in der bestehenden PNNI-Spezifikation verwendet, um den Zustand von Datenbanksynchronisation und Flooding zu beschreiben, die zwischen einem gegebenen Knoten und jedem seiner benachbarten Teilnehmer stattfindet. Wie bekannt weist der spezifizierte endliche Automat 5 für benachbarte Teilnehmer einen Anfangszustand 12 (mit "BTunten" bezeichnet), der angeben würde, dass es keine aktiven Verbindungen zu dem bestimmten benachbarten Teilnehmer gibt. Der erste Schritt, eine Adjazenz mit einem benachbarten Teilnehmer zu erzeugen, ist der Verhandlungszustand 14, der Fachleuten auf dem Gebiet bekannt ist. Das auslösende Ereignis für den Übergang zum Verhandlungszustand 14 aus dem Anfangszustand 12 wird mit Ereignis 13 Port hinzufügen bezeichnet. Hier hat eine Grußzustandsmaschine für eine Verbindung zum benachbarten Teilnehmer typischerweise seinen 2-Wege-Innenzustand (2-WayInside state) erreicht, wie jenen bekannt ist, die mit diesem Gebiet vertraut sind. Im Verhandlungszustand 14 entscheiden zwei benachbarte Teilnehmer, welcher der Knoten der Master für den Zweck des Datenbasisaustauschs ist, und wird eine DS-Folgennummer gewählt. Fachleute auf diesem Gebiet werden verstehen, dass die DS-Folgennummer verwendet wird, um einzelne Pakete der Datenbasiszusammenfassung zu identifizieren.
  • Wenn der Verhandlungszustand 14 abgeschlossen ist, empfangen benachbarte Teilnehmerknoten während des Austauschzustandes 16 Datenbasiszusammenfassungspakete von dem zur Debatte stehenden Konten. Somit überführt das Ereignis 15 Verhandlung erledigt den endlichen Automaten 10 in den Austauschzustand 16. Wie bereits beim PNNI-Protokoll bekannt beschreibt der zur Debatte stehende Knoten im Austauschzustand 16 dem benachbarten Knoten seine Topologiedatenbasis. Wenn der benachbarte Knoten die Datenbasiszusammenfassungspakete verarbeitet hat, kann er dann fortfahren, seine erforderliche PTSE-Information anzufordern. Wenn eine solche Information erforderlich ist, überführt das Ereignis 17 Austausch erledigt den endlichen Automaten 5 in den Ladezustand 18.
  • Während des Ladezustands 18, wird vom benachbarten Knoten erforderliche PTSE-Information angefordert und wenigstens ein PTSE-Kopf wurde von diesem Knoten noch nicht empfangen. Zuletzt wird in den bekannten PNNI-Protokoll der Zustand 20 Vollständig erreicht, wenn eines von zwei Ereignissen eintritt. Erstens kommt man im Zustand 20 Vollständig an, wenn der Empfang von PTSE-Information abgeschlossen ist, nach dem Ladezustand 18 über das Ereignis 21 Laden erledigt. Alternativ kann der Zustand 20 Vollständig direkt nach dem Austauschzustand 16 über das Ereignis 19 Synchronisation erledigt erreicht werden, wenn die Verarbeitung von Datenbasiszusammenfassungspaketen zeigt, dass vom benachbarten Knoten keine PTSE-Information gefordert wird. Im Zustand 20 Vollständig besitzt der zur Debatte stehende Knoten alle PTSE-Information, von der bekannt ist, dass sie vom benachbarten Teilnehmer verfügbar ist, und Verbindungen zum benachbarten Teilnehmer können mittels PTSEen bekannt gemacht werden.
  • Wie oben erwähnt und unter besonderer Bezugnahme auf 3 werden mit einer Ausführungsform der vorliegenden Erfindung dem bekannten endlichten Automaten 5 neue Zustände hinzugefügt, um einen modifizierten endlichen Automaten 10 zu erreichen. Die zusätzlichen Zustände werden mit Zustand 22 Vollständiger Austausch und Zustand 24 Vollständiges Laden bezeichnet. Wenn ein Knoten im Zustand 20 Vollständig vor einem Ausfall oder vor irgendeiner anderen Forderung nach weiterer Synchronisation bereits seine Topologiedatenbasis synchronisiert hat und der Knoten danach eine Neusynchronisation der Datenbasis fordert, sendet er initialisierte Datenbasiszusammenfassungspakete an seine benachbarten Teilnehmerknoten. Wie oben angedeutet haben diese Datenbasiszusammenfassungspakete ihre jeweiligen Bits Vollständige Synchronisation (FS) gesetzt. Das Ereignis 28 Austausch (vollständig) erledigt überführt dann den endlichen Automaten 10 in den Zustand 22 Vollständiger Austausch. Im Zustand 22 Vollständiger Austausch versucht ein Knoten, seine Topologiedatenbasis seinen Nachbarknoten zu beschreiben, ohne seine Bekanntmachungen von lokalen Zustandsinformationen für seine Nachbarn zu entziehen, die bekanntgemacht wurden, als er den Zustand 20 Vollständig erreichte. Ebenso entziehen die Nachbarknoten, mit denen der zur Debatte stehende Knoten synchronisiert, auch nicht die Bekanntmachung ihrer jeweiligen lokalen Zustandsinformation für den Knoten, der eine Neusynchronisation der Datenbasis anfordert. Es werden Datenbasiszusammenfassungspakete zu den benachbarten Teilnehmer eines Knotens gesendet, der eine Neusynchronisation anfordert. Diese Datenbasiszusammenfassungspakete haben ebenfalls ihre jeweiligen Bits Vollständige Synchronisation (FS) gesetzt. Wenn als Folge der Verarbeitung von Datenbasiszusammenfassungspaketen der ausgefallene Knoten ermittelt, dass keine PTSE-Pakete erforderlich sind, geht der endliche Automat 10 über das Ereignis 25 (Neu)Synchronisation erledigt in den Zustand 20 Vollständig über.
  • Wenn andererseits PTSE-Pakete erforderlich sind, führt der endliche Automat 10 das Ereignis 26 Austausch (vollständig) erledigt aus, um in den Zustand 24 Vollständiges Laden überzugehen. Die erforderlichen PTSEe werden dann von dem Knoten angefordert, der eine Neusynchronisation erfordert, wobei Verbindungen zu den benachbarten Teilnehmerknoten immer noch bekanntgemacht werden, wie im Zustand 20 Vollständig. Wenn alle angeforderten PTSE-Pakete von dem Knoten, der die Neusynchronisation anfordert, empfangen wurden, überführt das Ereignis 27 Laden (vollständig) erledigt den endlichen Automaten 10 in den Zustand 20 Vollständig. Somit sendet und empfängt der die Neusynchronisation anfordernde Knoten Datenbasiszusammenfassungs-, PTSE-Anforderungs- und PTZP-Pakete, während sich seine Nachbardatenstruktur im Zustand 20 Vollständig, Zustand 22 Vollständiger Austausch und Zustand 24 Vollständiges Laden befindet. Die gleichen Zustandsübergänge, die oben beschrieben wurden, treten auch im Zusammenhang mit den benachbarten Teilnehmerknoten des ausgefallenen Knotens auf, der eine Neusynchronisation anfordert.
  • Als solches werden gemäß der vorliegenden Erfindung zwei Prozeduren für die Datenbasissynchronisation bereitgestellt, eine die arbeitet, wenn sich die Teilnehmerdatenstruktur im Zustand 20 Vollständig befindet, und die andere, die arbeitet, wenn sich die Datenstruktur im Verhandlungszustand 14 befindet. Verbindungen zwischen benachbarten Teilnehmern der untersten Ebene können nur in PTSEen bekanntgemacht werden, wenn sich der endliche Automat 10 im Zustand 20 Vollständig, Zustand 22 Vollständiger Austausch oder im Zustand 24 Vollständiges Laden befindet. Somit bewirken für benachbarte Teilnehmer der untersten Ebene, die durch physikalische Verbindungen oder VPCs verbunden sind, Wechsel in den Zustand 20 Vollständig von anderen Zuständen als dem Zustand 22 Vollständiger Austausch oder Zustand 24 Vollständiges Laden und Wechsel aus der Gruppierung von Zuständen heraus, die aus dem Zustand 20 Vollständig, Zustand 22 Vollständiger Austausch und Zustand 24 Vollständiges Laden besteht, neue Fälle eines oder mehrerer PTSEe, damit ein synchronisierender Knoten oder damit ein neusynchronisierender Knoten an den Anfang gesetzt (originated) oder geleert wird.
  • Zusätzlich zu den Zustandsübergängen, die in 2 dargestellt sind, weist das bekannte PNNI-Protokoll vier zusätzliche Ereignisse auf. Diese werden als die Ereignisse DSFehlanpassung, SchlechtePTSEAnforderung, PortFallenlassen und PortZuletztFallenlassen bezeichnet. Jedes der Ereignisse DSFehlanpassung und SchlechtePTSEAnforderung erzwingen einen Zustandsübergang zum Verhandlungszustand 14. Die DSFehlanpassung tritt immer dann auf, wenn ein Datenbasiszusammenfassungspaket empfangen wurde, wobei irgendeines der folgenden auftritt: (i) es weist eine unerwartete DS-Folgennummer auf, (ii) sein Initialisierungsbit ist unerwartet gesetzt oder (iii) es weist ein unerwartetes Setzen seines Master-Bits auf. Gemäß der vorliegenden Erfindung ist das bekannte Ereignis DSFehlanpassung so modifiziert, dass das Ereignis auch immer dann auftritt, wenn ein Datenbasiszusammenfassungspaket ein unerwartetes Setzen des Bits Vollständige Synchronisation aufweist. Ebenso tritt gemäß der vorliegenden Erfindung ein Ereignis DSFehlanpassung auch auf, wenn der vorher erwähnte Inaktivitätszeitgeber für die DS-Neusynchronisation abläuft. Jede der vorhergehenden Bedingungen gibt an, dass im Datenbasissynchronisationsvorgang ein Fehler aufgetreten ist. Das bekannte Ereignis PortFallenlassen bewirkt keinen Zustandswechsel und das bekannte Ereignis PortZuletztFallenlassen erzwingt den Zustand 12 BTunten. Bei dem bekannten Ereignis PortFallenlassen hat der Grußautomat für eine Verbindung zum benachbarten Teilnehmer den Zwei-Wege-Innenzustand verlassen. Bei dem bekannten Ereignis PortZuletztFallenlassen wird ermittelt, dass alle Ports zu dem Nachbarknoten fallengelassen wurden.
  • Wie oben eingeführt ist ein Ereignis, das als das Ereignis DS(Neusynch)Fehlanpassung bezeichnet werden kann, so definiert, dass es immer dann stattfindet, wenn ein Datenbasiszusammenfassungspaket empfangen wird, bei dem sein Bit Vollständige Synchronisation gesetzt ist, und ein solches Paket sein Initialisierungsbit gesetzt hat. Wie es für die Erörterung des Ereignisses DSFehlanpassung im bekannten PNNI-Protokoll der Fall war, bedeutet analog das Auftreten des Ereignissses DSNeusynchFehlanpassung, dass im Verlauf der Datenbasisneusynchronisation ein Fehler aufgetreten ist. Die DSNeusynchFehlanpassung gibt an, dass eine Datenbasisneusynchronisation erneut versucht wird, ohne dass der endliche Automat 10 in den Verhandlungszustand 14 abfällt.
  • Als nächstes wird der endliche Automat 10 des benachbarten Teilnehmers gemäß einer Ausführungsform der vorliegenden Erfindung unter Bezugnahme auf Tabelle 1, die unten dargelegt ist, ausführlicher beschrieben. In Tabelle 1 sind der neue Zustand 22 Vollständiger Austausch und Zustand 24 Vollständiges Laden zusammen mit möglichen Übergangsereignissen für diese Zustände in zusammengefasster Form dargelegt, sowohl im bekannten PNNI-Protokoll vorhanden als auch als neu hinzugefügt oder modifiziert durch die vorliegende Erfindung. Jede Zelle der Tabelle stellt eine Paarung von Übergangsereignis und angegebenen Zustand als dem laufenden Zustand des Knotens zu Beginn des spezifizierten Übergangsereignisses dar. Jede Zelle spiegelt den neuen Zustand, der als Folge des spezifizierten Übergangsereignisses erreicht wird, zusammen mit einem vom zur Debatte stehenden Knoten vorzunehmenden Schritt wider. Tabelle 1 zeigt nur die Aspekte des vorhandenen endlichen Automaten 5 des benachbarten Teilnehmers des PNNI-Protokolls, die durch die vorliegende Erfindung modifiziert werden oder die durch zusätzliche Funktionen oder Prozeduren zum Implementieren der vorliegenden Erfindung ergänzt werden, um beim modifizierten endlichen Automaten 10 anzukommen. Diese Modifikationen und Hinzufügungen zum bestehenden PNNI-Protokoll werden unten ausführlicher erörtert.
  • TABELLE 1: Modifikationen am bestehenden endlichen PNNI-Automaten des benachbarten Teilnehmers
    Figure 00170001
  • Figure 00180001
  • Wie in der bestehenden PNNI-Spezifikation, in ihrem Abschnitt 5.7.4, bezeichnet FSM_ERR einen internen Implementierungsfehler. Somit sollte das Ereignis 28 Verhandlung (vollständig) erledigt normalerweise nicht auftreten, während sich der endliche Automat 10 in irgendeinem anderen Zustand außer dem Zustand 20 Vollständig befindet. Ebenso sollten die Ereignisse 26 Austausch (vollständig) erledigt und 25 (Neu)synchronisation erledigt nicht während irgendwelcher anderen Zustände außer dem Zustand 22 Austausch vollständig auftreten. Ebenso wird nicht erwartet, dass das Ereignis 27 Laden (vollständig) erledigt in irgendeinem der Zustände außer dem Zustand 24 Laden vollständig auftritt. Darüber hinaus wird nicht erwartet, dass das Ereignis DS (Neusynchronisation) Fehlanpassung in irgendeinem der Zustände außer dem Zustand 22 Austausch vollständig und dem Zustand 24 Laden vollständig auftritt.
  • Jedes der vorhandenen Ereignisse 15 Verhandlung erledigt, 17 Austausch erledigt, 19 Synchronisation erledigt und 21 Laden erledigt sind nicht bereitgestellt, um in den neuen Zuständen 22 Vollständiger Austausch und 24 Vollständiges Laden der vorliegenden Erfindung aufzutreten. Aus diesem Grund ist in Tabelle 1 für das Abbilden der vorhandenen Ereignisse auf die neuen Zustände der Protokollfehlerzustand FSM_ERR widergespiegelt. Die vorhandenen Ereignisse werden durch die analogen Ereignisse 28 Verhandlung (vollständig) erledigt, 26 Austausch (vollständig) erledigt, 25 (Neu)Synchronisation erledigt und 27 Laden (vollständig) erledigt ersetzt, wie unten ausführlicher erläutert.
  • Wenn das Ereignis Port hinzufügen stattfindet, während sich der zur Debatte stehende Knoten im Zustand 12 BTunten befindet, wird den bekannten Prozeduren gefolgt, die im PNNI-Protokoll für die in Abschnitt 5.7.4 der PNNI-Spezifikatiohn mit Ds1 bezeichnete Aktion beschrieben sind. Im Allgemeinen fordern die Prozeduren das Senden von Datenbasiszusammenfassungspaketen ohne PTSE-Zusammenfassungen an. Diese Datenbasiszusammenfassungspakete werden in dem Zeitintervall erneut übertragen, das durch den bekannten DS-Rxmt-Zeitgeber der benachbarten Teilnehmerdatenstruktur spezifiziert ist. Der Unterschied bei den Ds1-Prozeduren der vorliegenden Erfindung ist, dass das Datenbasiszusammenfassungspaket ein zusätzliches Bit in Form des vorher erwähnten Bits Sychronisation vollständig enthält. Bei den Ds1-Prozeduren, auf die in Tabelle 1 Bezug genommen wird, sind die Bits Synchronisation vollständig in den zur Debatte stehenden Datenzusammenfassungspaketen nicht gesetzt. Wo ein Ereignis Port hinzufügen während des Zustands 22 Vollständiger Austausch oder während des Zustands 24 Vollständiges Laden stattfindet, bleibt die Maschine im selben Zustand. Im Falle von benachbarten Teilnehmern der untersten Ebene, die durch physikalische Verbindungen oder VPCs verbunden sind, wird die Portidentifikation der Portidentifikationsliste der benachbarten Teilnehmerdatenstruktur hinzugefügt. Ebenso wird eine Verbindung zum benachbarten Teilnehmer hinzugefügt und ein neuer Fall eines PTSE erzeugt. Dieser Satz von Aktionen ist der gleiche, wie im PNNI-Protokoll spezifiziert, wie es besteht und als Aktion Ds8 in Abschnitt 5.7.4 der PNNI-Spezifikation bezeichnet ist.
  • Wenn sich der endliche Automat 10 in seinem Zustand 20 Vollständig befindet und das Ereignis 28 Verhandlung (vollständig) erledigt stattfindet, wird ein Übergang zum Zustand 22 Vollständiger Austausch ausgelöst und der Satz an Aktionen, die in Tabelle 1 als Ds11 bezeichnet sind, findet statt. Unter diesem Ds11 genannten Satz von Aktionen und wie im Falle mit den Ds2 genannten Aktionen im bekannten PNNI-Protokoll beginnt der zur Debatte stehende Knoten, eine Zusammenfassung der Inhalte seiner Topologiedatenbasis in Form von Datenbasiszusammenfassungspaketen zum benachbarten Knoten zu senden. Die Prozeduren, denen bei diesem Übergang zum Zustand 22 Vollständiger Austausch gefolgt wird, sind mit denen identisch, die in Abschnitt 5.7.4 der PNNI-Spezifikation als Ds2 bezeichnet sind, mit der Ausnahme, dass die vom Knoten gesendeten Datenzusammenfassungspakete das Bit Vollständige Synchronisation gesetzt haben. Auch wird gemäß der vorliegenden Erfindung beim Zustandsübergang der Inaktivitätszeitgeber für die Neusynchronisation als Teil der Ds2-Prozeduren gestartet, wenn dieser Zeitgeber nicht bereits läuft.
  • Wo während des Zustands 22 Vollständiger Austausch des endlichen Automaten 10 ein Ereignis 26 Austausch (vollständig) erledigt eingeworfen wird, findet ein Übergang zum Zustand 24 Vollständiges Laden statt. Danach folgt die Ds3-Aktion, wie in Abschnitt 5.7.4 der bestehenden PNNI-Spezifikation beschrieben. Es wird nämlich der DS-Rxmt-Zeigeber angehalten, falls er nicht vorher angehalten wurde. Es werden PTSE-Anforderungspakete zum zur Debatte stehenden benachbarten Teilnehmer oder zu anderen benachbarten Teilnehmern gesendet oder weiterhin gesendet, wie Fachleuten auf dem Gebiet bekannt ist. Jedes der PTSE-Anforderungspakete fordert enige der neureren PTSEe des benachbarten Teilnehmers an, die vorher entdeckt, aber noch nicht empfangen wurden. Diese PTSEe werden in der PTSE-Anforderungsliste der benachbarten Teilnehmerdatenstruktur aufgelistet.
  • Immer wenn ein Ereignis 25 (Neu)Synchronisation erledigt eingeworfen wird, während sich der Automat in seinem Zustand 22 Vollständiger Austausch befindet, geht der endliche Automat 10 in den Zustand 20 Vollständig über. Dieses mit dem Zustand 22 Vollständiger Austausch verbundene Ereignis wird Ereignis 25 (Neu)Synchronisation erledigt genannt, um das Ereignis von seinem Gegenstück zu unterscheiden, das während des Austauschzustands 16 stattfindet.
  • Immer wenn ein Ereignis 27 Laden (vollständig) erledigt eingeworfen wird, während sich der endliche Automat 10 in seinem Zustand 24 Vollständiges Laden befindet, geht der Automat in den Zustand 20 Vollständig über. Dieses mit dem Zustand 24 Vollständiges Laden verbundene Ereignis wird in 1 Ereignis Laden (vollständig) erledigt genannt, um das Ereignis von seinem Gegenstück zu unterscheiden, das während des Ladezustands 18 stattfindet.
  • In der Situation, dass ein Ereignis 27 Laden (vollständig) erledigt während des Zustands 24 Vollständiges Laden stattfindet, oder in der Situation, dass ein Ereignis 25 (Neu)Synchronisation erledigt während des Zustands 22 Vollständiger Austausch stattfindet, werden der DS-Rxmt-Zeitgeber und Inaktivitätszeitgeber für die Neusynchronisation, der in der darstellenden Ausführungsform der vorliegenden Erfindung eingeführt und oben erwähnt wurde, angehalten. Diese Aktionen, die den zur Debatte stehenden Zustandsänderungen folgen, werden in Tabelle 1 Ds12 genannt. Dies gibt an, dass die Neusynchronisation der Datenbasis abgeschlossen ist.
  • Wenn entweder ein Ereignis DSFehlanpassung oder ein Ereignis SchlechtePTSEAnforderung während des Austauschzustands 16 oder des Ladezustands 18 eingeworfen wird, wird ein Zustandsübergang zum Verhandlungszustand 14 bewirkt. Ebenso werden die bekannten Prozeduren, die im bestehenden PNNI-Protokoll mit Ds5 bezeichnet sind, anschließend an den zur Debatte stehenden Zustandsübergang ausgelöst. Diese Prozeduren sind in Abschnitt 5.7.4 der PNNI-Spezifikation beschrieben. Gemäß der vorliegenden Erfindung wird jedoch auch der Inaktivitätszeitgeber für die Neusynchronisation angehalten, falls er nicht vorher angehalten wurde, wie es bei dem Zeitgeber für eine verzögerte Teilnehmerrückmeldung, dem DS-Rxmt-Zeitgeber und dem Anforderung-Rxmt-Zeitgeber des bekannten Protokolls der Fall ist. Gemäß der vorliegenden Erfindung ist das Bit Vollständige Synchronisation der Datenbasiszusammenfassungspakete, die von dem Knoten in den bekannten Ds5-Prozeduren gesendet werden, nicht gesetzt.
  • Die Ereignisse DSFehlanpassung und SchlechtePTSEAnforderung der Tabelle 1, die während des Zustands 22 Vollständiger Austausch oder des Zustands 24 Vollständiges Laden auftreten, bewirken einen Übergang zum Verhandlungszustand 14. Die durchzuführenden Aktionen sind wie oben im Falle des gleichen Ereignisses spezifiziert, das während des Austausch- oder Ladezustands auftritt, mit der Ausnahme, dass PTSEe modifiziert werden, um jegliche Bekanntmachung von Verbindungen für den Nachbar zu entfernen. Der letztere Schritt ist im bestehenden PNNI-Protokoll bekannt und ist als Aktion Ds6 in Abschnitt 5.7.4 der PNNI-Spezifikation beschrieben.
  • Der endliche Automat 10 wird immer mit dem Ereignis DSFehlanpassung ausgeführt, wenn der Inaktivitätszeitgeber für die Neusynchronisation abläuft. Dies zwingt den Knoten, alle Verbindungen zum nicht antwortenden Nachbarn zu entziehen, die in PTSEen gegenwärtig bekannt gemacht werden. Der endliche Automat 10 wird dann zum Verhandlungszustand 14 gezwungen, in dem der Knoten noch einmal versucht, Datenbasen in der bekannten Weise ausgehend vom Verhandlungszustand 14 zu synchronisieren. Im Falle einer erfolgreichen Neusynchronisation der Datenbasis wird der Inaktivitätszeitgeber für die Neusynchronisation angehalten.
  • Wenn, immer noch unter Bezugnahme auf Tabelle 1, während des Zustands 22 Vollständiger Austausch oder des Zustands 24 Vollständiges Laden eine DS(Neusynchronisations)Fehlanpassung auftritt, wird zum Zustand 20 Vollständig zurückgekehrt. Die bei diesem Übergangsereignis vorgenommene Aktion führt dazu, dass der Zeitgeber für eine verzögerte Teilnehmerrückmeldung, der DS-Rxmt-Zeitgeber und der Anforderung-Rxmt-Zeitgeber angehalten werden, falls sie nicht vorher angehalten wurden. Alle genannten Zeitgeber sind im bestehenden PNNI-Protokoll bekannt. Die Liste der erneuten Übertragungen für den Teilnehmer, die Liste der verzögerten Teilnehmerrückmeldungen, die PTSE-Anforderungsliste und alle damit in Verbindung stehenden Zeitgeber werden ebenfalls gelöscht. Der Austausch von Datenbasiszusammenfassungen, wobei das Bit Vollständige Synchronisation gesetzt ist, muss erneut beginnen. Dann inkrementiert der zur Debatte stehende Knoten die DS-Folgennummer für seinen benachbarten Teilnehmer, erklärt sich selbst zum Master durch setzen des Master-Bits auf einen Wert von Eins und beginnt das Senden von Datenzusammenfassungspaketen, bei denen die Bits Initialisieren, Mehr, Master und Vollständige Synchronisation gesetzt sind. Es werden diesen Paketen keine PTSE-Zusammenfassungen beigefügt. Zuletzt wird der DS-Rxmt-Zeitgeber gestartet und das Datenbasiszusammenfassungspaket wird zu jeder DSRxmt-Intervallzeit erneut übertragen, wenn kein Datenbasiszusammenfassungspaket empfangen wird, um es zu quittieren. Alle diese Aktionen beim Zustandswechsel zum Zustand 20 Vollständig wurden in Tabelle 1 Ds13 genannt.
  • Das Ereignis Port fallenlassen von Tabelle 1 führt dazu, dass der endliche Automat 10 den Zustand 22 Vollständiger Austausch und Zustand 24 Vollständiges Laden beibehält, wann immer sich der endliche Automat 10 jeweils in jenen Zuständen befindet. Wie bei den Ds9-Prozeduren von Abschnitt 5.7.4 des bestehenden PNNI-Protokolls wird die zur Debatte stehende Verbindung aus der Port-Identifikationsliste in der entsprechenden benachbarten Teilnehmerdatenstruktur entfernt. Wenn es ein PTSE gibt, das diese Verbindung bekannt macht, wird ein neuer Fall des betroffenen PTSE ausgelöst. Wenn die Verbindung die letzte aktive Verbindung zum Nachbarn ist, wird das Ereignis PortZuletztFallenlassen erzeugt. Wie in Tabelle 1 gezeigt, überführt das Ereignis PortZuletztFallenlassen den endlichen Automaten 10 immer dann in den Zustand BTunten, wenn sich der endliche Automat 10 im Zustand 22 Vollständiger Austausch oder Zustand 24 Vollständiges Laden befindet. Wie im PNNI-Protokoll bekannt und in Abschnitt 5.7.4 der PNNI-Spezifikation Ds10 genannt werden der Zeitgeber für eine verzögerte Teilnehmerrückmeldung, der DS-Rxmt-Zeitgeber und der Anforderung-Rxmt-Zeitgeber angehalten, falls sie nicht vorher angehalten wurden. Wie bei der bestehenden Ds10-Prozedur bekannt werden die Liste der erneuten Übertragungen für den Teilnehmer, die Liste der verzögerten Teilnehmerrückmeldungen, die PTSE-Anforderungsliste zusammen mit ihren in Verbindung stehenden Zeitgebern gelöscht. Gemäß der vorliegenden Erfindung wird jedoch der Inaktivitätszeitgeber für die Neusynchronisation ebenfalls angehalten, falls er nicht vorher angehalten wurde.
  • Senden von Datenbasiszusammenfassungspaketen
  • Das Senden von Datenbasiszusammenfassungspaketen ist im Allgemeinen wie durch das bekannte PNNI-Protokoll spezifiziert, mit den unten erwähnten Ausnahmen. Im Zustand 20 Vollständig kann jedoch ein Knoten eine Datenbasis-Neusynchronisation auslösen, indem er leere Datenbasiszusammenfassungspakete sendet, in denen die Bits Initialisieren, Mehr, Master und Vollständige Synchronisation gesetzt sind. Der Inaktivitätszeitgeber für die Neusynchronisation wird gestartet, wenn das erste solche Datenbasiszusammenfassungspaket gesendet wird, wenn der Zeitgeber nicht bereits läuft. Wenn solche Datenbasiszusammenfassungspakete gesendet werden, muss der DS-Rxmt-Zeitgeber neu gestartet werden. Diese Pakete werden von dem Knoten, der eine Datenbasis-Neusynchronisation auslöst, alle Sekunden des DS-Rxmt-Intervalls erneut übertragen, wenn der DS-Rxmt-Zeitgeber aktiviert.
  • Ein Knoten in seinem Zustand 20 Vollständig sendet als Antwort auf empfangene Datenbasiszusammenfassungspakete, bei denen die Bits Initialisieren, Mehr, Master und Vollständige Synchronisation gesetzt sind, von einem benachbarten Teilnehmer, der eine Datenbasis-Neusynchronisation anfordert, ebenfalls Datenbasiszusammenfassungspakete. Wenn ein Knoten eine Datenbasis-Neusynchronisation auslöst, sendet er Datenbasiszusammenfassungspakete, bei denen die Bits Vollständige Synchronisation, Initialisieren, Mehr und Master auf einen Wert von Eins gesetzt sind. Ein Knoten, der einem Nachbarknoten antwortet, der eine Datenbasis-Neusynchronisation anfordert, setzt die Bits Vollständige Synchronisation, Initialisieren, Mehr und Master, wie unten ausführlicher beschrieben wird. Wenn ein Knoten auf das erste solche Datenbasiszusammenfassungspaket an einen Nachbarknoten, der eine Datenbasis-Neusynchronisation anfordert, antwortet, startet er den Inaktivitätszeitgeber für die Neusynchronisation, wenn er nicht bereits läuft.
  • Im Verhandlungszustand 14 sendet der zur Debatte stehende Knoten leere Datenbasiszusammenfassungspakete, wie beim bestehenden Protokoll, mit der Ausnahme, dass das Bit Vollständige Synchronisation in dem Datenbasiszusammenfassungspaket nicht gesetzt ist, das gemäß der vorliegenden Erfindung so modifiziert wurde, dass es ein zusätzliches Bit in Form des Bits Vollständige Synchronisation beinhaltet. Im Zustand 22 Vollständiger Austausch sendet der zur Debatte stehende Knoten Datenbasiszusammenfassungspakete, die mit denen im bekannten Austauschzustand 16 identisch sind, aber das Bit Vollständige Synchronisation ist in solchen Datenbasiszusammenfassungspaketen gesetzt.
  • Empfangen von Datenbasiszusammenfassungspaketen
  • Als nächstes wird dass Verarbeiten eines empfangenen Datenbasiszusammenfassungspakets durch einen Knoten erläutert. Das Empfangen von Datenbasiszusammenfassungspaketen ist im Allgemeinen wie durch das bekannte PNNI-Protokoll spezifiziert, mit den unten erwähnten Ausnahmen. Wenn ein Datenbasiszusammenfassungspaket akzeptiert wird, werden eine Anzahl von Paketfeldern in der entsprechenden benachbarten Teilnehmerdatenstruktur im bekannten Datensatz gespeichert, der als Identifizierungsinformation für das letzte empfangene Datenbasiszusammenfassungspaket gekennzeichnet ist. Somit werden die Paketmarken, die aus den Bits Initialisieren, Mehr, Master und Reserviert bestehen, auf diese Weise zusammen mit der DS-Folgennummer gespeichert, alles wie es beim bestehenden PNNI-Protokoll bekannt ist. Das Bit Vollständige Synchronisation der vorliegenden Erfindung wird jedoch auch zusammen mit den vorhergehenden Bits gespeichert. Wo diese gespeicherten Elemente in zwei aufeinanderfolgenden Datenbasiszusammenfassungspaketen, die vom benachbarten Teilnehmer her empfangen werden, identisch gesetzt sind, wird das zweite solche Datenbasiszusammenfassungspaket bei der Verarbeitung von empfangenen Datenbasiszusammenfassungspaketen als Duplikat betrachtet.
  • Wie beim bekannten PNNI-Protokoll muss ein Datenbasiszusammenfassungspaket ignoriert werden, wenn das Paket empfangen wird, wenn sich der endliche Automat 10 im Zustand 12 BTunten befindet.
  • Bei der bestehenden PNNI-Spezifikation führt ein Datenbasiszusammenfassungspaket, das empfangen wird, wenn sich der endliche Automat 5 im Verhandlungszustand 14 befindet, und das zu einem der beiden Fälle passt, die in Abschnitt 5.7.6 der bestehenden PNNI-Spezifikation unter der Überschrift "Verhandeln" spezifiziert sind, den endlichen Automaten 5 mit dem Ereignis Verhandlung erledigt und mit einem Übergang zum Austauschzustand 16 aus. Im ersten dieser Fälle des bekannten Protokolls sind die Bits Initialisieren, Mehr und Master auf einen Wert von Eins gesetzt. Bei der vorliegenden Erfindung muss zusätzlich dazu, dass die Bits Initialisieren, Mehr und Master die vorhergehenden Werte aufweisen, das Bit Vollständige Synchronisation auf einen Wert von Null gesetzt sein, damit ein Paket als nächstes in der Folge akzeptiert und in der bereits bekannten Weise gemäß dem ersten Fall, der unter der Überschrift "Verhandeln" von Abschnitt 5.7.6 erörtert wird, weiter verarbeitet wird. Im zweiten dieser Fälle des bekannten Protokolls sind die Bits Initialisieren, Mehr und Master auf einen Wert von Null gesetzt. Bei der vorliegenden Erfindung muss zusätzlich dazu, dass die Bits Initialisieren und Master die vorhergehenden Werte aufweisen, das Bit Vollständige Synchronisation auf einen Wert von Null gesetzt sein, damit ein Paket als nächstes in der Folge akzeptiert und in der bereits bekannten Weise gemäß dem zweiten Fall, der unter der Überschrift "Verhandeln" von Abschnitt 5.7.6 erörtert wird, weiter verarbeitet wird.
  • Bei einem Datenbasiszusammenfassungspaket, das empfangen wird, wenn sich der endliche Automat 10 im Austauschzustand 16 befindet, wird den Prozeduren gefolgt, die in der bestehenden PNNI-Spezifikation unter der Überschrift "Austauschen" von Abschnitt 5.7.6 dargelegt sind, mit einer Ausnahme. Es wird nämlich direkt nach dem dritten bestehenden Schritt, der unter besagter Überschrift von Abschnitt 5.7.6 aufgezählt wurde, eine neue Bedingung eingefügt. Diese neue Bedingung erfordert, dass, wenn das Bit Vollständige Synchronisation gesetzt ist, das Ereignis DS-Fehlanpassung erzeugt und die Verarbeitung des Datenbasiszusammenfassungspakets angehalten wird. Die Prozeduren, denen für den Empfang eines Datenbasiszusammenfassungspakets im Austauschzustand 16 zu folgen ist, sind ansonsten wie in der bestehenden PNNI-Spezifikation beschrieben.
  • Der Empfang von Datenbasiszusammenfassungspaketen, wenn sich ein Knoten in seinem Ladezustand 18 befindet, gibt an, dass der Knoten eine gesamte Folge von Datenbasiszusammenfassungspaketen gesendet und empfangen hat. Somit sollten die einzigen so empfangenen Pakete Duplikate sein. Alle anderen empfangenen Datenbasiszusammenfassungspakete müssen das Ereignis DS-Fehlanpassung erzeugen, was eine Rückkehr zum Verhandlungszustand 14 bewirkt, wobei die beiden Teilnehmer ihre Datenbasen erneut gemäß dem bekannten PNNI-Protokoll synchronisieren. Die Prozedur, der gefolgt wird, wenn ein Datenbasiszusammenfassungspaket im Ladezustand 18 empfangen wird, ist daher wie in Abschnitt 5.7.6 des bestehenden PNNI-Protokolls spezifiziert.
  • Wenn sich ein Knoten im Zustand 20 Vollständig befindet und bei dem empfangenen Datenbasiszusammenfassungspaket sein Bit Vollständige Synchronisation gesetzt ist, dann muss, falls das empfangene Paket zu einem der beiden Fälle passt, die folgen, der endliche Automat 10 mit dem Ereignis 28 Verhandlung (vollständig) erledigt ausgeführt werden. Der endliche Automat 10 wird dadurch veranlasst, zum Zustand 22 Vollständiger Austausch überzugehen. Das Paket wird dann als das nächste in der Folge akzeptiert und weiter verarbeitet, wie unten dargelegt.
  • Fall 1: Empfangender Knoten ist ein Slave
  • Dieser Fall deckt die Situation ab, in der die Bits Initialisieren, Mehr und Master auf einen Wert von Eins gesetzt sind, die Inhalte des Pakets leer sind und die Knotenidentifikation des benachbarten Teilnehmers größer als die Knotenidentifikation ist, die zu dem empfangenden Knoten gehört.
  • In dieser Situation ist der zur Debatte stehende Knoten ein Slave und beim Erzeugen des Ereignisses 28 Verhandlung (vollständig) erledigt nimmt der Slave-Knoten die folgende Folge von Aktionen vor. Zuerst wird der DS-Rxmt-Zeitgeber angehalten. Als nächstes wird der Inaktivitätszeitgeber für die Neusynchronisation gestartet, falls der Zeitgeber nicht bereits läuft. Dann wird das Bit Master auf einen Wert von Null gesetzt (was angibt, dass der gegebene Knoten ein Slave ist), wird das Bit Initialisieren ebenfalls auf einen Wert von Null gesetzt, wird das Bit Vollständige Synchronisation auf einen Wert von Eins eingesetzt, wird die DS-Folgennummer auf die gesetzt, die vom Masterknoten spezifiziert wird, und wird ein Datenbasiszusammenfassungspaket zum Master gesendet, das den Abschnitt der Datenbasiszusammenfassungsinformation für den zur Debatte stehenden Knoten beinhaltet, wie er in Abschnitt 5.7.5 der bestehenden PNNI-Spezifikation dargelegt ist.
  • Fall 2: Empfangender Knoten ist ein Master
  • Dieser Fall deckt die Situation ab, in der die Bits Initialisieren und Master auf einen Wert von Null gesetzt sind, die DS-Folgennummer des Pakets gleich der DS-Folgennummer des zur Debatte stehenden Knotens ist (was ein Rückmeldung angibt) und die Knotenidentifikation des benachbarten Teilnehmers kleiner als die des gegebenen Knotens ist.
  • In diesem Fall ist der zur Debatte stehende Knoten ein Master-Knoten. Bei Erzeugung des Ereignisses 28 Verhandlung (vollständig) erledigt muss der Master-Knoten die folgende Folge von Aktionen durchführen. Zuerst muss der DS-Rxmt-Zeitgeber angehalten werden. Dann müssen die Inhalte des empfangenen Datenzusammenfassungspakets als empfangen bestätigt werden und werden diese Inhalte danach in der Weise verarbeitet, die beim bestehenden PNNI-Protokoll bekannt ist, wie auf den Seiten 94 und 95 in Abschnitt 5.7.6 der PNNI-Spezifikation unter der Überschrift "Austauschzustand" erläutert. Die DS- Folgennummer muss mit einem Wert von Eins inkrementiert werden, das Bit Vollständige Synchronisation wird auf einen Wert von Eins gesetzt und das Bit Initialisieren muss auf einen Wert von Null gesetzt werden. Das Datenbasiszusammenfassungspaket muss zum Slave-Knoten gesendet werden, einschließlich des Abschnittes der Datenbasiszusammenfassungsinformation für den zur Debatte stehenden Knoten, wie in Abschnitt 5.7.5 der bestehenden PNNI-Spezifikation, und der DS-Rxmt-Zeitgeber muss neu gestartet werden. Der Inaktivitätszeitgeber für die Neusynchronisation wird gestartet, falls er nicht bereits läuft.
  • Wenn keiner der Fälle 1 oder 2 oben anwendbar ist, wird das zur Debatte stehende Paket daraufhin überprüft, ob es ein Duplikat ist. Wenn das Paket ein Duplikat ist, wird es ignoriert. Ansonsten, wenn das Paket kein Duplikat ist, dann trat während der Neusynchronisation ein Fehler auf, und der endliche Automat 10 muss danach mit dem Ereignis DS-Fehlanpassung ausgeführt werden.
  • Wenn sich ein Knoten im Zustand 20 Vollständig befindet und bei dem empfangenen Datenbasiszusammenfassungspaket das Bit Vollständige Synchronisation nicht gesetzt ist, dann wird erwartet, dass das zur Debatte stehende Paket ein Duplikat ist. Jedes andere Datenbasiszusammenfassungspaket, bei dem das Bit Vollständige Synchronisation nicht gesetzt ist, erzeugt das Ereignis DS-Fehlanpassung, wodurch bewirkt wird, dass der endliche Automat 10 zum Verhandlungszustand 14 zurückkehrt und die beiden zur Debatte stehenden benachbarten Teilnehmer ihre Datenbasen neu synchronisieren. Gemäß der vorliegenden Erfindung sind die verfolgten Prozeduren, wenn ein Datenbasiszusammenfassungspaket empfangen wird, dessen Bit Vollständige Synchronisation nicht gesetzt ist, die gleichen wie die, denen im bekannten Austauschzustand 16 gefolgt wird, außer dass Pakete, die als das Nächste in der Folge angenommen werden, das Ereignis DS-Fehlanpassung erzeugen müssen und dass ein weiteres Verarbeiten solcher Pakete gestoppt wird. Der Empfang von Paketen mit einem inkonsistenten Master-Bit, oder dessen Bit Initialisieren auf einen Wert von Eins gesetzt ist, müssen ebenfalls das Ereignis DS-Fehlanpassung erzeugen.
  • Wenn der Zustand des Knotens der Zustand 22 Vollständiger Austausch ist, wird ein empfangenes Datenbasiszusammenfassungspaket gemäß der vorliegenden Erfindung verarbeitet, indem die folgenden bedingten Schritte ausgeführt werden. Wenn einer dieser bedingten Schritte als wahr analysiert wurde, braucht keiner der verbleibenden Schritte geprüft oder ausgeführt zu werden.
    • 1) Wenn ein Datenbasiszusammenfassungspaket von dem Knoten, der als Master wirkt, empfangen wird, wird die Verarbeitung des Pakets gestoppt, wenn ermittelt wird, dass das Paket ein Duplikat ist. Die Ermittlung eines Duplikatpakets wurde vorher erörtert.
    • 2) Wenn andererseits der Knoten als Slave wirkt, ist die Reaktion auf den Empfang eines Duplikatpakets, das letzte an den Master gesendete Datenbasiszusammenfassungspaket erneut zu übertragen und dann die Verarbeitung des empfangenen Datenbasiszusammenfassungspakets zu stoppen.
    • 3) Wenn das Pakete in jedem Fall kein Duplikat ist und der Zustand des Master-Bits mit dem Master/Slave-Zustand der Verbindung inkonsistent ist, wird das Ereignis DS-Fehlanpassung erzeugt und die Verarbeitung des Pakets gestoppt.
    • 4) Wenn das Master-Bit konsistent aber das Bit Vollständige Synchronisation nicht gesetzt ist, wird das Ereignis DS-Fehlanpassung erzeugt und die Verarbeitung des Pakets gestoppt.
    • 5) Wenn alle der vorher aufgezählten Bedingungen als falsch analysiert wurden und das Bit Initialisieren gesetzt ist, wird das Ereignis DS-Neusynchronisation-Fehlanpassung erzeugt und die Verarbeitung des Pakets angehalten.
    • 6) Wenn alle der vorher aufgezählten Bedingungen als falsch analysiert wurden und der Knoten ein Master ist, dann wird das Paket akzeptiert und weiter verarbeitet, wenn die DS-Folgennummer des Pakets gleich der DS-Folgennummer für den Knoten ist. Dies gibt an, dass das Paket das nächste in der Folge ist. Die Verarbeitung in diesem Fall wird in der folgenden Weise ausgeführt. Der DS-Rxmt-Zeitgeber wird angehalten. Danach werden die Inhalte des zuletzt empfangenen Datenzusammenfassungspakets als empfangen bestätigt und dann dessen Inhalte in der Weise verarbeitet, die beim bestehenden PNNI-Protokoll bekannt ist, wie auf den Seiten 94 und 95 in Abschnitt 5.7.6 der PNNI-Spezifikation unter der Überschrift "Austausch" erläutert. Die DS-Folgennummer wird dann um einen Wert von Eins inkrementiert. Als nächstes wird, wenn der Knoten bereits seine gesamte Folge von Datenbasiszusammenfassungspaketen gesendet hat und bei dem empfangenen Paket das Bit Mehr auf einen Wert von Null gesetzt ist, das Ereignis 25 (Neu)synchronisation erledigt erzeugt, wenn die PTSE-Anforderungsliste leer ist, und das Ereignis 26 Austausch (vollständig) erledigt erzeugt, wenn die PTSE-Anforderungsliste nicht leer ist. Die Ermittlung, ob ein Knoten seine gesamte Folge von Datenbasiszusammenfassungspaketen gesendet hat, wird vorgenommen, wenn bei dem vom Knoten gesendeten vorhergehenden Datenbasiszusammenfassungspaket das Bit Mehr ebenfalls auf einen Wert von Null gesetzt ist. Wenn die gesamte Folge von Datenbasiszusammenfassungspaketen noch nicht empfangen wurde, wird ein neues Datenbasiszusammenfassungspaket an den Slave gesendet und der DS-Rxmt-Zeitgeber neu gestartet.
    • 7) Wenn alle der vorher aufgezählten Bedingungen als falsch analysiert wurden und der Knoten ein Slave ist, dann wird das Paket akzeptiert und weiter verarbeitet, wenn die DS-Folgennummer des Pakets eins mehr als die DS-Folgennummer des Knotens ist. Dies gibt an, dass das Paket das nächste in der Folge ist. Die Verarbietung des Pakets in dieser Situation ist entsprechend der Zwei-Schritte-Prozedur wie folgt: Als erster Schritt werden dann die Inhalte des Datenzusammenfassungspakets, das als empfangen bestätigt wurde, in der Weise verarbeitet, die beim bestehenden PNNI-Protokoll bekannt ist, wie auf den Seiten 94 und 95 in Abschnitt 5.7.6 der PNNI-Spezifikation unter der Überschrift "Austausch" erläutert. Als zweiter Schritt werden die folgenden Aktionen ausgeführt. Die DS-Folgennummer wird auf die DS-Folgennummer gesetzt, die im empfangenen Paket auftaucht. Dann wird ein Datenbasiszusammenfassungspaket an den Master gesendet. Als nächstes wird dann, wenn bei dem empfangenen Paket das Bit Mehr auf null gesetzt und das gerade übermittelte Datenbasiszusammenfassungspaket leer und somit also sein Bit Mehr auf Null gesetzt ist, das Ereignis 25 (Neu)synchronisation erledigt erzeugt, wenn die PTSE-Anforderungsliste leer ist. Wenn die PTSE-Anforderungsliste nicht leer ist, wird das Ereignis 26 Austausch (vollständig) erledigt ausgeführt.
    • 8) Wenn alle der vorher aufgezählten Bedingungen als falsch analysiert wurden, wird das Ereignis DS-Übereinstimmung erzeugt und die Verarbeitung des Datenbasiszusammenfassungspakets gestoppt.
  • Bezüglich des Zustands 24 Vollständiges Laden hat ein Knoten in diesem Zustand eine gesamte Folge von Datenbasiszusammenfassungspaketen, bei denen das Bit Vollständige Synchronisation gesetzt ist, gesendet und empfangen. Somit sollten die einzigen vom Knoten in diesem Zustand empfangenen Datenbasiszusammenfassungspakete Duplikate sein.
  • Jegliche anderen empfangenen Datenbasiszusammenfassungspakete, die keine Neusynchronisation anfordern, müssen das Ereignis DS-Fehlanpassung erzeugen. Dies bewirkt eine Rückkehr zum Verhandlungszustand 14, und die beiden zur Debatte stehenden benachbarten Teilnehmer werden dann weiter ihre Datenbasen entsprechend der bekannten Prozeduren synchronisieren. Die Prozeduren, denen gefolgt werden soll, wenn ein Datenbasiszusammenfassungspaket im Zustand 24 Vollständiges Laden empfangen wird, sind die gleichen wie die, denen im Zustand 22 Vollständiger Austausch gefolgt wird, außer dass statt dessen Pakete, die als das nächste in der Folge akzeptiert werden, das Ereignis DS-Fehlanpassung erzeugen müssen und eine weitere Verarbeitung solcher Pakete gestoppt wird. Der Empfang von Paketen mit einem inkonsistenten Master-Bit erzeugen ebenfalls das Ereignis DS-Fehlanpassung. Jegliche Pakete mit dem Bit Initialisieen als das einzige inkonsistente Bit erzeugen das Ereignis DS-Neusynchronisation-Fehlanpassung.
  • Wie vorher erwähnt, ist gemäß der vorliegenden Erfindung für das sonst bekannte Datenbasiszusammenfassungspaket des bestehenden PNNI-Protokolls eine zusätzliche Marke definiert. Zum Beispiel kann das Bit Nummer 13 in dem bekannten Markenfeld des Datenbasiszusammenfassungspakets verwendet werden, um diese neue Marke zu definieren, die nützlicherweise Bit Vollständige Synchronisation (SF) genannt werden kann. Dieses Bit wird von jedem der beiden Knoten, die eine Neusynchronisation der Datenbasis ausführen, auf einen Wert von Eins gesetzt, um diesen Austauschvorgang von der Synchronisation zu unterscheiden, wie sie im bestehenden PNNI-Protokoll bekannt ist.
  • Fachleute auf diesem Gebiet werden einsehen, dass in einigen Fällen Netze mit Topologiezustandsroutingprotokollen mit weiteren Protokollen verbunden sein können, die für die Prozeduren der Datenbasissynchronisation erforderlich sind. Zum Beispiel muss in dem speziellen Fall des bestehenden PNNI-Protokolls bei der Anwendung der vorliegenden Erfindung sichergestellt sein, dass das Grußprotokoll nicht wegen der Aktivitätsumschaltung von der aktiven Routingeinheit zur inaktiven Routingeinheit unterbrochen wird. Wenn dies nicht der Fall wäre, würde ein Netzknoten, der mit der ausgefallenen aktiven Routingeinheit verbunden ist, nur wegen der Aktivitätsumschaltung als unerreichbar erklärt. Somit muss im Falle von Netzprotokollen, wie dem PNNI-Protokoll, zur aktiven Routingeinheit gehörige lokale Zustandsinformation der inaktiven Routingeinheit zur Verfügung gestellt werden, so dass jede an einem gemeinsamen Verständnis der lokalen Zustandsinformation während der Wiederherstellung aus einem Ausfall heraus teilhat. Dies kann zum Beispiel durch periodische Übertragung von lokaler Zustandsinformation von der aktiven Routingeinheit zur inaktiven Routingeinheit vor dem zur Debatte stehenden Ausfall erreicht werden.
  • Als nächstes wird die Erfindung unter Bezugnahme auf 4 im Hinblick auf ein einsatzbereites redundantes Netzelement 56 in einem Kommunikationsnetz, wie einem Netz 2 (1) beschrieben, das Netzbereiche 30 und 55 umfasst. Das Netzelement 56 kann auch einen Knoten einer logischen Gruppe implementieren, wie Knoten 36. Das Netzelement 56 umfasst einen Eingangs/Ausgangs-Prot 100, über den Netzverbindungen 76 mittels einer Vermittlugnsstruktur 71 geleitet werden. Netzverbindungen 76a können bei einem Ausfall einer aktiven Routingeinheit 68 von der aktiven Routingeinheit 68 zu einer inaktiven Routingeinheit 70 neu geleitet und umgeleitet werden. Sowohl die aktive Routingeinheit 68 als auch die inaktive Routingeinheit 70 sind mit einem Zugang zu Topologiezustandsinformation versehen, die das Kommunikationsnetz 2 mit den Netzbereichen 30 und 55 betrifft. Zum Beispiel kann die zur Debatte stehende Topologiezustandsinformation für die aktive Routingeinheit 68 und die inaktive Routingeinheit 70 mittels jeweiliger Topologiedatenbasen 74a und 74b zugänglich sein.
  • Gemäß der vorliegenden Erfindung können sowohl die aktive Routingeinheit 68 als auch die inaktive Routingeinheit 70 eines einsatzbereiten redundanten Netzelements, wie Knoten 56, Topologiezustandsinformation mittels periodischer Übermittlungen 69 von Topologiezustandsinformation von der aktiven Routingeinheit 68 zur inaktiven Routingeinheit 70 miteinander teilen, die vor dem Auftreten eines Ausfalls, der die aktive Routingeinheit 68 betrifft, zu vorbestimmten Zeitintervallen stattfinden. Alternativ können solche Übermittlungen in einer ereignisgesteuerten Weise auftreten, wenn von der aktiven Routingeinheit 68 neue Daten empfangen werden. Ebenso kann die inaktive Routingeinheit 70 statt dessen periodisch mit Topologiezustandsinformation aktualisiert werden, die außerhalb des Knotens 56 zugeführt wird, zum Beispiel über Übermittlungen 69a mit externer Quelle. Fachleute auf diesem Gebiet werden einsehen, dass es auch möglich ist, das Verfahren der vorliegenden Erfindung für eine Verwendung mit einem Knoten 56 mit einer inaktiven Routingeinheit 70 anzupassen, die nicht periodisch mit Topologiezustandsinformation aktualisiert wird. Fachleute auf diesem Gebiet werden auch verstehen, dass das Teilen von Topologieinformation zwischen aktiven und inaktiven Routingeinheiten 68, 70 des Netzelements 56 sowie jeder andere Mechanismus zum periodischen Aktualisieren der Topologiezustandsinformation der inaktiven Routingeinheit 70 gemäß bekannter Techniken durchgeführt werden kann.
  • Wie es auf dem Gebiet von Techniken mit einsatzbereiter Redundanz bekannt ist, mag es nicht nur erwünscht sein, die Topologiezustandsinformation der inaktiven Routingeinheit 70 periodisch zu aktualisieren, sondern es kann in gleicher Weise auch lokale Zustandsinformation periodisch zur inaktiven Routingeinheit 70 übertragen werden. Beim PNNI-Protokoll wird beispielsweise solche lokale Zustandsinformation mittels des Grußprotokolls übertragen. Wie vorher erläutert, dient dies dazu zu verhindern, dass Netzknoten einen ausgefallen Knoten nicht als unerreichbar für Routingzwecke erklären, nur wegen der Aktivitätsumschaltung, die die Notwendigkeit für eine Datenbasisneusynchronisation schaffte. Der wiederhergestellte Knoten behält daher seine lokale Zustandsinformation nach der zur Debatte stehenden Aktivitätsumschaltung bei. Eine solche lokale Zustandsinformation würde in einer zu der vorher in Verbindung mit der Topologiezustandsinformation beschriebenen analogen Weise übermittelt.
  • Wenn ein Knoten 56 (und logischer Knoten 36, den er implementiert) vorher synchronisierte Topologiedatenbasen mit seinen benachbarten Teilnehmern aufweist und diese Datenbasen neu synchronisieren möchte, ob zur Wiederherstellung aus einem für die aktive Routingeinheit 68 lokalen Ausfall oder um ein Zurücksetzen davon auszuführen, gestattet die Implementierung der vorliegenden Erfindung, dass der Knoten einen Austauschvorgang für die Topologiedatenbasen mit seinen Nachbarknoten einleitet, der nicht zu einer Beendigung der Bekanntmachung von lokaler Zustandsinformation führt, wenn sie sich auf mit dem Ausfall der aktiven Routingeinheit 68 verbundenen Knoten bezieht und wenn sie sich auf jeden Knoten bezieht, der dem mit dem Ausfall der aktiven Routingeinheit 68 verbundenen Knoten direkt benachbart ist. Solche direkt benachbarten Knoten, wie die Terminologie hier verwendet wird, schließen sowohl physikalische als auch logische Nachbarknoten ein. Zum Beispiel werden bei dem PNNI-Protokoll Verbindungsbekanntmachungen unter den verschiedenen Knoten, die an der Wiederherstellung aus einem Ausfall der aktiven Routingeinheit 68 beteiligt sind, während des Datenbasisaustauschs nicht beendet. Somit entzieht gemäß der vorliegenden Erfindung der mit dem Ausfall der aktiven Routingeinheit 68 verbundene Knoten nicht die Bekanntmachung seiner lokalen Zustandsinformation. Ebenso entziehen gemäß der vorliegenden Erfindung die Nachbarknoten, die dem mit dem Ausfall der aktiven Routingeinheit 68 verbundenen Knoten direkt benachbart sind, desgleichen nicht die Bekanntmachung der jeweiligen lokalen Zustandsinformation, die jeden solchen Nachbarknoten betrifft.
  • Das Verfahren der vorliegenden Erfindung, wie es oben beschrieben ist, kann in jeder, der aktiven Routingeinheit 68 und der inaktiven Routingeinheit 70, durch jeweilige Prozessoren 78a und 78b für die Datenbasissynchronisation implementiert werden, die in Hardware, Software oder einer Kombination davon ausgeführt sein können. Die Prozessoren 78a und 78b für die Synchronisation führen die verschiedenen Prozeduren aus, die vorher im Zusammenhang mit dem Austausch von Topologiezustandsinformation zwischen dem Knoten 56, jedem seiner direkt benachbarten Nachbarn 57, 59, 60 einer niedrigeren Ebene und zwischen dem Knoten 36 und jedem seiner direkt benachbarten Nachbarn 34, 35, 37, 38 einer höheren Ebene beschrieben wurden. Obwohl das oben Beschriebene einen jeweiligen Prozessor 78a oder 78b für die Synchronisation bei jeder, der aktiven Routingeinheit 68 und der inaktiven Routingeinheit 70, bereitstellt, werden Fachleute auf diesem Gebiet einsehen, dass auch ein einziger Prozessor für die Synchronisation von beiden Einrichtungen geteilt werden kann.
  • Somit definiert die vorliegende Erfindung einen Mechanismus für die Datenbasisneusynchronisation zwischen einem Knoten und dazu direkt benachbarten physikalischen oder logischen Nachbarknoten, der bewirkt, dass diese Knoten ihre Bekanntmachungen von lokaler Zustandsinformation während des Synchronisationsvorgangs nicht ändern. Dies sollte sicherstellen, dass die Synchronisation zwischen den zur Debatte stehenden Knoten für alle anderen Knoten im Netz transparent ist, nämlich für solche Knoten, die nicht die direkt benachbarten physikalischen oder logischen Nachbarknoten des ausgefallenen Knotens sind. Die letzteren benachbarten Knoten sind die einzigen Knoten, die aufgefordert werden müssen, sich an der Neusynchronisation zu beteiligen.
  • Gemäß der vorliegenden Erfindung wird daher der Versuch gemacht, einige der Nachteile von bekannten Systemen aus dem Stand der Technik für die Datenbasisneusynchronisation anzugehen, wie sie während einer Wiederherstellung mit einsatzbereiter Redundanz auftreten kann. In Fällen, in denen der ausgefallene Knoten eine aktive Routingeinheit ist, die ausgezeichnete Verantwortlichkeiten besitzt, ist der Ausfall der aktiven Routingeinheit nicht so störend für das Routingsystem oder das Netz im Allgemeinen in dem Sinne, dass keine der ausgezeichneten Verantwortlichkeiten der Routingeinheit während der Wiederherstellung aufgegeben werden muss. Folglich muss kein anderer Knoten die ausgezeichneten Verantwortlichkeiten des ausgefallenen Knotens übernehmen. Zum Beispiel würde der designierte Sicherungsrouter des OSPF-Protokolls nicht der designierte Router werden und es würde kein neuer Teilnehmergruppenführer auf irgendeiner Ebene der Netzhierarchie unter dem PNNI-Protokoll als Ersatz für eine ausgefallene ausgezeichnete Netzkomponente gewählt werden.
  • Da eine Fehlererfassung und eine Wiederherstellung nach einem Fehler bei der vorliegenden Erfindung innerhalb des ausgefallenen Knotens und nur bezüglich physikalischer oder logischer direkt infizierter Knoten oder Einrichtungen auftritt, wird erwartet, dass der Wiederherstellungsvorgang gemäß der vorliegenden Erfindung weniger zeitaufwendig als der von Techniken für eine Wiederherstellung einsatzbereiter Redundanz aus dem Strand der Technik ist. Ebenso nimmt unter der Voraussetzung, dass erwartet wird, dass es keine Beteiligung von anderen Netzeinrichtungen als den oben beschriebenen gibt, die der ausgefallenen Netzeinheit benachbart sind, ein weniger umfassender Abschnitt der Netztopologie an der Wiederherstellung teil, als es bei Techniken oder Einrichtungen aus dem Stand der Technik der Fall wäre. Dieser erwartete Vorteil in zeitlichem und topologischem Ausmaß der Wiederherstellung ist anwendbar, ob der ausgefallene Knoten normalerweise ausgezeichnete Verwantwortlichkeiten ausführt oder nicht. Schließlich wird erwartet, dass die Anforderungen an Netzbandbreite und Verarbeitung im Zusammenhang mit dem Wiederherstellungsvorgang der vorliegenden Erfindung gegenüber bekannten Techniken der Wiederherstellung aus Fehlern dadurch verringert ist, dass nur jene Knoten, die der ausgefallenen Komponente direkt benachbart sind, an der Wiederherstellung beteiligt sind.
  • Obwohl die vorliegende Erfindung unter Bezugnahme auf eine Implementierung beschrieben wurde, die an das bestehende PNNI-Protokoll angepasst ist, werden Fachleute auf dem Gebiet der Kommunikationsnetze einsehen, dass die Erfindung auf andere Topologiezustandsprotokollen angewendet oder angepasst werden kann. Ebenso können, während ein Prozessor für die Synchronisation zum Ausführen des Verfahrens der vorliegenden Erfindung eingesetzt werden kann, die verschiedenen Schritte des Verfahrens als Ganzes oder teilweise von einer oder mehreren zu einem Netzelement gehörigen anderen Einrichtungen oder Software ausgeführt werden kann oder von bestehenden Einrichtungen oder Software ausgeführt werden kann, die damit verbunden ist und die für eine Verwendung mit dieser Erfindung modifiziert oder anderweitig angepasst sein kann. Obwohl die vorliegende Erfindung im Kontext der Wiederherstellung einer einsatzbereiten Redundanz beschrieben wurde, kann die Erfindung ferner in anderen Situationen der Wiederherstellung aus Ausfällen oder immer dann eingesetzt werden, wenn es für einen Knoten wünschenswert sein kann, seine Topologiedatenbasis neu zu synchronisieren, wenn er einmal vorher eine Datenbasissynchronisation ausgeführt hat.

Claims (41)

  1. Verfahren zur Wiederherstellung aus einer Störung, die eine aktive Routingeinheit (68) in einem Kommunikationsnetz (2) betrifft, wobei die aktive Routingeinheit zu einem Netzknoten (36) des Kommunikationsnetzes gehört, wobei das Kommunikationsnetz ein Routingprotokoll zur intermittierenden Bekanntmachung von Information über den lokalen Zustand über das ganze Netz umfasst, und der Knoten ferner eine inaktive Routingeinheit (70) umfasst, zu der bei Störung Netzverbindungen des Netzknotens von der aktiven Routingeinheit weg umgeleitet werden können, wobei bei Störung eine Aktivitätsumschaltung (71) zwischen der aktiven Routingeinheit und der inaktiven Routingeinheit ausgeführt wird und Netzverbindungen (76) des Netzknotens von der aktiven Routingeinheit weg zur inaktiven Routingeinheit umgeleitet werden, um dadurch die inaktive Routingeinheit zu einer neu-aktiven Routingeinheit umzuwandeln; und nach der Aktivitätsumschaltung umfasst es die Schritte des Austauschens von Information über den Topologiezustand ausschließlich zwischen der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten (34, 35, 37, 38) des mit der Störung verbundenen Netzknotens, so dass die neu-aktive Routingeinheit und jeder direkt benachbarte Nachbarknoten jeweils synchronisierte Information über den Topologiezustand besitzen; und wobei der Austausch von Information über den Topologiezustand zwischen der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten von dem mit der Störung verbundenen Netzknoten und von jedem direkt benachbarten Nachbarknoten ohne Entzug der intermittierenden Bekanntmachung von Information über den lokalen Zustand ausgeführt wird, wenn sie sich jeweils auf den mit der Störung verbundenen Netzknoten und auf jeden direkt benachbarten Nachbarknoten bezieht, dadurch gekennzeichnet, dass die neu-aktive Routingeinheit (68) vor dem Austausch von Information über den Topologiezustand mit jedem direkt benachbarten Nachbarknoten jedem direkt benachbarten Nachbarknoten meldet, dass der Austausch ohne Entzug der intermittierenden Bekanntmachung von Information über den lokalen Zustand stattfinden soll.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass es ferner den Schritt des Übertragens von Information über den Topologiezustand zur inaktiven Routingeinheit (70) vor der Störung umfasst, wobei die den Topologiezustand des gesamten Netzes betreffende Information der Übertragung von Information über den Topologiezustand direkt folgt.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Übertragung von Information über den Topologiezustand periodisch ist.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die periodische Übertragung von Information über den Topologiezustand zur inaktiven Routingeinheit von der aktiven Routingeinheit (68) kommt.
  5. Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass es ferner den Schritt des Übertragens von Information über den lokalen Zustand zur inaktiven Routingeinheit (70) vor der Störung umfasst, wobei die den lokalen Zustand betreffende Information über den lokalen Zustand der Übertragung von Information über den lokalen Zustand direkt folgt.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Übertragung von Information über den lokalen Zustand periodisch ist.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die periodische Übertragung von Information über den lokalen Zustand zur inaktiven Routingeinheit (70) von der aktiven Routingeinheit (68) kommt.
  8. Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass die Information über den lokalen Zustand Information über den lokalen Verbindungszustand und Information über den lokalen Knotenzustand umfasst.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Information über den lokalen Verbindungszustand aus der Gruppe ausgewählt ist, die Verbindungseigenschaften, Betriebszustand der Verbindung und Portidentifikatoren umfasst.
  10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass die Information über den lokalen Knotenzustand aus der Gruppe ausgewählt ist, die Knotenidentifikatoren, Teilnehmergruppenidentifikatoren, Wahlzustand ausgezeichneter Knoten, Führungszustand ausgezeichneter Knoten und lokal erreichbare Adressen umfasst.
  11. Verfahren nach einem der Ansprüche 7 bis 10, dadurch gekennzeichnet, dass die aktive Routingeinheit (68) und die inaktive Routingeinheit (70) jeweils einen Teil des mit der Störung verbundenen Knotens bilden.
  12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die aktive Routingeinheit (68) und die inaktive Routingeinheit (70) jeweils mittels getrennter physikalischer Komponenten implementiert sind.
  13. Verfahren nach einem der Ansprüche 5 bis 12, dadurch gekennzeichnet, dass das Kommunikationsnetz (2) ein Netz mit asynchronem Übertragungsmodus ist und das Routingprotokoll für die intermittierende Bekanntmachung von Information über den lokalen Zustand über das gesamte Kommunikationsnetz das Protokoll für private Netzknotenschnittstellen oder für private Schnittstellen von Netz zu Netz ist.
  14. Verfahren nach einem der Ansprüche 5 bis 12, dadurch gekennzeichnet, dass das Kommunikationsnetz (2) ein Netz mit Internetprotokoll ist und das Routingprotokoll für die intermittierende Bekanntmachung von Information über den lokalen Zustand über das gesamte Kommunikationsnetz das Open-Shortest-Path-First-Protokoll ist.
  15. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Information über den Topologiezustand, die von der aktiven Routingeinheit vor der Störung übertragen wird, aus einer zur aktiven Routingeinheit gehörigen Topologiedatenbasis extrahiert wird, und wobei die Information über den Topologiezustand, die nach der Aktivitätsumschaltung zwischen der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten ausgetauscht wird, aus einer Topologiedatenbasis extrahiert wird, die jeweils zu der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten gehört.
  16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass Information über den Topologiezustand von der aktiven Routingeinheit zur inaktiven Routingeinheit vor der Störung übertragen wird, indem die Information über den Topologiezustand zu Topologiezustandselementen für private Netzknotenschnittstellen oder für private Schnittstellen von Netz zu Netz gebündelt wird.
  17. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass Information über den Topologiezustand nach der Aktivitätsumschaltung zwischen der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten übertragen wird, indem die Information über den Topologiezustand zu Topologiezustandselementen für private Netzknotenschnittstellen oder für private Schnittstellen von Netz zu Netz gebündelt wird.
  18. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass jedes Topologiezustandselement für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz für die Übertragung in Topologiezustandspaketen für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz eingekapselt ist.
  19. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass jedes Topologiezustandselement für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz für Austausch in Topologiezustandspaketen für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz eingekapselt ist.
  20. Verfahren nach einem der Ansprüche 1 bis 19, dadurch gekennzeichnet, dass das Melden des Austauschs von Information über den Topologiezustand ohne Entzug der intermittierenden Bekanntmachung von Information über den lokalen Zustand mittels einer Marke in einer jedem direkt benachbarten Nachbarknoten des mit der Störung verbundenen Netzknotens gesendeten Meldenachricht stattfindet.
  21. Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass die Meldenachricht ein Datenbasiszusammenfassungspaket für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz ist, in dem die Marke bereitgestellt ist.
  22. Netzelement zur Wiederherstellung nach einer Störung in einem Kommunikationsnetz (2), das ein Routingprotokoll für eine intermittierende Bekanntmachung von Information über den lokalen Zustand über das gesamte Netz umfasst, wobei das Netzelement umfasst: eine aktive Routingeinheit (68), wobei die aktive Routingeinheit mit Information über den Topologiezustand verbunden ist, die das Kommunikationsnetz betrifft; eine inaktive Routingeinheit (70), wobei eine Aktivitätsumschaltung zwischen der aktiven Routingeinheit und der inaktiven Routingeinheit bei Störung der aktiven Routingeinheit ausgeführt wird, um dadurch Netzverbindungen von der aktiven Routingeinheit zur inaktiven Routingeinheit umzuleiten und die inaktive Routingeinheit zu einer neu-aktiven Routingeinheit umzuwandeln; einen Synchronisationsprozessor für die Datenbasis, der dafür ausgelegt ist, einen Austausch von Information über den Topologiezustand ausschließlich zwischen der neu-aktiven Routingeinheit (68) und jedem direkt benachbarten Nachbarknoten (34, 35, 37, 38) des Netzelements nach der Aktivitätsumschaltung zu bewirken, so dass die neu-aktive Routingeinheit und jeder direkt benachbarte Nachbarknoten jeweils synchronisierte Information über den Topologiezustand besitzen, und wobei der Austausch von Information über den Topologiezustand zwischen der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten von dem mit der Störung verbundenen Netzknoten und von jedem direkt benachbarten Nachbarknoten ohne Entzug der intermittierenden Bekanntmachung von Information über den lokalen Zustand ausgeführt wird, wenn sie sich jeweils auf das Netzelement und auf jeden direkt benachbarten Nachbarknoten bezieht, dadurch gekennzeichnet, dass die neu-aktive Routingeinheit vor dem Austausch von Information über den Topologiezustand mit jedem direkt benachbarten Nachbarknoten jedem direkt benachbarten Nachbarknoten meldet, dass der Austausch ohne Entzug der intermittierenden Bekanntmachung von Information über den lokalen Zustand stattfinden soll.
  23. Netzelement nach Anspruch 22, dadurch gekennzeichnet, dass die Information über den Topologiezustand zur inaktiven Routingeinheit (70) vor der Störung der aktiven Routingeinheit (68) übertragen wird, wobei die den Topologiezustand des gesamten Netzes betreffende Information der Übertragung von Information über den Topologiezustand folgt.
  24. Netzelement nach Anspruch 23, dadurch gekennzeichnet, dass die Übertragung von Information über den Topologiezustand periodisch ist.
  25. Netzelement nach Anspruch 24, dadurch gekennzeichnet, dass die periodische Übertragung von Information über den Topologiezustand zur inaktiven Routingeinheit von der aktiven Routingeinheit kommt.
  26. Netzelement nach einem der Ansprüche 23 bis 25, dadurch gekennzeichnet, dass die Information über den lokalen Zustand zur inaktiven Routingeinheit (70) vor der Störung der aktiven Routingeinheit (68) übertragen wird, wobei die den lokalen Zustand betreffende Information der Übertragung von Information über den lokalen Zustand direkt folgt.
  27. Netzelement nach Anspruch 26, dadurch gekennzeichnet, dass die Übertragung von Information über den lokalen Zustand periodisch ist.
  28. Netzelement nach Anspruch 27, dadurch gekennzeichnet, dass die periodische Übertragung von Information über den lokalen Zustand zur inaktiven Routingeinheit (70) von der aktiven Routingeinheit (68) kommt.
  29. Netzelement nach einem der Ansprüche 23 bis 28, dadurch gekennzeichnet, dass die Information über den lokalen Zustand Information über den Verbindungszustand und Information über den lokalen Knotenzustand umfasst.
  30. Netzelement nach Anspruch 29, dadurch gekennzeichnet, dass die Information über den lokalen Verbindungszustand aus der Gruppe ausgewählt ist, die Verbindungseigenschaften, Betriebszustand der Verbindung und Portidentifikatoren umfasst.
  31. Netzelement nach Anspruch 30, dadurch gekennzeichnet, dass die Information über den lokalen Knotenzustand aus der Gruppe ausgewählt ist, die Knotenidentifikatoren, Teilnehmergruppenidentifikatoren, Wahlzustand ausgezeichneter Knoten, Führungszustand ausgezeichneter Knoten und lokal erreichbare Adressen umfasst.
  32. Netzelement nach Anspruch 31, dadurch gekennzeichnet, dass die aktive Routingeinheit (68) und die inaktive Routingeinheit (70) jeweils mittels getrennter physikalischer Komponenten implementiert sind.
  33. Netzelement nach einem der Ansprüche 25 bis 32, dadurch gekennzeichnet, dass das Kommunikationsnetz ein Netz mit asynchronem Übertragungsmodus ist und das Routingprotokoll für die intermittierende Bekanntmachung von Information über den lokalen Zustand über das gesamte Kommunikationsnetz das Protokoll für private Netzknotenschnittstellen oder für private Schnittstellen von Netzwerk zu Netzwerk ist.
  34. Netzelement nach einem der Ansprüche 25 bis 32, dadurch gekennzeichnet, dass das Kommunikationsnetz ein Netz mit Internetprotokoll ist und das Routingprotokoll für die intermittierende Bekanntmachung von Information über den Verbindungsustand über das gesamte Kommunikationsnetz das Open-Shortest-Path-First-Protokoll ist.
  35. Netzelement nach Anspruch 33, dadurch gekennzeichnet, dass die Information über den Topologiezustand, die von der aktiven Routingeinheit vor der Störung der aktiven Routingeinheit übertragen wird, aus einer zur aktiven Routingeinheit gehörigen Topologiedatenbasis extrahiert wird, und wobei die Information über den Topologiezustand, die nach der Aktivitätsumschaltung zwischen der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten ausgetauscht wird, aus einer Topologiedatenbasis extrahiert wird, die jeweils zu der neu-aktiven Routingeinheit und jedem direkt benachbarten Nachbarknoten gehört.
  36. Netzelement nach einem der Ansprüche 22 bis 35, dadurch gekennzeichnet, dass Information über den Topologiezustand von der aktiven Routingeinheit zur inaktiven Routingeinheit vor der Störung übertragen wird, indem die Information über den Topologiezustand zu Topologiezustandselementen für private Netzknotenschnittstellen oder für private Schnittstellen von Netz zu Netz gebündelt wird.
  37. Netzelement nach einem der Ansprüche 22 bis 36, dadurch gekennzeichnet, dass Information über den Topologiezustand nach der Aktivitätsumschaltung zwischen der neu-aktiven Routingeinheit (68) und jedem direkt benachbarten Nachbarknoten übertragen wird, indem die Information über den Topologiezustand zu Topologiezustandselementen für private Netzknotenschnittstellen oder für private Schnittstellen von Netz zu Netz gebündelt wird.
  38. Netzelement nach Anspruch 36, dadurch gekennzeichnet, dass jedes Topologiezustandselement für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz für die Übertragung in Topologiezustandspaketen für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz eingekapselt ist.
  39. Netzelement nach Anspruch 37, dadurch gekennzeichnet, dass jedes Topologiezustandselement für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz für den Austausch in Topologiezustandspaketen für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz eingekapselt ist.
  40. Netzelement nach einem der Ansprüche 22 bis 39, dadurch gekennzeichnet, dass das Melden des Austauschs von Information über den Topologiezustand ohne Entzug der intermittierenden Bekanntmachung von Information über den lokalen Zustand mittels einer Marke in einer jedem direkt benachbarten Nachbarknoten des Netzelements gesendeten Meldenachricht stattfindet.
  41. Netzelement nach Anspruch 40, dadurch gekennzeichnet, dass die Meldenachricht ein Datenbasiszusammenfassungspaket für private Netzknotenschnittstellen oder private Schnittstellen von Netz zu Netz ist, in dem die Marke bereitgestellt ist.
DE60118143T 2000-09-18 2001-09-17 Verfahren und Vorrichtung zur Re-Synchronisierung einer Netzwerkstruktur-Datenbank in einem Kommunikationsnetz mit Topologie-Zustand Leitweglenkung-Protokollen Expired - Lifetime DE60118143T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/663,793 US6876625B1 (en) 2000-09-18 2000-09-18 Method and apparatus for topology database re-synchronization in communications networks having topology state routing protocols
US663793 2000-09-18

Publications (2)

Publication Number Publication Date
DE60118143D1 DE60118143D1 (de) 2006-05-11
DE60118143T2 true DE60118143T2 (de) 2007-01-25

Family

ID=24663283

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60118143T Expired - Lifetime DE60118143T2 (de) 2000-09-18 2001-09-17 Verfahren und Vorrichtung zur Re-Synchronisierung einer Netzwerkstruktur-Datenbank in einem Kommunikationsnetz mit Topologie-Zustand Leitweglenkung-Protokollen

Country Status (5)

Country Link
US (1) US6876625B1 (de)
EP (2) EP1189384B1 (de)
JP (2) JP4755786B2 (de)
CN (1) CN100391193C (de)
DE (1) DE60118143T2 (de)

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002064509A (ja) * 2000-08-18 2002-02-28 Nec Corp 装置内経路監視制御方式、装置内経路監視制御方法及び記録媒体
US20020176355A1 (en) * 2001-05-22 2002-11-28 Alan Mimms Snooping standby router
US8423674B2 (en) * 2001-06-02 2013-04-16 Ericsson Ab Method and apparatus for process sync restart
US7003582B2 (en) * 2001-06-20 2006-02-21 International Business Machines Corporation Robust NP-based data forwarding techniques that tolerate failure of control-based applications
US7458017B2 (en) * 2001-06-26 2008-11-25 Microsoft Corporation Function-based object model for use in website adaptation
US7110355B1 (en) * 2001-08-14 2006-09-19 Cisco Technology, Inc. Automatic side selection in double-ring topologies
CA2357444A1 (en) * 2001-09-13 2003-03-13 Armadillo Networks Inc. System and methods for automatic negotiation in distributed computing
US7499986B2 (en) * 2001-10-04 2009-03-03 International Business Machines Corporation Storage area network methods with event notification conflict resolution
US7639680B1 (en) * 2001-10-04 2009-12-29 Cisco Technology, Inc. Out of band data base synchronization for OSPF
US7254111B2 (en) * 2001-10-05 2007-08-07 Samsung Electronics Co., Ltd. Routing coordination protocol for a massively parallel router architecture
US7277383B2 (en) * 2001-10-05 2007-10-02 Samsung Electronics Co., Ltd. Redundancy mechanization protocol for a massively parallel router
US7042850B2 (en) * 2001-11-09 2006-05-09 Fujitsu Limited Focused link state advertisements
US7093001B2 (en) * 2001-11-26 2006-08-15 Microsoft Corporation Methods and systems for adaptive delivery of multimedia contents
US7028224B2 (en) * 2002-01-09 2006-04-11 International Business Machines Corporation Network router having an internal automated backup
US8769154B2 (en) 2002-01-24 2014-07-01 Alcatel Lucent Method and apparatus for facilitating routing protocol redundancy in a network element
US8005980B2 (en) 2002-01-24 2011-08-23 Alcatel Lucent Method and apparatus for synchronizing redundant communication tasks
DE60304307T2 (de) * 2002-01-24 2006-12-07 Alcatel Canada Inc., Kanata Methode und Apparat zur Bereitstellung von Routing Protokoll Redundanz in einem Netzelement
US7406035B2 (en) 2002-01-24 2008-07-29 Alcatel-Lucent Canada Inc. Method and apparatus for providing redundant protocol processes in a network element
US7301894B1 (en) * 2002-03-25 2007-11-27 Westell Technologies, Inc. Method for providing fault tolerance in an XDSL system
US7065707B2 (en) * 2002-06-24 2006-06-20 Microsoft Corporation Segmenting and indexing web pages using function-based object models
US20040073659A1 (en) * 2002-10-15 2004-04-15 Carl Rajsic Method and apparatus for managing nodes in a network
US7286468B2 (en) 2002-11-12 2007-10-23 Cisco Technology, Inc. Routing system and method for synchronizing a routing system with peers after failover
US7203901B2 (en) * 2002-11-27 2007-04-10 Microsoft Corporation Small form factor web browsing
CN100344105C (zh) * 2003-09-16 2007-10-17 华为技术有限公司 承载控制层的平滑重启方法
US8527457B2 (en) * 2003-10-07 2013-09-03 Cisco Technology, Inc. Arrangement for autonomous mobile network nodes to organize a wireless mobile network based on detected physical and logical changes
US8009556B2 (en) * 2003-10-17 2011-08-30 Ip Infusion, Inc. System and method for providing redundant routing capabilities for a network node
US7580418B2 (en) * 2003-12-17 2009-08-25 Nec Corporation Network, router device, route updating suppression method used for the same, and program thereof
EP1700433A1 (de) * 2003-12-22 2006-09-13 Koninklijke Philips Electronics N.V. Verfahren zum automatischen transferieren von router-funktionalität
US8213439B2 (en) * 2004-01-30 2012-07-03 Hewlett-Packard Development Company, L.P. Method and system for managing a network having an HSRP group
JP4408756B2 (ja) * 2004-06-30 2010-02-03 富士通株式会社 経路計算システム
CN100370748C (zh) * 2005-01-19 2008-02-20 华为技术有限公司 承载网间拓扑资源信息同步的实现方法
US8213340B1 (en) * 2005-08-15 2012-07-03 Tellabs Operations, Inc. System and method for managing a node split across multiple network elements
US7542432B2 (en) * 2005-10-27 2009-06-02 Alcatel Lucent Resource matched topology database synchronization in communications networks having topology state routing protocols
US7953096B2 (en) * 2005-11-23 2011-05-31 Ericsson Ab Method and system for communication using a partial designated transit list
US7664789B2 (en) * 2005-12-02 2010-02-16 Cisco Technology, Inc. Method and apparatus to minimize database exchange in OSPF by using a SHA-1 digest value
EP1816804B1 (de) * 2005-12-05 2012-12-19 Nippon Telegraph And Telephone Corporation Ausfallwiederherstellungsverfahren und paketkommunikationsgerät
US8015235B1 (en) * 2006-01-03 2011-09-06 Emc Corporation Group services
CN101022451B (zh) * 2006-02-14 2014-07-23 杭州华三通信技术有限公司 数据通信中连接状态的同步方法及其应用的通信节点
US8209405B1 (en) 2006-06-12 2012-06-26 Juniper Networks, Inc. Failover scheme with service-based segregation
US7768995B2 (en) * 2006-08-01 2010-08-03 Cisco Technology, Inc. Techniques for one-way synchronization of routing information among intermediate nodes
US8437280B2 (en) * 2007-03-22 2013-05-07 Tr Technologies Inc. Distributed synchronous batch reconfiguration of a network
WO2009002147A1 (en) * 2007-06-27 2008-12-31 Telefonaktiebolaget Lm Ericsson (Publ) Method for expression evaluation and network node implementing such a method
JP2009147735A (ja) * 2007-12-14 2009-07-02 Nec Corp ネットワーク、ノード装置、ネットワーク冗長化方法及びネットワーク冗長化プログラム
CN101651510B (zh) * 2008-08-14 2013-01-16 中兴通讯股份有限公司 业务数据同步发送的恢复处理方法和装置
CN101729408B (zh) * 2009-11-23 2012-05-30 福建星网锐捷网络有限公司 一种判定接口网络类型的方法及路由设备
FR2954644A1 (fr) * 2009-12-21 2011-06-24 Thales Sa Protocole de routage fiabilise
CN102273133B (zh) * 2011-04-29 2013-04-17 华为技术有限公司 网络故障诊断方法及装置和系统
US9477739B2 (en) * 2011-09-23 2016-10-25 Hybrid Logic Ltd System for live-migration and automated recovery of applications in a distributed system
GB2495079A (en) 2011-09-23 2013-04-03 Hybrid Logic Ltd Live migration of applications and file systems in a distributed system
US9483542B2 (en) 2011-09-23 2016-11-01 Hybrid Logic Ltd System for live-migration and automated recovery of applications in a distributed system
US10331801B2 (en) 2011-09-23 2019-06-25 Open Invention Network, Llc System for live-migration and automated recovery of applications in a distributed system
US9501543B2 (en) 2011-09-23 2016-11-22 Hybrid Logic Ltd System for live-migration and automated recovery of applications in a distributed system
US10311027B2 (en) 2011-09-23 2019-06-04 Open Invention Network, Llc System for live-migration and automated recovery of applications in a distributed system
US9547705B2 (en) 2011-09-23 2017-01-17 Hybrid Logic Ltd System for live-migration and automated recovery of applications in a distributed system
GB2505230B (en) * 2012-08-23 2019-10-16 Metaswitch Networks Ltd Leader node appointment
GB2513188B (en) 2013-04-19 2015-11-25 Entuity Ltd Identification of the paths taken through a network of interconnected devices
JP6193473B2 (ja) 2013-04-19 2017-09-06 エンチュイティ リミテッドEntuity Limited コンピュータ実施方法、コンピュータプログラム製品及びコンピュータ
ES2617196T3 (es) 2013-04-19 2017-06-15 Entuity Limited Identificación de rutas en una red de dispositivos de enrutamiento/conmutación mezclados
US9219562B2 (en) * 2014-05-08 2015-12-22 Nokia Solutions And Networks Oy System and method to dynamically redistribute timing and synchronization in a packet switched network
US9893948B2 (en) 2015-03-26 2018-02-13 Utopus Insights, Inc. Network management using hierarchical and multi-scenario graphs
CN105072043B (zh) * 2015-08-10 2018-07-06 尚一民 Mesh网络路由协议中的客户端声明过程优化方法
US11075806B1 (en) 2016-06-30 2021-07-27 Juniper Networks, Inc. Hierarchical naming scheme for state propagation within network devices
US10887173B2 (en) 2016-12-21 2021-01-05 Juniper Networks, Inc. Communicating state information in distributed operating systems
US11316744B2 (en) 2016-12-21 2022-04-26 Juniper Networks, Inc. Organizing execution of distributed operating systems for network devices
US11316775B2 (en) * 2016-12-21 2022-04-26 Juniper Networks, Inc. Maintaining coherency in distributed operating systems for network devices
US10560326B2 (en) * 2017-09-22 2020-02-11 Webroot Inc. State-based entity behavior analysis
EP3587194B1 (de) * 2018-06-29 2022-08-03 Aptiv Technologies Limited Leistungs- und datenzentrum (pdc) für automobilanwendungen
WO2020125978A1 (en) * 2018-12-19 2020-06-25 Rohde & Schwarz Gmbh & Co.Kg System and method for monitoring a secure communication
US11095742B2 (en) * 2019-03-27 2021-08-17 Juniper Networks, Inc. Query proxy for delivery of dynamic system state
CN112202679B (zh) * 2020-11-17 2022-05-10 中国人民解放军战略支援部队信息工程大学 用于分层网络拓扑自动路由分发的硬件设备量化方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5473599A (en) 1994-04-22 1995-12-05 Cisco Systems, Incorporated Standby router protocol
JP2723084B2 (ja) * 1995-07-19 1998-03-09 日本電気株式会社 リンクステートルーティング装置
US5970502A (en) * 1996-04-23 1999-10-19 Nortel Networks Corporation Method and apparatus for synchronizing multiple copies of a database
WO1998051096A1 (en) * 1997-05-09 1998-11-12 Dsc Telecom L.P. Communication system with rapid database synchronization
US5974114A (en) * 1997-09-25 1999-10-26 At&T Corp Method and apparatus for fault tolerant call processing
US6473408B1 (en) * 1999-05-19 2002-10-29 3Com Corporation Building a hierarchy in an asynchronous transfer mode PNNI network utilizing proxy SVCC-based RCC entities
US6717939B1 (en) * 1999-07-12 2004-04-06 Lucent Technologies Inc. Virtual transport server in a telecommunication network

Also Published As

Publication number Publication date
EP1598995A2 (de) 2005-11-23
US6876625B1 (en) 2005-04-05
JP4755786B2 (ja) 2011-08-24
JP5200138B2 (ja) 2013-05-15
EP1598995A3 (de) 2006-04-19
EP1189384A2 (de) 2002-03-20
CN1345148A (zh) 2002-04-17
EP1189384B1 (de) 2006-03-22
JP2002135328A (ja) 2002-05-10
EP1189384A3 (de) 2002-12-18
DE60118143D1 (de) 2006-05-11
CN100391193C (zh) 2008-05-28
JP2011151864A (ja) 2011-08-04

Similar Documents

Publication Publication Date Title
DE60118143T2 (de) Verfahren und Vorrichtung zur Re-Synchronisierung einer Netzwerkstruktur-Datenbank in einem Kommunikationsnetz mit Topologie-Zustand Leitweglenkung-Protokollen
DE60213192T2 (de) Resynchronisation von Kontrollpfad- und Datenpfadzuständen für Netzwerke
DE60201706T2 (de) Verfahren und Vorrichtung zur Ersatzschaltung von Router Verbindungen
DE69922690T2 (de) Fehlertolerante netze
DE69738175T2 (de) Verbindungsübertragungsnetzwerk
DE69735740T2 (de) Asynchrone paketvermittlung
US5805578A (en) Automatic reconfiguration of multipoint communication channels
DE69637290T2 (de) Verbindungsreservation in Kommunikationsnetzwerken
DE60111551T2 (de) Mechanismus zur vervollständigung von nachrichten im speicher
DE60214234T2 (de) Verfahren und apparate zum implementieren einer glasfaservermittlungseinheit mit hoher verfügbarkeit
DE69735084T2 (de) Leitwegumlenkungsverfahren in hierarchischen strukturierten Netzwerken
DE19532422C1 (de) Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk mit wenigstens zwei Ringsystemen
DE19900065B4 (de) Netzwerküberwachungsgerät
DE69532262T2 (de) Verfahren zum Mehrfachsenden
DE60121798T2 (de) Router und leitweglenkungsprotokoll redundanz
DE19950822B4 (de) Verfahren und Vorrichtung für das Verteilen von Paketen über parallele Kommunikationsverbindungen
DE60318878T2 (de) Verfahren und systeme zum austausch von erreichbarkeitsinformationen und zum umschalten zwischen redundanten schnittstellen in einem netzwerkcluster
DE60022602T2 (de) Verfahren, Vorrichtung und Computerprogramm um Topologiedaten eines Link State Routing Netzwerkes aktuell zu halten
DE60207967T2 (de) System und Verfahren zur Bereitstellung von Daten der Dienstsverfügbarkeit eines Kommunikationsnetzes
DE10360190A1 (de) Vorrichtung für die Erfassung von Verbindungsfehlern auf der Backplane des hochverfügbaren Ethernet
DE69936817T2 (de) Automatischer Sicherheitsumschaltungsmechanismus auf der asynchronen Übertragungsmodusebene für ATM permanente virtuelle Verbindungen
DE69922200T2 (de) Verfahren und vorrichtung zur störungsfreien hinzufügung von einem neuen knoten zu einem knotennetzwerk
DE60133685T2 (de) Kommunikationszwischenstelle zwischen Uhrtaktbereichen mit minimaler Latenz
DE60130844T2 (de) Autonomes OSPF-System mit einem in zwei Teilbereiche getrennten Hauptnetz
EP2127329B1 (de) Filterung von redundanten frames in einem netzwerkknoten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition