DE69635648T2

DE69635648T2 - System und Verfahren zur Filterung eines Hochleistungsnetzwerk-Verwaltungsplans

Info

Publication number: DE69635648T2
Application number: DE69635648T
Authority: DE
Inventors: Robert Dwight Schettler; Eric A. Pulsipher; Brian J. Atkins
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1995-11-01
Filing date: 1996-10-10
Publication date: 2006-08-24
Anticipated expiration: 2016-10-11
Also published as: EP0772318A2; DE69635648D1; EP0772318B1; EP0772318A3; JPH09204384A; US5787252A

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf Datenkommunikationsnetze und insbesondere auf ein Filtersystem und -Verfahren zum Ermöglichen einer Hochleistungserzeugung einer Netzverwaltungsabbildung eines Datenkommunikationsnetzes in einer Verwaltungsstation.
Hintergrund der Erfindung
Ein Datenkommunikationsnetz umfasst allgemein eine Gruppe von Vorrichtungen, wie z. B. Computern, Repeatern, Brücken, Routern, usw., die sich an Netzknoten befinden, sowie eine Sammlung von Kommunikationskanälen zum Verbinden der verschiedenen Knoten untereinander. Hardware und Software, die dem Netz und insbesondere den Vorrichtungen zugeordnet ist, erlaubt ein elektronisches Austauschen von Daten über die Kommunikationskanäle durch die Vorrichtungen.
Die Größe von Netzen variiert. Ein lokales Netz (LAN) ist ein Netz von Vorrichtungen in nächster Nähe, üblicherweise weniger als einer Meile, die üblicherweise durch ein einzelnes Kabel, wie z. B. ein Koaxialkabel, verbunden sind. Ein weites Netz (WAN) ist ein Netz von Vorrichtungen, die durch größere Entfernungen getrennt sind, die oft z. B. durch Telefonleitungen oder Satellitenverbindungen verbunden sind. Tatsächlich überspannen einige WANs die Vereinigten Staaten sowie die Erde. Ferner sind viele dieser Netze zur Verwendung durch die Öffentlichkeit gut verfügbar, einschließlich üblicherweise Universitäten und kommerzieller Industrien.
Ein sehr beliebtes Industriestandard-Protokoll für eine Datenkommunikation entlang der Netze ist das Internetproto koll (IP; IP = Internet Protocol). Dieses Protokoll wurde ursprünglich durch das Verteidigungsministerium der Regierung der Vereinigten Staaten entwickelt und durch die Regierung der Vereinigten Staaten einer öffentlichen Verwendung zugeteilt. Mit der Zeit wurden das Übertragungssteuerprotokoll (TCP; TCP = Transmission Control Protocol) und das unzuverlässige Datagramm-Protokoll (UDP; UDP = Unreliable Datagram Protocol) zur Verwendung mit dem IP entwickelt. Das erstere Protokoll (TCP/IP) ist ein Protokoll, das eine Übertragung von Daten ohne Fehler garantiert, da es eine bestimmte Prüffunktionalität implementiert, und das letztere Protokoll (UDP/IP) ist ein Protokoll, das eine Übertragung von Daten nicht garantiert, jedoch viel weniger Mehraufwand benötigt als die TCP/IP-Plattform. Ferner wurde das einfache Netzverwaltungsprotokoll (SNMP; SNMP = Simple Network Management Protocol) schließlich zur Verwendung mit einer UDP/IP-Plattform entwickelt, um die verschiedenen sich auf einem Netz befindlichen Vorrichtungen zu verfolgen und zu verwalten. Die Verwendung der vorangegangenen Protokolle ist in der Industrie weit verbreitet und zahlreiche Verkäufer stellen heute viele Typen von Netzvorrichtungen her, die diese Protokolle einsetzen können.
Einige Verwaltungsstationen weisen Nach-Bedarf-Teilabbildungs-Fähigkeiten auf. Ein solches Beispiel ist „OPENVIEW"^TM von Hewlett-Packard. Bei Nach-Bedarf-Teilabbildungs-Systemen entspricht eine Teilabbildung jeder Ansicht des Netzes, das angezeigt werden soll. Die Netzverwaltungsabbildung ist die Sammlung von allen Teilabbildungen. Bei diesen Nach-Bedarf-Teilabbildungs-Systemen und insbesondere dem „OPENVIEW"^TM-System spezifiziert der Benutzer, welche Teilabbildungen der Benutzer zur Verfügung haben möchte und spezifiziert somit die Teilabbildungen, die innerhalb der Abbildung vorhanden sind. Ferner kann der Benutzer auch eine Teilabbildung öffnen oder „explodieren", während der Operation, obwohl diese nicht als in der Abbildung vorhanden spezifiziert ist. In diesem Fall wird die Teilabbildung direkt aus den Topologiedaten erzeugt, wenn der Benutzer die Verwalterstation auffordert, die Teilabbildung zu öffnen, und somit den geforderten Namen.
Obwohl die gegenwärtig erhältlichen SNMP-Verwaltungsstationen zu einem gewissen Grad verdienstvoll sind, ist die Technik der SNMP-Verwaltungsstationen immer noch in ihren Kinderschuhen und das Verhalten dieser Verwaltungsstationen kann weiter verbessert und optimiert werden. Ein spezifischer Bereich, wo eine Optimierung erwünscht wäre, umfasst das kundenspezifische Erzeugen der Netzverwaltungsabbildung. Gegenwärtig wird eine Netztopologie entdeckt, und alle diese Topologie-Informationen werden in der Netzverwaltungsabbildung angezeigt. Diese Lage führt zu einer Anhäufung von Objekten in den Teilabbildungen und zu einer Abschwächung der Funktionalität, die jede Teilabbildung betrifft. Ferner führt diese Situation zu einer unnötigen Verwendung von Speicherraum mit einer resultierenden unerwünschten Ausgabe und einer übermäßigen Zwischenprozesskommunikation oder einem Kontext-Schalten, was das Verfahren verschlechtert.
Somit besteht ein Bedarf in der Industrie nach einem System und einem Verfahren zum besseren kundenspezifischen Erzeugen der Inhalte der Netzverwaltungsabbildung für eine Verwaltungsstation zum Zweck des Reduzierens von Objektanhäufung, zum Minimieren von Speicheranforderungen und zum Minimieren von Kosten und Optimieren des Verhaltens (einschließlich Geschwindigkeit).
Die US-A-5,202,985 beschreibt ein Verfahren und eine Vorrichtung in einem Datenkommunikationsnetz zum Bestimmen des Leitens in einem Diagnosekanal. Das Verfahren verwendet einen Such-Token, der durch Knoten eines Speichermodells des Netzes geleitet wird. Das Speichermodell stellt Knoten als ein (oder eine Kombination aus mehreren) Objektmodell dar, das eine Ansammlung, Ansammlungs-Aufhebung, Vernetzungs- oder Übersetzungs-Operation darstellt. Durch Bezug nahme auf eine relationale Datenbank werden selektive Suchvorgänge ausgeführt, ohne einen Bedarf zum Überfluten des Netzes mit Such-Token. Die Suchergebnisse können graphisch für ein leichteres Verständnis angezeigt werden. Das Verfahren hat auch eine allgemeine Anwendung an ein relationales Datenbank-Verwaltungssystem, durch Ermöglichen einer Anzeige der Datenbank-Beziehungen und -Verbindungen auf graphische Weise für eine leichtere Interpretation durch den Benutzer.
Es ist die Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren für ein besseres kundenspezifisches Erzeugen der Inhalte der Netzverwaltungsabbildung für eine Verwaltungsstation zum Zweck des Reduzierens von Objektanhäufung, zum Minimieren von Speicheranforderungen und zum Minimieren von Kosten und Optimieren des Verhaltens (einschließlich Geschwindigkeit) zu schaffen.
Diese Aufgabe wird gelöst durch ein System gemäß Anspruch 1, ein Verfahren gemäß Anspruch 8 und ein computerlesbares Medium gemäß Anspruch 9.
Zusammenfassung der Erfindung
Kurz beschrieben ist die vorliegende Erfindung ein Filtersystem und -Verfahren für eine Verwaltungsstation zum kundenspezifischen Erzeugen der Inhalte einer Netzverwaltungsabbildung. Das System weist einen Prozessor, der die Anweisungen ausführt, die durch die verschiedenen Softwareelemente des Systems geliefert werden, einen Speicher zum Speichern der verschiedenen Softwareelemente, eine Anzeige zum Zeigen der Vorrichtungen und Verbindungen des Netzes, eine Schnittstelle, die die vorangehenden Elemente und das Netz verbindet, einen Entdeckungsmechanismus zum Bestimmen der Netztopologiedaten, einen Entwurfsmechanismus zum Umwandeln der Netztopologiedaten in Abbildungsdaten und zum Treiben der Anzeige mit den Abbildungsdaten, und ein Fil tersystem, das ein wesentliches Merkmal der vorliegenden Erfindung ist, wie hierin nachfolgend weiter beschrieben wird, auf.
Das Filtersystem kann an einer oder mehreren von drei möglichen Positionen in der Verwaltungsstation positioniert sein. Erstens kann das Filtersystem zwischen dem Entdeckungsmechanismus und dem Entwurfsmechanismus positioniert sein, so dass das Filtersystem Objekte innerhalb der Topologiedaten filtert, die von dem Entdeckungsmechanismus zu dem Entwurfsmechanismus fließen. Zweitens kann das Filtersystem auch zwischen dem Entwurfsmechanismus und dem Netz positioniert sein, so dass das Filtersystem Objekte innerhalb der Topologiedaten filtert, die von dem Netz zu dem Entdeckungsmechanismus fließen. Drittens kann das Filtersystem auch zwischen Entdeckungsmechanismen positioniert sein, so dass das Filtersystem Objekte innerhalb der Topologiedaten filtert, die zwischen den Entdeckungsmechanismen fließen.
Bei einer Implementierung, bei der mehr als ein Filtersystem eingesetzt wird, ist es wünschenswert, dass die Filtersysteme eine gemeinsame Filterbibliothek verwenden, die die Filterspezifikation enthält, die sich auf die Objekte bezieht. Die Filterspezifikation, die jedem Filtersystem zugeordnet ist, kann eine Liste aus einem oder mehreren Objekten umfassen, die erlaubt oder nicht erlaubt werden sollen, einen Boolschen Ausdruck (oder Gleichung), der definiert, welche Objekte erlaubt oder nicht erlaubt werden sollen, oder jeglichen anderen Mechanismus zum Spezifizieren einer Filterbedingung.
Das Filtersystem und -Verfahren der vorliegenden Erfindung hat zahlreiche andere Vorteile, wobei einige derselben hierin nachfolgend als Beispiele ausgeführt werden.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie die Inhalte der Netzverwaltungsabbildung kunden spezifisch erzeugen können, die durch eine Verwaltungsstation erzeugt werden, um die Anhäufung von Objekten in Teilabbildungen zu reduzieren.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie Speicheranforderungen sowie die resultierenden Kosten zum Erzeugen einer Netzverwaltungsabbildung in einer Verwaltungsstation minimieren.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie das Verhalten eines Prozesses zum Erzeugen einer Netzverwaltungsabbildung in einer Verwaltungsstation verbessern.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie die erforderliche Verarbeitungszeit zum Erzeugen einer Netzverwaltungsabbildung in einer Verwaltungsstation minimieren.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie eine erforderliche Zwischenprozesskommunikation bei einer Verwaltungsstation zum Erzeugen einer Netzverwaltungsabbildung eines Datenkommunikationsnetzes minimieren.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie einfach im Hinblick auf den Entwurf und einfach zu implementieren sind.
Ein anderer Vorteil des Filtersystems und -Verfahrens ist, dass sie effizient sowie zuverlässig in ihrer Operation sind.
Andere Merkmale und Vorteile der vorliegenden Erfindung werden für einen Fachmann auf dem Gebiet nach der Untersuchung der nachfolgenden Zeichnungen und der detaillierten Beschreibung offensichtlich. Alle solchen zusätzlichen Objekte, Merkmale und Vorteile sollen hierin innerhalb des Schutzbereichs der vorliegenden Erfindung umfasst sein, wie in den Ansprüchen definiert ist.
Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung ist besser verständlich Bezug nehmend auf die nachfolgenden Zeichnungen im Kontext des Textes. Die Zeichnungselemente sind nicht notwendigerweise maßstabsgetreu zueinander, wobei die Betonung statt dessen auf das deutliche Darstellen der Prinzipien der vorliegenden Erfindung gelegt wird. Ferner bezeichnen gleiche Bezugszeichen entsprechende Teile durchgehend in den verschiedenen Ansichten.
1 ist ein Blockdiagramm einer Verwaltungsstation mit einer Entdeckungs-/Entwurfs-Software, die das Filtersystem und -Verfahren der vorliegenden Erfindung einsetzt;
2 ist ein schematisches Diagramm, das eine Netzverwaltungsabbildung darstellt, die eine Sammlung aus Teilabbildungen aufweist, wobei jede derselben auf der Anzeige der Verwaltungsstation durch die Entdeckungs-/Entwurfs-Software aus 1 angezeigt werden kann;
3 ist ein Blockdiagramm eines ersten Beispiels der Verwaltungsstation aus 1, bei dem ein Filtersystem zwischen einem Entwurfsmechanismus und einem Entdeckungsmechanismus positioniert ist;
4 ist ein erstes Ausführungsbeispiel der Verwaltungsstation aus 1, bei der ein Filtersystem zwischen dem Entdeckungsmechanismus und dem Netz positioniert ist;
5 ist ein zweites Beispiel der Verwaltungsstation aus 1, bei der ein Filtersystem zwischen parallelen Entdeckungsmechanismen positioniert ist;
6 ist ein zweites Ausführungsbeispiel der Verwaltungsstation aus 1, bei der eine Mehrzahl von Filtersystemen eine gemeinsame Filterbibliothek verwenden;
7 ist ein Flussdiagramm, das die Architektur und Funktionalität des Topologie-Zu-Abbildung-Übersetzers aus 3 darstellt;
8 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Filter-Initialisieren-Blocks aus 7 darstellt;
9 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Abbildung-Aktualisieren-Blocks aus 7 darstellt;
10 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Asynchrone-Ereignisse-Blocks aus 7 darstellt;
11 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Ereignisse-Lesen-Blocks aus 10 darstellt;
12 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Objektinformationen-Wiedergewinnen-Blocks aus 10 darstellt;
13 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Objektliste-Filtern-Blocks aus 12 darstellt;
14 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Objekt-Prüfen- (gegen Filter) Blocks aus 13 darstellt;
15 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Objekt-Prüfen- (gegen alle Filterausdrücke) Blocks aus 14 darstellt;
16 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Abbildungsänderungen-Berechnen-Blocks aus 10 darstellt;
17 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Teilabbildungsänderungen-Berechnen-Blocks aus 16 darstellt;
18 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Netzwerkänderung-Handhaben-Blocks aus 17 darstellt;
19 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Segmentänderung-Handhaben-Blocks aus 17 darstellt;
20 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Knotenänderung-Handhaben-Blocks aus 17 darstellt;
21A zeigen ein Flussdiagramm, das die Architektur und bis 21C Funktionalität eines Schnittstellenänderung-Handhaben-Blocks aus 17 darstellt;
22 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Abbildung-Aktualisieren-Blocks aus 10 darstellt; und
23 ist ein Flussdiagramm, das die Architektur und Funktionalität eines Auf-Befehl-Teilabbildungs- Blocks innerhalb der graphischen Benutzerschnittstelle (GUI; GUI = graphical user interface) aus 3–5 darstellt.
Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
Das Filtersystem der vorliegenden Erfindung kann auf jeglichem computerlesbaren Medium gespeichert sein zur Verwendung durch oder in Verbindung mit einem computerverwandten System oder Verfahren. Im Kontext dieses Dokuments ist ein computerlesbares Medium eine elektronische, magnetische, optische oder andere physische Vorrichtung oder Einrichtung, die ein Computerprogramm zur Verwendung durch oder in Verbindung mit einem computerverwandten System oder Verfahren enthalten oder speichern kann. Somit kann z. B. das neue Filtersystem auf einer tragbaren Diskette gespeichert und transportiert werden, oder als ein anderes Beispiel könnte das Filtersystem in dem Speicher eines Computers gespeichert sein zum Zweck des Treibens des Computers, wenn es aufgerufen wird.
1 zeigt ein Blockdiagramm einer objektorientierten Verwaltungsstation 100, die mit einem Allzweck-Computersystem implementiert ist, das eine Entdeckungs-/Entwurfs-Software 101 enthält, die das Filtersystem und die zugeordnete Methodik der vorliegenden Erfindung einsetzt. Das neue Filtersystem wird durch das Bezugszeichen 103 in 1 bezeichnet. Unter weiterer Bezugnahme auf 1 enthält die Verwaltungsstation 100 einen herkömmlichen Prozessor 102. Der Prozessor 102 kommuniziert mit anderen Elementen innerhalb der Verwaltungsstation 100 über eine Schnittstelle 104, wie z. B. einem Bus oder ein Bus-Netz. Eine Eingabevorrichtung 106, z. B. eine Tastatur oder eine Maus, wird zum Eingeben von Daten von einem Benutzer der Verwaltungsstation 100 verwendet, und eine Anzeige 108 wird verwendet, um Daten zu dem Benutzer auszugeben. Eine Netzschnittstelle 112 wird verwendet, um die Verwaltungsstation 100 schnittstellenmäßig mit einem Netz 118 zu verbinden, um zu ermöglichen, dass die Verwaltungsstation 100 als ein Knoten auf einem Netz 118 wirkt. Ein Speicher 110 innerhalb der Verwaltungsstation 100 enthält eine Entdeckungs-/Entwurfs-Software 101. Die Entdeckungs-/Entwurfs-Software 101 kommuniziert mit einem herkömmlichen Betriebssystem 122 und einer herkömmlichen Netzsoftware 124, um die Knoten auf dem Netz 118 zu entdecken. Die Netzsoftware 124 dient als die Intelligenz, einschließlich Validierung, für die Datenkommunikationsprotokolle. Wie in 1 gezeigt ist, implementiert bei dem bevorzugten Ausführungsbeispiel die Netzsoftware das IP, das TCP und UDP über dem IP und das SNMP über dem UDP. Alle der vorangehenden Protokolle sind in der Technik bekannt.
Die Entdeckungs-/Entwurfs-Software 101 implementiert eine objektorientierte Funktionalität. In dem Kontext von SNMP-Verwalten und diesem Dokument bedeutet objektorientiert, dass die meisten der Verwaltungssystem-Aktionen und -Prozesse, die der Benutzer aufrufen kann, hin zu einer Klasse von Vorrichtungen gerichtet sind und nicht individuell verwaltete Netzwerkknoten sind.
Im Allgemeinen ist die Entdeckungs-/Entwurfs-Software 101 aus 1 konfiguriert, um die Netztopologie zu entdecken, d. h. Netz-Knoten und -Knotenverbindungen, die auf dem Netz 118 existieren, und um eine Netzverwaltungsabbildung aufzubauen, die verschiedene Teilabbildungen aufweist, wobei jegliche derselben zum Anzeigen der Netztopologie auf der Anzeige 108 verwendet werden können. 2 zeigt eine Netzverwaltungsabbildung 200, die durch die Entdeckungs-/Entwurfs-Software 101 aus Topologiedaten erzeugt wird, die von dem Netzwerk 118 entdeckt werden. Die Entdeckungs-/Entwurfs-Software 101 kann jegliche der verschiedenen Teilabbildungen zu der Anzeige 108 (1) treiben, zum Betrachten durch den Benutzer.
Die Teilabbildungen in der Abbildung 200 aus 2 sind in einer Hierarchie angeordnet. Eine Grund- bzw. Wurzel-Teilabbildung 202 ist auf einer Grundebene definiert. Die Grundteilabbildung 202 stellt die Teilabbildung der höchsten logischen Ebene in der Hierarchie dar und zeigt Objekte 203, die als Ankerpunkte für verschiedene Teilabbildungshierarchien wirken. Jede Hierarchie ist ein separater Verwaltungsbereich. Dies könnte z. B. ein Netz, eine Logikgruppierung von Knoten oder ein bestimmter anderer Bereich sein. Eine Zwischennetz- bzw. Internetteilabbildung 204 ist an einer Zwischennetzebene definiert und wird durch ein „Explodieren" eines Objekts 203 innerhalb der Grundteilabbildung 202 erzeugt. „Explodieren" in dem Zusammenhang dieses Dokuments bedeutet, dass der Benutzer die Verwaltungsstation 100 mit der Eingabevorrichtung 106 auffordert, zusammenzubrechen und mehr Daten, die zu dem zur Debatte stehenden Objekt 203 gehören, bereitzustellen. Ferner stellt die Zwischennetzteilabbildung 204 Objekte 203 in der Form von Netzen und Routern dar. Jede einer Anzahl von Netzteilabbildungen 206 kann durch Explodieren aus der Zwischennetzteilabbildung 204 erzeugt werden. Jede Netzteilabbildung 206 zeigt Objekte 203 in der Form von Segmenten und Verbindungselementen. Jede einer Anzahl von Segmentteilabbildungen 208 kann durch Explodieren aus einem Objekt 203 innerhalb einer Netzteilabbildung 206 erzeugt werden. Jede Segmentteilabbildung 208 zeigt Objekte in der Form von Netzknoten. Schließlich kann jede einer Anzahl von Knotenteilabbildungen 210 durch Explodieren aus einem Objekt 203 innerhalb einer Segmentteilabbildung 208 erzeugt werden. Jede Knotenteilabbildung 210 zeigt Objekte 203 in der Form von Schnittstellen innerhalb dieses Knotens.
Bei dem bevorzugten Ausführungsbeispiel implementiert die Entdeckungs-/Entwurfssoftware 101, obwohl dies zur Praktizierung der vorliegenden Erfindung nicht nötig ist, Teilabbildungen auf Abruf, um Speicher und Verarbeitungszeit zu sparen. Das Konzept von Teilabbildungen auf Abruf besteht darin, nur die Teilabbildungen in der Abbildung 200 aus 2 zu platzieren, die der Benutzer sehen möchte. Das Nettoergebnis ist, dass nur ein Abschnitt der Teilabbildungshierarchie zu einer bestimmten Zeit in der Netzverwaltungsabbildung 200 ist. In 2 werden Teilabbildungen (nicht resident), die nicht vorhanden sind, auf ein Auffordern durch den Benutzer hin jedoch erzeugt würden, durch eine Schraffur angezeigt. Der residente Teilabbildungsteilsatz der Hierarchie verändert sich über die Zeit, wenn der Benutzer die Teilabbildungshierarchie durchquert und eine Erzeugung nicht residenter Teilabbildungen bewirkt.
A. Erstes Beispiel der Entdeckungs-/Entwurfs-Software
Ein Blockdiagramm der Entdeckungs-/Entwurfssoftware 101 (1) auf hoher Ebene ist in 3 dargelegt. Mit Ausnahme des Filtersystems 103 ist die Architektur der Entdeckungs-/Entwurfs-Software 101 in 3 im Wesentlichen dieselbe wie oder ähnlich zu der Architektur des bekannten und handelsüblich erhältlichen Verwaltungssoftwarepakets, genannt „OPENVIEW"^TM der Hewlett-Packard Company.
Wie in 3 gezeigt ist, weist auf einer allgemeinen Architekturebene die Entdeckungs-/Entwurfssoftware 101 einen Entdeckungsmechanismus 302 zum Entdecken von Knoten und Zwischenverbindungen des Netzes 118 und einen Entwurfsmechanismus 304 zum Empfangen von Topologiedaten von dem Entdeckungsmechanismus 302 und zum Erzeugen der 200 (2) zum Treiben der Anzeige 108 auf. Ferner können eine oder mehrere Integrieranwendungen 332 Anzeige- und Abbildungs-Informationen mit dem Entwurfsmechanismus 304 kommunizieren.
Der Entdeckungsmechanismus 302 weist eine Netzüberwachungsvorrichtung 306, die mit dem Netz 118 verbunden ist, wie durch Verbindungen 308a, 308b angezeigt ist, einen Topologieverwalter 310, der mit der Netzüberwachungsvorrichtung 306 verbunden ist, wie durch Pfeile 312a, 312b angezeigt ist, und eine Topologiedatenbank, die in Kommunikation mit dem Topologieverwalter 310 steht, wie durch einen Pfeil 316 angezeigt ist, auf.
Die Netzüberwachungsvorrichtung 306 sendet und empfängt Datenpakete zu und von dem Netz 118. Die Netzüberwachungsvorrichtung 306 entdeckt und überwacht eine Netztopologie, wie durch Pfeile 308a, 308b angezeigt ist. Wenn sich die Netztopologie auf dem Netz verändert, erzeugt die Netzüberwachungsvorrichtung 306 Ereignisse oder Fallen (SNMP-einheimisch), die einen Objektidentifizierer und Objektveränderungsinformationen umfassen. Die Netzüberwachungsvorrichtung 306 kann außerdem Ereignisse von anderen Vorrichtungen, wie z. B. einem Router, in dem Netz 118 empfangen. Die Netzüberwachungsvorrichtung 306 steht mittels der Netzsoftware 124 (1), die im Wesentlichen Protokollstapel aufweist, die bei dem bevorzugten Ausführungsbeispiel IP, TCP, UDP und SNMP entsprechen, und die allgemein diese Protokolle implementiert und Validierungsfunktionen durchführt, in Wechselwirkung mit dem Netz 118. Ferner bestückt die Netzüberwachungsvorrichtung 306 die Topologiedatenbank 314 mittels des Topologieverwalters 310 und benachrichtigt den Topologieverwalter 310 über Ereignisse (Topologieveränderungen). Schließlich soll angemerkt werden, dass das US-Patent Nr. 5,185,860 von Wu ein Knotenentdeckungssystem beschreibt, das eingesetzt werden könnte, um die Netzüberwachungsvorrichtung 306 hierin zu implementieren.
Der Topologieverwalter 310 verwaltet die Topologiedatenbank 314, wie durch einen bidirektionalen Pfeil 316 angezeigt ist. Der Topologieverwalter 310 fordert die Netzüberwachungsvorrichtung 306 auf, Topologiedaten, die auf bestimmte Ereignisse bezogen sind, zu aktualisieren, wie durch einen Pfeil 312a angezeigt ist, und empfängt Topologieaktualisierungen, wie durch einen Pfeil 312b angezeigt ist.
Die Topologiedatenbank 314 speichert Topologiedaten basierend auf Objekten, die verwendet werden, um das Netz aus logischen Gründen zu partitionieren. Objekte umfassen z. B., jedoch nicht ausschließlich, ein Netz, ein Segment, einen Computer, einen Router, einen Repeater, eine Brücke, usw. Ferner umfassen die in Bezug auf die Objekte gespeicherten Topologiedaten z. B., jedoch nicht ausschließlich, eine Schnittstellen- oder Vorrichtungsadresse, einen Schnittstellen- oder Vorrichtungstyp, einen Schnittstellen- oder Vorrichtungshersteller sowie, ob eine Schnittstelle oder Vorrichtung das SNMP unterstützt.
Das Filtersystem 103 empfängt Topologiedaten von dem Topologieverwalter 310, wie durch den Pfeil 320b' angezeigt wird, filtert die Topologiedaten und leitet die verarbeiteten Daten zu dem Entwurfsmechanismus 304 weiter, wie durch den Pfeil 320b'' gezeigt ist. Das Filtersystem 103 behält eine Filter-Bibliothek 321 bei, die spezifiziert, welche Objekte innerhalb der Topologiedaten von dem Entdeckungsmechanismus 302 zu dem Entwurfsmechanismus 304 kommuniziert werden sollen. Im Wesentlichen bestimmt die Bibliothek, ob Objekte zulässige Objekte oder nicht-zulässige Objekte sind. Ferner werden zulässige Objekte schließlich in Abbildungsdaten umgewandelt und angezeigt, wohingegen nichtzulässige Objekte nicht in Abbildungsdaten umgewandelt und nicht angezeigt werden.
Obwohl dies zum Ausführen der Erfindung nicht notwendig ist, enthält bei dem bevorzugten Ausführungsbeispiel die Filterbibliothek eine Auflistung aus Filternamen, die in drei Gruppen organisiert sind, nämlich Sätzen, Filtern und Filterausdrücken, die hierin nachfolgend kurz beschrieben werden.
Ein Satz ist einfach eine Liste aus Zeichenfolgen. Die einzige Operation, die an Sätzen verfügbar ist, ist der Test im Hinblick auf Zugehörigkeit, (die durch den Boolschen NOT-Operator eingeleitet werden kann). Satzbauglieder können in der Filterdatei selbst aufgezählt werden oder können in einer separaten Datei aufgelistet werden. Jegliches Satzbauglied, das mit einem Schrägstrich (/) beginnt, wird als der Name einer Datei angenommen, in der Satzbauglieder aufgelistet sind, einer pro Zeile. Dateien in Zahlenzeichenfolgen können in der selben Satz-Definition vermischt sein.
Filter sind Boolsche Ausdrücke aus Datenbankfeldern und Werten. Ein geeigneter Satz aus Boolschen Ausdrücken kann innerhalb der Filter eingesetzt werden. Bei dem bevorzugten Ausführungsbeispiel umfassen die Boolschen Operatoren folgendes: „==" für „ist gleich"; „!=" für „ist nicht gleich"; „<" für „kleiner als"; „<=" für „ist kleiner oder gleich"; „>" für „größer als"; „>=" für „größer als oder gleich"; „~" für „ungefähr gleich"; und „!~" für „ist nicht ungefähr gleich". Ferner sind die Operanden, die durch die zuvor erwähnten Boolschen Operatoren kombiniert werden, entweder ein Feldname oder ein allgemeinen Wert, mit dem Datenbankfeldwerte verglichen werden.
Ein Filterausdruck ermöglicht, dass mehrere Filter an einen Satz aus Objekten angewendet werden, ohne zu erfordern, dass ein neues Filter nur die logische Kombination der anderen ist. Die einzigen gültigen Operanden bei einem Filterausdruck sind Filter, die vorangehend in der selben Filterdatei definiert wurden. Ferner kann jeglicher geeigneter Satz von Boolschen Ausdrücken innerhalb der Filterausdrücke verwendet werden. Bei dem bevorzugten Ausführungsbeispiel sind die Boolschen Operatoren, die bei den Filterausdrücken verwendet werden, unterschiedlich zu jenen, die bei den Filtern verwendet werden. Genauer gesagt sind die Boolschen Ausdrücke, die bei den Filterausdrücken verwendet werden: „||" für „oder"; „&&" für ein „und"; „!" für „nicht"; und „(" und „)", die verwendet werden, um die Reihenfolge der Operandenverarbeitung zu definieren.
Im Wesentlichen stellen diese Gruppen drei unterschiedliche Möglichkeiten für einen Benutzer dar, die Filterspezifikation zu spezifizieren, wobei die Art von dem Objekttyp abhängt, das gefiltert wird. Die Sprache für die Filterbibliothek 321 bei dem bevorzugten Ausführungsbeispiel wird hierin nachfolgend in Tabelle A ausgeführt. Die Auflistung in Tabelle A wird hierin als die Filterdefinitionsdateigrammatik bezeichnet und wird in dem Speicher 111 beibehalten (1). Tabelle A
Ein Beispiel einer Filterdatei, die durch die Filter-Bibliothek 321 verwendet wird, wird hierin nachfolgend ausgeführt: Tabelle B
Wie in Tabelle B gezeigt ist, werden die Filter in drei Gruppen unterteilt, d. h. Sätze (sets), Filter (filters), und Filterausdrücke (filter expressions).
Bei dem Beispiel von Tabelle B sind folgendes Filternamen:
CriticalNodes, BackboneNodes, Router, Level2Conn, MultiIF, Critical, Backbone, AdminNode, Connectors, MultiSegment-Hosts und BackboneNodes. Bei diesem Beispiel wird z. B. CriticalNodes spezifiziert als der Knoten „ov1" und eine Datei „/var/openview/critical.nodes" und daher sind die vorangehenden Knoten zulässig und werden durch das Filtersystem 103 kommuniziert. Ferner ist bei diesem Beispiel der Filterausdruck „Connectors" z. B. zulässig, wenn der Filterausdruck „Router %% Level2Conn" wahr ist, d. h., wenn sowohl Router als auch Level2Conn wahr oder zulässig sind.
Der Entwurfsmechanismus 304 weist einen Topologie-Zu-Abbildung-Übersetzer 318 in Kommunikation mit dem Filtersystem 103, wie durch den unidirektionalen Pfeil 320b'' angezeigt wird, und den Topologieverwalter 310, wie durch den unidirektionalen Pfeil 320a angezeigt wird, eine graphische Benutzerschnittstelle (GUI; GUI = graphical user interface) 322 in Kommunikation mit dem Topologie-Zu-Abbildung-Übersetzer 318, wie durch die Pfeile 324a, 324b angezeigt wird, und eine Abbildungsdatenbank 326 in Kommunikation mit der GUI 322, wie durch den bidirektionalen Pfeil 328 angezeigt wird, auf. Die Integrieranwendung 332 kommuniziert Informationen mit der GUI 322, wie durch die Pfeile 333a, 333b angezeigt wird.
Es sollte darauf hingewiesen werden, dass die Netzwerküberwachungsvorrichtung 306, der Topologieverwalter 310, der Übersetzer 318 und die GUI 322 sich beim Verwenden der Kombination des Betriebssystems 122 (1) und des Prozessors 102 (1) abwechseln, um drei jeweilige Funktionen auszuführen. Ein „Kontextschalten", wie es hierin verwendet wird, bezieht sich auf eine Änderung bei der Steuerung des Systems 122 und/oder des Prozesses 102 durch die vorangehenden Softwareelemente.
Der Übersetzer 318 wandelt Topologiedaten aus der Topologiedatenbank 314 in Abbildungsdaten um und konstruiert die verschiedenen Teilabbildungen 202–210 in der Netzverwaltungsabbildung 200 aus 2. Der Übersetzer 318 kann eine Anforderung zu dem Topologieverwalter 310 weiterleiten, wie durch den Pfeil 320a angezeigt wird, um Topologiedaten zu erhalten, die sich auf bestimmte Objekte beziehen. Ferner, zusätzlich zu dem Weiterleiten von Topologiedaten zu dem Übersetzer 318 auf eine Anfrage hin, weist der Topologieverwalter 310 den Übersetzer 318 an, mit Hilfe des Filtersystems 103, wie durch die Pfeile 320b', 320b'' angezeigt wird, wenn sich Topologiedaten basierend auf einem Ereignis verändert haben, so dass der Übersetzer 318 entsprechende Änderungen in den Teilabbildungen ausführen kann.
Die GUI 322 verwaltet die Abbildungsdatenbasis 326, wie durch den bidirektionalen Pfeil 328 angezeigt wird, und verwaltet die Anzeige 108 und Eingabevorrichtung 106, wie durch die Pfeile 330a, 330b angezeigt wird. Die GUI 322 empfängt Abbildungsaktualisierungen von dem Übersetzer 318, wie durch Pfeil 324b angezeigt wird, und übermittelt vom Benutzer ausgelöste Ereignisse zu dem Übersetzer 318, wie durch den Pfeil 324a angezeigt wird. Ein vom Benutzer ausgelöstes Ereignis umfasst eine Aufforderung 330a von einem Benutzer, ein Objekt zu explodieren, wie Bezug nehmend auf 2 beschrieben wurde. Abschließend sollte darauf hingewiesen werden, dass das U.S.-Patent Nr. 5,276,789 an Besaw u. a. eine graphische Benutzerschnittstelle beschreibt, die eingesetzt werden könnte, um die GUI 322 hierin zu implementieren.
B. Erstes Ausführungsbeispiel der Entdeckungs-/Entwurfs-Software
Ein Blockdiagramm eines ersten Ausführungsbeispiels der Entdeckung-/Entwurfs-Software 101 (1) auf hoher Ebene ist in 4 ausgeführt. Wie in 4 gezeigt ist, ist das erste Ausführungsbeispiel ähnlich zu dem ersten Beispiel (3) aufgebaut, und die vorangehende Erörterung von ähnlich identifizierten Elementen ist hierin durch Bezugnahme aufgenommen. Tatsächlich sind sowohl der Entdeckungsmechanismus 302 als auch der Entwurfsmechanismus 304 des ersten Beispiels und des ersten Ausführungsbeispiels der Entdeckungs-/Entwurfs-Software 101 im Allgemeinen identisch. Das Filtersystem 103 bei dem ersten Ausführungsbeispiel ist jedoch zwischen dem Entdeckungsmechanismus 302 und dem Netz 118 so positioniert, dass das Filtersystem 103 Objekte filtert, die von dem Netz 118 zu dem Entdeckungsmechanismus 302 verlaufen. Bei dieser Konfiguration verhindert das Filtersystem 103, dass nicht-zulässige Objekte in der Topologiedatenbank 314 gespeichert werden.
C. Zweites Beispiel der Entdeckungs-/Entwurfs-Software.
Ein Blockdiagramm eines zweiten Beispiels der Entdeckungs-/Entwurfs-Software 101 (1) auf hoher Ebene ist in 5 gezeigt. Das zweite Beispiel aus 5 ist ähnlich zu dem ersten Beispiel und dem ersten Ausführungsbeispiel aufgebaut (3 und 4), und die vorangehende Erörterung von ähnlich identifizierten Elementen ist hierin durch Bezugnahme aufgenommen. Tatsächlich ist der Entwurfsmechanismus 304 des zweiten Beispiels identisch zu dem des ersten Beispiels und des ersten Ausführungsbeispiels. Ein wesentlicher Unterschied zwischen dem zweiten Beispiel und dem ersten Beispiel und dem ersten Ausführungsbeispiel ist jedoch die Tatsache, dass das zweite Beispiel eine Mehrzahl von Entdeckungsmechanismen 302 verwendet (nur zwei sind in 5 der Einfachheit halber gezeigt, aber mehr sind möglich).
Die Entdeckungsmechanismen 302 funktionieren allgemein parallel zu den Entdeckungsvorrichtungen und Verbindungen auf dem Netz 118. Die Topologie von jedem Entdeckungsmechanismus 302 ist zu einem einzelnen bestimmten Topologieverwalter 310 zusammengeführt, wo sie dann zu dem Topologie-Zu-Abbildung-Übersetzer 318 kommuniziert wird, wie durch den Referenzpfeil 320b in 5 angezeigt wird. Ferner werden Anforderungen nach Topologiedaten von dem Übersetzer 318 zu dem bestimmten Topologieverwalter 310 weitergeleitet, der dann die Informationen wiedergewinnt.
Die Entdeckungsmechanismen 302 können Topologiedaten zwischen ihren jeweiligen Topologieverwaltern 310 mit Hilfe eines Filtersystems 103 übertragen, wie durch Pfeile 501a, 501b, 502a, 502b angezeigt wird. Das Filtersystem 103, wie es in diesem Kontext verwendet wird, verhindert die Übertragung von nicht-zulässigen Objekten von einem der Entdeckungsmechanismen 302 zu dem anderen, während die Übertra gung von zulässigen Objekten ermöglicht wird. Ferner wird durch die Filterbibliothek 321 definiert, ob ein Objekt zulässig oder nicht-zulässig ist, wie vorangehend erörtert wurde.
D. Zweites Ausführungsbeispiel der Entdeckungs-/Entwurfs-Software.
Ein Blockdiagramm auf hoher Ebene eines zweiten Ausführungsbeispiels der Entdeckungs-/Entwurfs-Software 101 (1) ist in 6 ausgeführt. Wie in 6 gezeigt ist, weist das zweite Ausführungsbeispiel eine Mischung der Merkmale auf, die dem ersten und zweiten Beispiel und dem ersten Ausführungsbeispiel zugeordnet sind. Das zweite Ausführungsbeispiel umfasst zumindest zwei Entdeckungsmechanismen 302 (nur zwei sind in 6 der Einfachheit halber gezeigt, aber mehr sind möglich). Ferner umfasst das zweite Ausführungsbeispiel eine Mehrzahl von Filtersystemen 103, die alle eine gemeinsame Filterbibliothek 321 verwenden, wie durch den Referenzpfeil 602 angezeigt wird.
Genauer gesagt ist ein erstes Filtersystem 103 zwischen den Entdeckungsmechanismen 302 und dem Entwurfsmechanismus 304 positioniert, wie durch die Pfeile 320b', 320b'' angezeigt wird. Der Einfachheit halber ist nur der Filterdatenfluss in 6 dargestellt. Die zuvor erwähnte Platzierung des Filtersystems 103 ist ähnlich zu der, die in Bezug auf das erste Beispiel beschrieben wurde.
Ein zweites Filtersystem 103 ist zwischen jedem der Entdeckungsmechanismen 302 und dem Netz 118 positioniert, wie durch die Pfeile 308b', 308b'' angezeigt wird, um Objekte innerhalb von Topologiedaten zu filtern, die von dem Netz 118 empfangen werden. Diese Filtersystemkonfiguration ist ähnlich zu der, die vorangehend in Bezug auf das erste Ausführungsbeispiel der Entdeckungs-/Entwurfs-Software 101 beschrieben wurde.
Ein drittes Filtersystem 103 ist zwischen den Entdeckungsmechanismen 302 positioniert, wie durch die Pfeile 501, 502 angezeigt wird, um Objekte innerhalb der Topologiedaten zu filtern, die von einem Entdeckungsmechanismus 302 zu einem anderen Entdeckungsmechanismus 302 übertragen werden. Diese Filtersystemkonfiguration ist ähnlich zu der, die in dem zweiten Beispiel der Entdeckungs-/Entwurfs-Software 101 beschrieben wurde.
Somit, wie aus 6 ersichtlich ist, kann jegliche Kombination der Filtersystemplatzierungen, die vorangehend bei dem ersten und zweiten Beispiel und dem ersten Ausführungsbeispiel beschrieben wurde, verwendet werden, und genauer gesagt können die Filtersysteme 103 die selbe Filterbibliothek 321 gemeinschaftlich verwenden. Da eine gemeinsame Filterbibliothek 321 verwendet wird, werden die individuellen Komponenten davon befreit, die Implementierung und Konfiguration der Filterarchitektur zu verstehen. Ferner bietet die gemeinsame Filterbibliothek 321 ein logisches Filtersystem für den Benutzer. Wenn jede Komponente ihren eigenen Mechanismus implementieren müsste, würde für den Benutzer wahrscheinlich jede Komponente unterschiedlich zu der anderen aussehen.
E. Filtersystem
Das Filtersystem 103 mit der Bibliothek 321 verwendet die selbe Methodik und Architektur für das erste und zweite Beispiel und das erste und zweite Ausführungsbeispiel der Entdeckungs-/Entwurfs-Software 101 (1). Dementsprechend wird zu Zwecken der Einfachheit das Filtersystem 103 in Verbindung mit dem ersten Beispiel der Entdeckungs-/Entwurfs-Software 101 beschrieben, wie in 3 dargestellt ist.
Vorzugsweise, aber nicht notwendigerweise, ist das Filtersystem 103 als ein Teil des Topologie-Zu-Abbildung-Übersetzers 318 implementiert (3). 7 zeigt ein Flussdiagramm 700, das die Architektur und Funktionalität des bevorzugten Ausführungsbeispiels des Topologie-Zu-Abbildung-Übersetzers 318 anzeigt.
Bezug nehmend auf 7 wird zuerst das Filtersystem 103 initialisiert, d. h. die Filter innerhalb der Bibliothek 321 werden initialisiert, wie weiter Bezug nehmend auf 8 beschrieben wird. Als Nächstes werden andere allgemeine Initialisierungsverfahren ausgeführt, wie bei Block 704 angezeigt ist. Die allgemeinen Initialisierungsverfahren umfassen das Einrichten eines Kontakts mit dem Topologieverwalter 310, das Einrichten eines Kontakts mit der GUI 322 und das Lesen von Abbildungskonfigurationsdaten. Block 704 überträgt zu Block 706. Wie bei Block 706 angezeigt ist, wird die Abbildung mit den Änderungen aktualisiert, die in den Topologiedaten aufgetreten sind. Dieses Verfahren wird weiter in 9 geschildert und wird hierin nachfolgend detailliert beschrieben. Als Nächstes überträgt Block 706 zu Block 708. Bei Block 708 werden asynchrone Ereignisse gehandhabt, die weiter in 10 geschildert werden.
8 zeigt ein Flussdiagramm, das die Architektur und Funktionalität des Filter-Initialisieren-Blocks 702 darstellt (7). Bei diesem Softwaremodul werden die Filter, die der Benutzer für die Netzverwaltungsabbildung 200 konfiguriert hat, die gegenwärtig offen ist, identifiziert, und eine Bestimmung darüber wird durchgeführt, ob die Filter in der Filterbibliothek 321 vorliegen.
Wie bei Block 802 aus 8 angezeigt ist, wird die Filterdefinitionsdateigrammatik aus Tabelle A aus dem Speicher 110 gelesen (1). Als Nächstes, wie bei Block 804 angezeigt ist, wird die Syntax der Filterdefinitionsdateigrammatik nach Fehlern geprüft. Die Inhalte dieser Datei sollten der Grammatik folgen, die in Tabelle A ausgeführt ist. Jeglicher geeignete Analyse-Mechanismus kann zum syntaktischen Analysieren der Filterdefinitionsdateigrammatik während des Syntaxprüfverfahrens eingesetzt werden. Bei dem bevorzugten Ausführungsbeispiel werden die LEX- und YACC-Tools des „UNIX"^TM-Betriebssystems zum Analysieren der Felder der Filterdefinitionsdateigrammatik eingesetzt. Die LEX- und YACC-Tools, das „UNIX"^TM-Betriebssystem und das Konzept hinter der Operation dieser Programme sind in der Technik bekannt und ferner sind diese Programme handelsüblich erhältlich. Wenn die Syntax inkorrekt ist, dann wird eine Fehlermeldung über der Anzeige 108 angezeigt (1), wie bei dem Block 806 angezeigt ist, und die Operation des Übersetzers 318 wird abgeschlossen. Wenn die Syntax der Filterdefinitionsdateigrammatik korrekt ist, überträgt Block 804 zu Block 808.
Wie bei Block 808 ausgeführt wird, wird die Liste von Filternamen aus der Abbildungsdatenbank 326 gelesen. Block 808 überträgt zu einer Schleife, die bestimmt, welche Filternamen der betreffenden Abbildung zugeordnet werden sollten. Die Schleife beginnt mit Block 810, wo ein Zähler CTR für Filternamen initialisiert wird.
Nachdem der Zähler CTR initialisiert wurde, wird ein Filtername aus der Liste ausgewählt und durch die Schleife verarbeitet. Wie bei Flussdiagrammblock 812 angezeigt ist, wird bestimmt, ob der Filtername aus der Liste, bezeichnet als FILTERNAMELIST[CTR], wobei CTR = Zahl, in der Filterdefinitionsdateigrammatik ist. Wenn der Filtername FILTELRNAMELIST[CTR] nicht in der Filterdefinitionsdateigrammatik ist, dann wird eine Fehlermeldung über die Anzeige 108 angezeigt, wie bei dem Block 806 gezeigt ist, und der Übersetzer 318 beendet die Operation. Wenn der Filtername FILTERNAMELIST[CTR] in der Filterdefinitionsdateigrammatik ist, dann wird der Filtername FILTERNAMELIST[CTR] für zukünftige Verarbeitung gespeichert, wie bei Block 814 angezeigt ist. Block 814 überträgt zu Block 816, wo der Zähler CTR inkrementiert wird. Als Nächstes wird bei Block 818 eine Bestimmung darüber durchgeführt, ob der Zähler CTR größer ist als die Gesamtanzahl von Filternamen. Wenn nicht, dann überträgt der Block 818 zurück zu Block 812 und die Schleife fährt fort. Wenn doch, dann überträgt der Block 818 zu Block 704 (7).
Somit wurden nach dem Prozess der in 8 ausgeführt ist, die Filter, die der Benutzer für die Netzwerkverwaltungsabbildung 200 konfiguriert hat, die gegenwärtig offen ist, identifiziert, und eine Bestimmung darüber wurde durchgeführt, ob die Filter in der Filterbibliothek 321 vorliegen.
9 stellt ein Flussdiagramm dar, das die Architektur und Funktionalität des Aktualisiere-Abbildung-Blocks 706 beschreibt (7), bei dem die Abbildungsdaten, die innerhalb der Abbildungsdatenbank 326 vorliegen, basierend auf den gefilterten Topologiedaten aktualisiert werden. Wie bei Block 902 angezeigt ist, wird die Liste des einen oder der mehreren Netze durch den Übersetzer 318 aus dem Topologieverwalter 310 wiedergewonnen, der seinerseits die Liste von der Topologiedatenbank 314 erhält. Block 902 überträgt zu einer Schleife, die mit Block 904 beginnt und die die Objekte in jedem Netz verarbeitet und filtert.
Bei Block 904 wird ein Zähler NETCTR initialisiert. Als Nächstes wird bei Block 906 eine Bestimmung darüber durchgeführt, ob das bestimmte Netz NETWORK[NETCTR], wobei NETCTR = Zahl, durch die Filter durchgelassen wird (beschrieben durch die Filternamen), die die Abbildung 200 betreffen, die offen ist. Dieses Verfahren wird später weiter Bezug nehmend auf 13 beschrieben. Wenn bestimmt wird, dass das aktuelle Netz NETWORK[NETCTR] nicht durch die Filter durchgelassen wird, dann wird der Zähler NETCTR inkrementiert, wie bei Block 908 angezeigt ist. Ferner wird eine Bestimmung darüber durchgeführt, ob der Zähler NETCTR die Gesamtanzahl von Netzen in der offenen Abbildung 200 überstiegen hat, wie bei Block 910 angezeigt ist. Wenn bestimmt wird, dass der Zähler NETCTR die Gesamtanzahl von Netzen nicht überschritten hat, dann überträgt der Block 910 zurück zu Block 906 und die Schleife fährt fort. Im Gegensatz dazu, wenn der Zähler NETCTR die Gesamtanzahl von Netzen überschritten hat, dann überträgt Block 910 zurück zu Block 708 (7).
Wenn bestimmt wird, dass das aktuelle Netz NETWORK[NETCTR] zulässig ist, basierend auf den Filtern bei Block 906, dann überträgt Block 906 zu Block 909. Bei Block 909 erhält der Übersetzer 318 eine Liste von Objekten innerhalb NETWORK[NETCTR] von dem Topologieverwalter 310 (und schließlich von der Topologiedatenbank 314). Der Block 909 überträgt zu einer Schleife, die jedes Objekt in der Liste verarbeitet, um zu bestimmen, welche Objekte durch die Filter durchgelassen werden. Diesbezüglich überträgt Block 909 zu Block 911, wo ein Zähler OBJCTR initialisiert wird.
Als Nächstes wird eine Bestimmung darüber durchgeführt, ob das aktuelle Objekt OBJ[OBJCTR], wobei OBJCTR = Zahl, durch die Filter durchgelassen wird, wie bei Block 912 angezeigt ist. Diese Bestimmung wird ferner Bezug nehmend auf 13 hierin nachfolgend beschrieben. Wenn bestimmt wird, dass das aktuelle Objekt OBJ[OBJCTR] nicht durch die Filter durchgelassen wird, dann wird der Zähler OBJCTR inkrementiert, wie bei dem Flussdiagrammblock 914 angezeigt ist. Ferner wird eine Bestimmung darüber durchgeführt, ob der Zähler OBJCTR die Gesamtanzahl von Objekten überschritten hat. Wenn nicht, dann überträgt der Block 916 zurück zu Block 912 und die Schleife fährt fort und verarbeitet das nächste Objekt. Wenn doch, dann überträgt der Block 916 zu dem Block 908 (was eine Auswahl eines anderen Netzes verursacht, falls jegliche derselben verfügbar sind).
Wenn bei Block 912 bestimmt wird, dass das aktuelle Objekt OBJ[OBJCTR] durch die Filter innerhalb der Bibliothek 321 durchgelassen wird, dann überträgt der Block 912 zurück zu Block 918. Bei Block 918 fügt der Übersetzer 318 das aktu elle Objekt zu der Abbildung 200 hinzu. Dieses Verfahren wird weiter in 16 geschildert, die später in diesem Dokument beschrieben wird. Nachdem das Objekt zu der Abbildung hinzugefügt wurde, wird der Zähler OBJCTR inkrementiert und ein anderes Objekt wird verarbeitet, falls verfügbar, wie bei dem Flussdiagrammblöcken 914, 916 angezeigt ist.
10 zeigt ein Flussdiagramm, das sich auf die Handhabung von asynchronen Ereignissen bezieht, wie bei Block 708 aus 7 angezeigt ist. Wenn sich die Netztopologie auf dem Netz ändert, erzeugt die Netzüberwachungsvorrichtung 306 Ereignisse oder Fallen (SNMP-einheimisch), die einen Objektidentifizierer und Objektänderungsinformationen umfassen. Die Netzüberwachungsvorrichtung 306 kann ferner Ereignisse von anderen Vorrichtungen, wie z. B. einem Router, in dem Netz 118 empfangen.
Bezug nehmend auf 10 werden anfänglich Ereignisse in eine Warteschlange gegeben und in einer Warteschlange (nicht gezeigt) oder einem Akkumulator angesammelt, der einem Topologieverwalter 310 zugeordnet ist, und warten auf die Wiedergewinnung durch den Übersetzer 318. Der Übersetzer 318 liest während jedes Zugriffs einen Stapel von Ereignissen aus dem Topologieverwalter 310.
Als Nächstes, wie bei Block 1004 angezeigt ist, ruft der Übersetzer 318 den Topologieverwalter 310 im Hinblick auf eine Liste aus Topologiedaten auf, die alle Objekte betreffen, die in den Ereignissen identifiziert wurden. Nach dem Empfangen der Topologiedaten überträgt Block 1004 zu Block 1006.
Bei Block 1006 berechnet der Übersetzer 318 die Änderungen, die an den Abbildungsdaten durchgeführt werden sollen, insbesondere an der Netzverwaltungsabbildung 200 (2), basierend auf den Topologiedatenänderungen, die in den Ereignissen angezeigt sind. Block 1006 überträgt zu Block 1008. Bei Block 1008 aktualisiert der Übersetzer 318 die Abbildung 200 (2) durch Anrufen der GUI 322 und Anweisen der GUI 322 über alle Teilabbildungsänderungen (SYMCHANGELIST und NEWSYMLIST, hierin nachfolgend beschrieben), die sich auf alle Objektänderungen beziehen. Diese Transaktion ist vorzugsweise aber nicht notwendigerweise eine Stapelübertragung. Während dieser Stapelübertragungstransaktion identifiziert der Übersetzer 318 jede Teilabbildung, die geändert werden soll, jedes Objekt, das innerhalb einer Teilabbildung geändert werden soll und die bestimmte Änderung, die an dem Objekt ausgeführt werden soll. Eine Objektänderung kann z. B. aber nicht ausschließlich eine Farb-, Positions- oder Verbindungs-Änderung umfassen. Block 1008 überträgt zu Block 1010.
Bei Block 1010 bestimmt der Übersetzer 318, ob ein anderer Stapel aus Ereignissen aus dem Topologieverwalter 310 gelesen werden soll. Wenn ja, dann überträgt Block 1010 zu Block 1002 und der vorangehend beschriebene Prozess wird wiederholt. Wenn nicht, dann wartet die Software bei Block 1010 auf einen anderen Stapel aus Ereignissen.
11 erörtert ein Flussdiagramm, das die Architektur und Funktionalität des Ereignisse-Lesen-Blocks 1002 anzeigt (10). Dieses Flussdiagramm stellt dar, wie der Übersetzer 318 einen Stapel von Ereignissen aus dem Topologieverwalter 310 liest. Wie bei einem Block 1102 angezeigt wird, werden anfänglich Ereignisse aus dem Topologieverwalter 310 angesammelt (in eine Warteschlange gestellt). Ein Zähler TRAPCTR bei Block 1104 wird in Verbindung mit einer Schleife verwendet, um jedes Ereignis von dem Topologieverwalter 310 zu dem Übersetzer 318 zu routen. Bei Block 1106 wird ein Ereignis durch den Übersetzer 318 aus dem Topologieverwalter 310 gelesen. Block 1106 überträgt zu Block 1108, der das Ereignis decodiert. Das Ereignis wird decodiert, um die Art von Ereignis und die zugeordneten Daten zu identifizieren. Es gibt zahlreiche Typen von Ereignissen, und unterschiedliche Typen von Ereignissen weisen unterschiedliche Typen von zugeordneten Daten auf. Genauer gesagt kann ein Ereignis zum Beispiel aber nicht ausschließlich einen neuen Knoten oder eine Knotenzustandsänderung umfassen (z. B. verbunden/zugreifbar oder verbunden/nicht-zugreifbar). Ein Ereignis weist einen Ereignisidentifizierer auf, üblicherweise an dem Anfangsblock, zum Identifizieren der Art des Ereignisses. Ferner enthält das Ereignis in dem Fall eines neuen Knotens einen Objektidentifizierer und eine Adresse. In dem Fall einer Knotenstatusänderung enthält das Ereignis einen Objektidentifizierer, den alten Status und den neuen Status.
Block 1108 überträgt zu Block 1110. Bei Block 1110 werden die decodierten Ereignisdaten (d. h. eine Aufzeichnung) zu einer TLIST hinzugefügt. Bei Block 1112 wird der Zähler TRAPCTR inkrementiert, so dass ein anderes Ereignis bedient wird. Block 1112 überträgt zu Block 1114, der bestimmt, ob weitere Ereignisse zu bedienen vorliegen. Wenn ja, dann überträgt Block 1114 zurück zu Block 1106 und der zuvor erwähnte Prozess wird wiederholt. Wenn nicht, dann kehrt Block 1114 zu Block 1002 zurück (10).
12 zeigt ein Flussdiagramm der Architektur und Funktionalität eines bevorzugten Ausführungsbeispiels zum Implementieren des Objektinformationen-Wiedergewinnen-Blocks 1004 (10). Bezug nehmend auf 12 wird bei Block 1202 die Liste aus Ereignissen, TLIST, gelesen. Block 1202 überträgt zu Block 1204, der eine Schleife beginnt, die verursacht, dass alle Ereignisse innerhalb der TLIST bedient werden.
Bei Block 1204 wird ein Zähler TLISTCTR initialisiert. Block 1204 überträgt zu Block 1206. Bei Block 1206 wird eine einzelne Aufzeichnung aus TLIST gelesen. Aus der Aufzeichnung werden ein Objektidentifizierer und eine Objektänderung bestimmt. Die vorangehenden Daten werden in eine Objektliste platziert, OBJLIST. Als Nächstes, wie bei Block 1208 angezeigt ist, wird der Zähler TLISTCTR so inkrementiert, dass eine andere Aufzeichnung von TLIST bedient wird, falls jegliche verbleiben. Block 1208 überträgt zu Block 1210. Bei Block 1210 wird bestimmt, ob jegliche Ereignisse übrig sind, die bedient werden sollen, durch Vergleichen der Aufzeichnungszählung des Aufzeichnungszählers CTR mit der Gesamtanzahl von bereits verarbeiteten Aufzeichnungen. Wenn ja, dann überträgt Block 1210 zurück zu Block 1206, der beginnt, eine andere Aufzeichnung zu bedienen. Wenn nicht, dann überträgt der Block 1210 zu Block 1212, der eine Anforderung zu dem Topologieverwalter 310 nach einer Stapelübertragung von Objektinformationen sendet, die sich auf alle Objekte innerhalb des Stapels beziehen. Die Objektinformationen für jedes Objekt umfassen einen Objekt-Namen, -Adresse, -Status, -Konnektivitätsinformationen etc.
Als Nächstes, wie bei Block 1214 angezeigt ist, wird die Objektliste OBJLIST gefiltert, um Objekte zu entfernen, die durch die Filter innerhalb der Bibliothek 321 nicht durchgelassen werden. Dieser Prozess wird weiter ausgeführt in 13, wie direkt hierin nachfolgend beschrieben wird.
Wie in 13 angezeigt ist, wird die Objektliste OBJLIST verarbeitet, zuerst durch Initialisieren eines Objektzählers FILTCTR, wie bei Block 1302 angezeigt ist. Block 1302 überträgt zu Block 1304, wo bestimmt wird, ob das bestimmte Objekt OBJLIST[FILTCTR] durch die Filter durchgelassen wird. Wenn bestimmt wird, dass das bestimmte Objekt OBJLIST[FILTCTR] der Filterspezifikation entspricht, dann wird erlaubt, dass das bestimmte Objekt in der Objektliste OBJLIST verbleibt. Wenn bestimmt wird, dass das bestimmte Objekt nicht durch die Filter durchgelassen wird, dann wird das bestimmte Objekt OBJLIST[FILTCTR] aus der Objektliste OBJLIST entfernt, wie bei Block 1306 angezeigt ist.
Als Nächstes wird der Objektzähler inkrementiert, wie in dem Flussdiagrammblock 1308 ausgeführt ist, und eine Bestimmung darüber wird durchgeführt, ob der Objektzähler die Gesamtanzahl von Objekten überschritten hat, wie in dem Flussdiagrammblock 1310 angezeigt ist. Wenn nicht alle Objekte bedient wurden, wie durch den Objektzähler angezeigt wird, dann überträgt der Block 1310 zurück zu Block 1304 und ein anderes Objekt wird bedient. Anderweitig, wenn der Objektzähler CTR die Gesamtanzahl von Objekten überschritten hat, dann überträgt Block 1310 zurück zu Block 1004 (12).
14 ist ein Flussdiagramm, das die Methodik darstellt zum Bestimmen, ob ein Objekt durch die Filterspezifikation durchgelassen wird, wie bei Block 1304 angezeigt wurde (13). Die Methodik aus 14 implementiert ein spezielles Verarbeiten zum Handhaben von Knoten, die Schnittstellen enthalten. Ein Knoten wird durch die Filterspezifikation vielleicht nicht durchgelassen, aber eine Schnittstelle innerhalb eines nicht-zulässigen Knotens kann durch die Filterspezifikation durchgelassen werden. Somit ist die Methodik so entworfen, dass ein Knoten durch die Filterspezifikation durchgelassen wird, wenn seine Felder durch die Filterspezifikation durchgelassen werden oder wenn jegliche Schnittstellen innerhalb des Knotens durch die Filterspezifikation durchgelassen werden.
Anfänglich, wie bei Block 1402 angezeigt ist, wird das bestimmte Objekt OBJLIST[CTR] gegenüber allen Filterausdrücke geprüft, um zu bestimmen, ob das Objekt aus der Objektliste OBJLIST entfernt werden sollte oder gelassen werden sollte, um in der Liste OBJLIST zu verbleiben. Dieses Verfahren wird ausführlicher in 15 geschildert und wird hierin nachfolgend beschrieben.
Block 1402 überträgt zu Block 1404. Bei Block 1404 wird eine Bestimmung darüber durchgeführt, ob das bestimmte Objekt OBJLIST[CTR] durch die Filterspezifikation durchgelassen wurde. Wenn ja, dann überträgt Block 1404 zu Block 1408, der das bestimmte Objekt derart etikettiert, dass es durchgelassen wurde (d. h. zulässig ist), und der Prozess überträgt zurück zu Block 1306 (13). Wenn nicht, dann überträgt Block 1404 zurück zu Block 1406, der eine Abfrage darüber macht, ob das bestimmte Objekt ein Knoten ist.
Wenn das Objekt kein Knoten ist, dann wird das Objekt gelöscht, da es nicht durch die Filterspezifikation durchgelassen wird, wie in dem Flussdiagramm-Block 1410 ausgeführt ist. Im Gegensatz dazu, wenn das Objekt ein Knoten ist, wie bei Block 1406 bestimmt wird, dann überträgt der Block 1406 zu Block 1412, der die Liste aus Schnittstellen innerhalb des Knotens filtert. Dieses Verfahren wurde Bezug nehmend auf 13 hierin vorangehend beschrieben.
Block 1412 überträgt zu Block 1414, der eine Bestimmung darüber trifft, ob die Schnittstellenliste leer ist. Wenn sie leer ist, dann wurden alle Schnittstellen als nichtzulässig erachtet. Wenn sie leer ist, dann überträgt der Block 1414 zu Block 1410 und das Objekt wird aus der Objektliste OBJLIST entfernt. Wenn bei Block 1414 bestimmt wird, dass die Schnittstellenliste nicht leer ist, dann überträgt Block 1414 zu Block 1408 und das Objekt wird schließlich zu der Objektliste OBJLIST hinzugefügt, wenn es durch die Filterspezifikation durchgelassen wird.
15 zeigt ein Flussdiagramm zum Bestimmen, ob ein Objekt entweder als zulässig oder nicht-zulässig klassifiziert werden sollte, gemäß der Filterspezifikation, die durch die Sätze, Filter und Filterausdrücke in den Filterdefinitionsdateien definiert wird, die durch die Filterbibliothek 321 verwendet werden. Die Funktionalität, die in dem Flussdiagramm aus 15 ausgeführt ist, ist bei Block 1402 verkörpert (14). 15 implementiert einen Teil der Grammatik, die in Tabelle A ausgeführt ist. Sie demonstriert, wie Filter für eine einfache Grammatik implementiert werden können. Die vollständige Grammatik ist eine Erweiterung dieses Konzepts und wird bei dem bevorzugten Ausführungsbeispiel unter Verwendung von LEX- und YACC-Werkzeugen implementiert.
Bezug nehmend auf 15 setzt ein Block 1502 eine Variable FILTEREXPR, um eine Liste aus Feldern und Werten anzunehmen. Jedes Feld ist ein Filtername und sein entsprechender Wert kann wahr, falsch, eine ganze Zahl oder eine Zeichenfolge sein.
Block 1502 überträgt zu Block 1504, der einen Objektzähler FIELDCTR zu dem Zweck initialisiert, alle Paarungen der Felder und Werte im Hinblick auf das betreffende Objekt zu betrachten. Block 1504 überträgt in die Schleife, die mit Block 1506 beginnt.
Bei Block 1506 wird eine Variable EXPR gesetzt, um ein Feld und einen Wert anzunehmen. Block 1506 überträgt zu Block 1508, der eine Variable EXPRVAL setzt, um den Wertabschnitt innerhalb der Variablen EXPR anzunehmen. Block 1508 überträgt zu Block 1510.
Bei Block 1510 wird eine Variable OBJVAL gesetzt, um den Wert des Feldes EXPR.FIELD anzunehmen, der sich auf das betreffende Objekt bezieht. Dieser Feldwert wird aus der Topologiedatenbank 314 wiedergewonnen. Block 1510 überträgt zu Block 1512.
Bei Block 1512 wird OBJVAL mit EXPRVAL verglichen, d. h. der Objektwert wird mit dem Wert verglichen, der in der Filterspezifikation spezifiziert ist. Wenn der Objektwert nicht mit dem Filterspezifikationswert übereinstimmt, dann erfüllt das Objekt nicht die Filterspezifikation, wie bei Block 1514 angezeigt wird, und das Flussdiagramm endet. Wenn jedoch der Objektwert mit allen Filterspezifikationswerten übereinstimmt, dann wird schließlich erlaubt, dass das Objekt in der Objektliste OBJLIST verbleibt, wie bei Flussdiagrammblock 1520 angezeigt ist. Bevor Block 1520 erreicht wird, überträgt Block 1512 zu Block 1516, der den Feldzähler FIELDCTR inkrementiert, der bei Block 1504 initialisiert wird. Ferner überträgt Block 1516 zu Block 1518, der bestimmt, ob alle EXPRs betrachtet wurden. Wenn einige verbleiben, überträgt Block 1518 zurück zu Block 1506 und der vorangehende Prozess fährt fort. Wenn keine EXPRs verbleiben, dann überträgt das Flussdiagramm zu Block 1520, der spezifiziert, dass das Objekt die Filterspezifikation erfüllt, und dann endet das Flussdiagramm.
16 zeigt ein Flussdiagramm der Architektur und Funktionalität eines bevorzugten Ausführungsbeispiels des Abbildungsänderungen-Berechnen-Blocks 1006 (10). Bei diesem Flussdiagramm bestimmt der Übersetzer 318, welche Teilabbildungen (2) geändert werden, und die Änderungen, die bewirkt werden sollen, basierend auf den Objektidentifizierern und den Objektänderungen, die vorangehend basierend auf den Ereignissen bestimmt wurden. Bezug nehmend auf 16 initialisiert Block 1601 einen Objektänderungszähler OBJCTR, so dass alle Objektänderungen betrachtet werden. Block 1601 überträgt zu Block 1602. Block 1602 bestimmt einen Teilabbildungsidentifizierer, wobei basierend auf demselben die Teilabbildungen (2) durch die Objektänderung beeinflusst werden, die gegenwärtig betrachtet wird. Block 1602 überträgt zu Block 1604, der bestimmt, ob die beeinflusste Teilabbildung existiert. Wenn die Teilabbildung existiert, dann überträgt Block 1604 zu Block 1610. Wenn die Teilabbildung nicht existiert, dann überträgt Block 1604 zu Block 1606. Block 1606 erzeugt die beeinflusste Teilabbildung in der Abbildung 200 (2). Block 1606 überträgt zu Block 1608.
Bei Block 1608 besetzt der Übersetzer 318 die neu erzeugte Teilabbildung mit Daten aus dem Topologieverwalter 310. Als Nächstes werden bei Block 1610 Teilabbildungsänderungen basierend auf dem aktuellen Ereignis, insbesondere dem Objektidentifizierer und der Objektänderung, berechnet. Die Berechnungen von Block 1610 werden hierin nachfolgend Bezug nehmend auf 17 beschrieben. Block 1610 überträgt zu Block 1616.
Bei Block 1616 wird der Objektänderungszähler OBJCTR inkrementiert, so dass eine andere Objektänderung im Hinblick auf die Teilabbildungen betrachtet wird. Block 1616 überträgt zu Block 1618, der eine Bestimmung darüber durchführt, ob jegliche Objektänderungen verbleiben, die bedient werden müssen. Wenn ja, dann überträgt der Block 1618 zurück zu Block 1602. Wenn nicht, dann endet das Flussdiagramm nach Block 1618.
Somit, am Ende der Operation der Schritte in 16, wurde ein Stapel aus Teilabbildungsidentifizierern mit zugeordneten Teilabbildungsänderungen aus dem Stapel von Objektidentifizierern mit zugeordneten Objektänderungen erzeugt.
Bezug nehmend auf 17, relativ zu den Teilabbildungsänderungsberechnungen von Block 1610 (16), gewinnt Block 1704 Daten, die ein einzelnes Objekt betreffen, aus der Objektliste OBJLIST wieder. Block 1704 überträgt zu Block 1706, der bestimmt, ob der Objekttyp ein Netz ist. Wenn ja, dann überträgt Block 1706 zu Block 1708 (Flussdiagramm in 18), der die Teilabbildungsänderungen berechnet, und dann überträgt Block 1708 zu Block 1722. Wenn nicht, dann überträgt Block 1706 zu Block 1710.
Bei Block 1710 wird eine Bestimmung darüber durchgeführt, ob der Objekttyp ein Segment ist. Wenn ja, dann überträgt Block 1710 zu Block 1712 (Flussdiagramm aus 19), der die Segmentänderungen an den Teilabbildungen berechnet, und dann überträgt Block 1712 zu Block 1722. Wenn nicht, dann überträgt Block 1710 zu Block 1714.
Bei Block 1714 wird eine Bestimmung darüber durchgeführt, ob der Objekttyp ein Knoten ist. Wenn ja, dann überträgt Block 1714 zu Block 1716 (Flussdiagramm aus 20), der die Knotenänderungen für die Teilabbildungen berechnet, und dann überträgt Block 1716 zu Block 1722. Wenn nicht, dann überträgt der Block 1714 zu dem Block 1718.
Bei Block 1718 wird eine Bestimmung darüber durchgeführt, ob der Objekttyp eine Schnittstelle ist. Wenn ja, dann überträgt Block 1718 zu Block 1720 (Flussdiagramm aus 21), der die Schnittstellenänderungen an der Teilabbildung berechnet, und dann überträgt Block 1720 zu Block 1722. Wenn nicht, dann endet das Flussdiagramm.
18 zeigt ein Flussdiagramm der Architektur und Funktionalität eines bevorzugten Ausführungsbeispiels zum Implementieren des Netzänderungs-Blocks 1708 (17). Dieses Flussdiagramm berechnet Änderungen an der Zwischennetz-Teilabbildung 204 (2), die Netze anzeigt. Ferner liegt nur eine einzelne Teilabbildung (mehrere Teilabbildungen sind möglich) auf der Zwischennetzebene bei dem bevorzugten Ausführungsbeispiel vor. Bezug nehmend auf 18 wird bei Block 1802 eine Variable INET gesetzt, um die Inhalte der Zwischennetz-Teilabbildung 204 anzunehmen (2). Die Inhalte umfassen eine Liste aus Netzobjekten und Router-Objekten und eine Liste aus Verbindungen zwischen den Netz- und Router-Objekten. Block 1802 überträgt zu Block 1804. Bei Block 1804 wird eine Variable NETOBJ gesetzt, um den Wert des Objektidentifizierers OBJID anzunehmen. Der OBJID wird aus dem OBJINFO wiedergewonnen. Block 1804 überträgt zu Block 1806. Bei Block 1806 wird eine Bestimmung darüber durchgeführt, ob NETOBJ in INET vorliegt, d. h., ob das zu ändernde Objekt innerhalb der Zwischennetz-Teilabbildung 1804 vorliegt (2). Wenn ja, dann überträgt Block 1806 zu Block 1808, der das Netz, das sich auf das NETOBJ bezieht, zu einer Liste SYMCHANGELIST hinzufügt. Wenn nicht, dann überträgt Block 1806 zu dem Block 1810, der das Netz, das zu dem NETOBJ gehört, zu einer Liste NEWSYMLIST hinzufügen. Die Liste SYMCHANGELIST und NEWSYMLIST wird schließlich durch den Übersetzer 318 zu der GUI während der Stapelübertragung zwischen denselben weitergeleitet.
19 zeigt das Flussdiagramm der Architektur und Funktionalität eines bevorzugten Ausführungsbeispiels zum Implementieren des Segmentänderungsblocks 1712 (17). Bei diesem Flussdiagramm werden Segmentänderungen bestimmt und berechnet. Bezug nehmend auf 19 setzt Block 1902 eine Variable INET, um die Inhalte der Zwischennetz-Teilabbildung 204 anzunehmen (2). Die Inhalte umfassen eine Liste aus Netz- und Router-Objekten und eine Liste aus Verbindungen zwischen den Netz- und Router-Objekten. Block 1902 überträgt zu Block 1904. Bei Block 1904 wird eine Variable SEGOBJ gesetzt, um den aktuellen Objektidentifizierer OBJID anzunehmen, der aus den Objektinformationen OBJINFO wiedergewonnen wird. Block 1904 überträgt zu Block 1906. Bei Block 1906 wird eine Variable NETOBJ zu dem Netzidentifizierer NETID gesetzt, der aus den OBJINFO bestimmt wird. Block 1906 überträgt zu Block 1908. Bei Block 1908 wird eine Bestimmung darüber durchgeführt, ob NETOBJ in dem INET ist, d. h., ob das aktuelle Netz in der aktuellen Zwischennetz-Teilabbildung 204 ist (2). Wenn nicht, dann endet das Flussdiagramm aus 19. Wenn ja, dann überträgt Block 1902 zu 1910. Bei Block 1910 wird eine Variable NET gesetzt, um die Inhalte der Netz-Teilabbildung 206 anzunehmen (2), die zu NETOBJ gehören. Die Inhalte umfassen z. B., sind jedoch nicht beschränkt auf, eine Liste aus Segment- und Verbinder-Objekten und Verbindungen zwischen den Segmenten und Verbindern. Block 1910 überträgt zu Block 1912. Bei Block 1912 wird eine Bestimmung darüber durchgeführt, ob SEGOBJ in dem NET ist (d. h., ist das Segment in der Netz-Teilabbildung?) Wenn ja, dann überträgt der Block 1912 zu dem Block 1914, der das Segment, das zu SEGOBJ gehört, zu SYMCHANGELIST hinzufügt. Anderweitig, wenn nicht, überträgt Block 1912 zu Block 1916, der das Segment, das zu SEGOBJ gehört, zu NEWSYMLIST hinzufügt. Abschließend, nach den Blöcken 1914, 1916, endet das Flussdiagramm von 19 und die Operation kehrt zurück zu 17.
20 zeigt das Flussdiagramm der Architektur und Funktionalität eines bevorzugten Ausführungsbeispiels zum Implementieren des Knotenänderungs-Blocks 1716 (17). Bei dem Flussdiagramm aus 20 werden Knotenänderungen bestimmt und berechnet durch den Übersetzer 318. Wie in 20 gezeigt ist, setzt Block 2002 eine Variable INET, um die Inhalte der Zwischennetz-Teilabbildung 204 anzunehmen (2). Die Inhalte umfassen eine Liste aus Netz- und Router-Objekten und eine Liste aus Verbindungen zwischen den Netz- und Router-Objekten. Block 2002 überträgt zu Block 2004. Bei Block 2004 wird eine Variable NODEOBJ gesetzt, um den Objektidentifizierer OBJID anzunehmen, der in den Objektinformationen OBJINFO enthalten ist. Block 2004 überträgt zu Block 2006. Bei Block 2006 wird eine Variable SEGOBJ gesetzt, um den Segmentidentifizierer SEGID anzunehmen, der innerhalb der OBJINFO enthalten ist. Block 2006 überträgt zu Block 2008. Bei Block 2008 wird eine Variable NETOBJ gesetzt, um den Netzidentifizierer NETID anzunehmen, der innerhalb der OBJINFO enthalten ist. Block 2006 überträgt zu Block 2010. Bei Block 2010 wird eine Bestimmung darüber durchgeführt, ob das NETOBJ in dem INET enthalten ist oder nicht (d. h., ist das Netz in der Internet-Teilabbildung?) Wenn nicht, dann endet das Flussdiagramm. Wenn ja, dann überträgt der Block 2010 zu dem Block 2012. Bei Block 2012 wird die Variable NET gesetzt, um die Inhalte der Netz-Teilabbildung 206 anzunehmen, (2), die zu NETOBJ gehören. Die Inhalte umfassen z. B., sind jedoch nicht beschränkt auf, eine Liste aus Segmenten, Verbindern und Verbindungen zwischen Segmenten und Verbindern. Block 2012 überträgt zu Block 2014. Bei Block 2014 wird eine Anfrage darüber getätigt, ob SEGOBJ in dem NET ist. Wenn nicht, dann endet das Flussdiagramm. Wenn ja, dann überträgt der Block 2014 zu dem Block 2016. Bei Block 2016 wird die Variable SEG gesetzt, um die Inhalte der Segment-Teilabbildung 208 anzunehmen (2), die zu SEGOBJ gehören. Die Inhalte umfassen z. B., sind jedoch nicht beschränkt auf, eine Liste aus Knoten und Verbindungen zwischen den Knoten und dem Netz. Block 2016 überträgt zu Block 2018. Bei Block 2018 wird eine Abfrage darüber durchgeführt, ob NODEOBJ in dem SEG ist, d. h, ob das Knotenobjekt in dem vorliegenden betreffenden Segment ist. Wenn ja, dann überträgt der Block 2018 zu Block 2020, der den Knoten, der zu NODEOBJ gehört, zu SYMCHANGELIST hinzufügt, und dann endet das Flussdiagramm. Ansonsten, wenn nicht, überträgt der Block 2018 zu dem Block 2022, was den Knoten, der zu NODEOBJ gehört, zu NEWSYMLIST hinzufügt, und dann endet das Flussdiagramm.
21A bis 21C zeigen zusammen ein Flussdiagramm der Architektur und Funktionalität des bevorzugten Ausführungsbeispiels zum Implementieren des Schnittstelle-Ändern-Blocks 1720 (17). Bei diesem Flussdiagramm werden Schnittstellenänderungen in den Teilabbildungen bestimmt und berechnet durch den Übersetzer 318 (13). Bezug nehmend auf 21A setzt ein Block 2102 eine Variable INET, um die Inhalte der Zwischennetz-Teilabbildung 204 anzunehmen (2), die gegenwärtig betroffen ist. Die Inhalte umfassen eine Liste aus Netzwerken, Routern und Verbindungen. Block 2102 überträgt zu Block 2104. Bei Block 2104 wird eine Variable IFOBJ gesetzt, um die OBJID anzunehmen, die in den OBJINFO enthalten ist. Der Block 2104 überträgt zu dem Block 2106. Bei Block 2106 wird die Variable NODEOBJ gesetzt, um die NODEID anzunehmen, die in den OBJINFO enthalten ist. Block 2106 überträgt zu Block 2108. Bei Block 2108 wird die Variable SEGOBJ gesetzt, um die SEGID anzunehmen, die in den OBJINFO enthalten ist. Block 2108 überträgt zu Block 2110. Bei Block 2110 wird eine Variable NETOBJ gesetzt, um die NETID anzunehmen, die in den OBJINFO enthalten ist. Nach Block 2110 wurde der Initialisierungsprozess abgeschlossen und Block 2110 überträgt zu Block 2112.
Bei Block 2112 wird eine Bestimmung darüber durchgeführt, ob das NETOBJ in dem INET vorliegt, d. h., ob das Netzobjekt in der aktuellen Zwischennetz-Teilabbildung 204 vorliegt (2). Wenn nicht, endet das Flussdiagramm, wie in 21A gezeigt ist. Wenn ja, dann überträgt der Block 2112 zu Block 1214. Bei Block 2114 wird eine Bestimmung darüber durchgeführt, ob NODEOBJ in dem INET ist, d. h., ob das Knotenobjekt in der Zwischennetz-Teilabbildung 204 ist (2). Wenn nicht, dann überträgt der Block 2114 zu dem Block 2122. Wenn ja, dann überträgt der Block 2114 zu dem Block 2116.
Bei Block 2116 wird eine Abfrage darüber durchgeführt, ob IFOBJ in INET vorhanden ist. Wenn ja, dann überträgt der Block 2116 zu dem Block 2118, was die Schnittstelle, die zu IFOBJ gehört, zu der SYMCHANGELIST hinzufügt. Wenn nicht, dann überträgt der Block 2116 zu dem Block 2120, was die Schnittstelle, die zu IFOBJ gehört (zwischen Knotenobjekt und Netzobjekt) zu NEWSYMLIST hinzufügt.
Bei Block 2122 wird die Variable NET gesetzt, um die Inhalte der Netz-Teilabbildung 206 anzunehmen (2). Die Inhalte umfassen z. B., sind jedoch nicht beschränkt auf Segmente, Verbindungen etc. Block 2122 überträgt Block 2124 aus 21B.
Bezug nehmend auf 21B wird bei Block 2124 eine Bestimmung darüber durchgeführt, ob SEGOBJ in dem NET ist, d. h., ob das Segmentobjekt innerhalb der Netz-Teilabbildung 206 ist (2). Wenn nicht, dann endet das Flussdiagramm. Wenn ja, dann überträgt der Block 2124 zu dem Block 2126.
Bei Block 2126 wird eine Bestimmung darüber durchgeführt, ob NODEOJ in dem NET ist, d. h., ob das Knotenobjekt in der Netz-Teilabbildung 206 ist (2). Wenn nicht, dann überträgt das Flussdiagramm zu Block 2134. Wenn ja, dann überträgt der Block 2126 zu dem Block 2128.
Bei Block 2128 wird eine Abfrage darüber durchgeführt, ob IFOBJ innerhalb von NET ist, d. h., ob das Schnittstellenobjekt innerhalb der Netz-Teilabbildung 206 ist (2). Wenn ja, dann überträgt der Block 2128 zu Block 2130, was die Schnittstelle, die zu IFOBJ gehört, zu SYMCHANGELIST hinzufügt. Wenn nicht, dann überträgt der Block 2128 zu dem Block 2132, was die Schnittstelle, die zu IFOBJ gehört (die zwischen einem Knotenobjekt und einem Segmentobjekt ist), zu NEWSYMLIST hinzufügt. Die Blöcke 2130, 2132 übertragen zu dem Block 2134, wie in 21B gezeigt ist.
Bei Block 2134 wird die Variable SEG gesetzt, um die Inhalte der Segment-Teilabbildung 208 anzunehmen (2). Die Inhalte umfassen z. B., sind jedoch nicht beschränkt auf Knoten und Verbindungen. Block 2134 überträgt zu Block 2136.
Bei Block 2136 wird eine Bestimmung darüber durchgeführt, ob NODEOBJ in SEG ist, d. h., ob das Knotenobjekt innerhalb der Segment-Teilabbildung 208 ist (2). Wenn nicht, dann überträgt das Flussdiagramm zu Block 2146 aus 21B. Wenn ja, dann überträgt der Block 2136 zu Block 2138.
Bei Block 2138 wird eine Bestimmung darüber durchgeführt, ob IFOBJ innerhalb von SEG ist, d. h., ob das Schnittstellenobjekt innerhalb der Segment-Teilabbildung 208 ist (2). Wenn ja, dann überträgt der Block 2138 zu dem Block 2142, was die Schnittstelle, die sich auf IFOBJ bezieht, zu SYMCHANGELIST hinzufügt. Wenn nicht, dann überträgt der Block 2138 zu dem Block 2144, was die Schnittstelle, die zu IFOBJ gehört, zu NEWSYMLIST hinzufügt. Die Blöcke 2142 und 2144 werden zu dem Block 2146 aus 21C übertragen.
Bezug nehmend auf 21C, wird bei Block 2146 die Variable NODE gesetzt, um die Inhalte der Knoten-Teilabbildung 210 anzunehmen (2). Die Inhalte umfassen Schnittstellenobjekte. Block 2146 überträgt zu dem Block 2148.
Bei Block 2148 wird eine Bestimmung darüber durchgeführt, ob IFOBJ innerhalb von NODE ist, d. h., ob das Schnittstellenobjekt innerhalb der Knoten-Teilabbildung 210 ist (2). Wenn ja, dann wird die Schnittstelle, die zu IFOBJ gehört, zu SYMCHANGELIST hinzufügt, wie bei Block 2150 angezeigt wird. Wenn nicht, dann überträgt der Block 2148 zu dem Block 2152, was die Schnittstelle, die zu IFOBJ gehört, zu NEWSYMLIST hinzufügt. Abschließend, nach den Blöcken 2150, 2152, endet das Flussdiagramm, das kollektiv in 21A–21C enthalten ist.
22 zeigt ein Flussdiagramm der Architektur und Funktionalität eines bevorzugten Ausführungsbeispiels zum Implementieren des Abbildung-Aktualisieren-Blocks 1008 (10). Bei diesem Flussdiagramm wird eine Stapelübertragung einer Änderung durch den Übersetzer 318 zu der GUI 322 gesendet. Bezug nehmend auf 22 überträgt bei Block 2202 der Übersetzer 318 die NEWSYMLIST zu der GUI 322, und bei Block 2204 überträgt der Übersetzer 318 die SYMCHANGELIST zu der GUI 322. Nach Block 2204 endet das Flussdiagramm von 22 und die Operation kehrt zurück zu Block 1010 (10).
23 stellt ein Auf-Befehl-Teilabbildungsmodul dar, das innerhalb der GUI 322 enthalten ist (3). Dieses Flussdiagramm implementiert die Benutzerschnittstelle zu den verschiedenen Teilabbildungen der 200 (2). Bezug nehmend auf 23 überwacht bei einem Block 2302 die GUI 322 die Eingabevorrichtungen, die mit der Verwaltungsstation 100 verbunden sind (1), z. B. die Eingabevorrichtung 106. Wenn der Benutzer der Verwaltungsstation 100 die Verwaltungsstation 100 über die Eingabevorrichtung 106 oder eine andere Eingabevorrichtung auffordert, ein Objekt auf der Anzeige 108 zu explodieren, überträgt der Block 2302 aus 23 zu dem Block 2304, um die Benutzeranforderung zu verarbeiten. Bei Block 2304 wird eine Bestimmung darüber durchgeführt, ob die Tochter-Teilabbildung in der 200 enthalten ist (2). Wenn ja, dann überträgt der Block 2304 zu dem Block 2308. Wenn nicht, dann überträgt der Block 2304 zu dem Block 2306, der die Teilabbildung erzeugt und besetzt. Die GUI 322 besetzt die Teilabbildung durch Auffordern des Übersetzers 318, eine Teilabbildung zu erzeugen und zu besetzen, basierend auf Topologiedaten, die aus dem Topologieverwalter 310 wiedergewonnen werden. Ferner überträgt der Block 2306 zu dem Block 2308, der die Tochter-Teilabbildung öffnet und die Tochter-Teilabbildung auf der Anzeige 108 für den Benutzer anzeigt.
Als Zusammenfassung der detaillierten Beschreibung sollte darauf hingewiesen werden, dass es für Fachleute auf dem Gebiet offensichtlich sein wird, dass viele Abweichungen und Modifikationen an den bevorzugten Ausführungsbeispielen durchgeführt werden können, ohne wesentlich von den Prinzipien der vorliegenden Erfindung abzuweichen. Alle derartigen Abweichungen und Modifikationen sollen hierin innerhalb des Schutzbereichs der vorliegenden Erfindung umfasst sein, wie in den nachfolgenden Ansprüchen ausgeführt ist. Ferner sollen in den hierin nachfolgenden Ansprüchen die Strukturen, Materialien, Handlungen und Entsprechungen aller Einrichtung-Plus-Funktion-Elemente oder aller Schritt-Plus-Funktion-Elemente jegliche und alle Strukturen, Materialien oder Handlungen zum Ausführen der spezifischen Funktionen in Kombination mit den anderen beanspruchten Elementen umfassen.

Claims

Ein Verwaltungssystem (100) zum effizienten Entdecken und Anzeigen von Vorrichtungen und Verbindungen eines Netzwerks (118), das folgende Merkmale aufweist: einen Prozessor (102); einen Speicher (110); eine Anzeige (108); eine Schnittstelle (104), die den Prozessor (102), den Speicher (110) und die Anzeige (108) verbindet und in der Lage ist, eine Verbindung mit dem Netzwerk (118) herzustellen; einen Entdeckungsmechanismus (302), der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der Entdeckungsmechanismus (302) konfiguriert ist, um Topologiedaten (316) zu entdecken und zu speichern, die die Vorrichtungen und die Verbindungen des Netzwerks (118) anzeigen; einen Entwurfsmechanismus (304), der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der Entwurfsmechanismus (304) konfiguriert ist, um die Topologiedaten (316) von dem Entdeckungsmechanismus (302) zu empfangen, wobei der Entwurfsmechanismus (304) konfiguriert ist, um die Anzeige (108) basierend auf den Topologiedaten (316) zu treiben; und gekennzeichnet durch einen Filtermechanismus (103), der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der Filtermechanismus konfiguriert ist, um zu verhindern, dass nicht-zulässige Objekte von dem Netzwerk (118) zu dem Entdeckungsmechanismus (302) durchgelassen werden.
Das System (100) gemäß Anspruch 1, das ferner einen zweiten Filtermechanismus (103) aufweist, der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der Filter-Mechanismus (103) konfiguriert ist, um Objekte innerhalb der Topologiedaten (316) zu filtern, die von dem Entdeckungsmechanismus (302) zu dem Entwurfsmechanismus (304) durchgelassen werden.
Das System (100) gemäß Anspruch 1, das ferner folgende Merkmale aufweist: einen zweiten Entdeckungsmechanismus (302), der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der zweite Entdeckungsmechanismus (302) konfiguriert ist, um Topologiedaten (316) zu entdecken und zu speichern, die die Vorrichtungen und die Verbindungen des Netzwerks (118) anzeigen; und einen zweiten Filtermechanismus (103), der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der zweite Filtermechanismus (103) konfiguriert ist, um Objekte innerhalb der Topologiedaten (316) zu filtern, die zwischen dem ersten und dem zweiten Entdeckungsmechanismus (302) durchgelassen werden.
Das System (100) gemäß Anspruch 3, das ferner einen dritten Filtermechanismus (103) aufweist, der durch Software implementiert ist, die in dem Speicher (110) gespeichert ist, zum Treiben des Prozessors (102), wobei der dritte Filtermechanismus (103) konfiguriert ist, um Objekte innerhalb der Topologiedaten (316) zu filtern, die von dem ersten und zweiten Entdeckungsmechanismus (302) zu dem Entwurfsmechanismus (304) durchgelassen werden.
Das System (100) gemäß Anspruch 4, das ferner eine Bibliothek (321) in Kommunikation mit dem ersten, zweiten und dritten Filtermechanismus (103) aufweist, wobei die Bibliothek (321) konfiguriert ist, um zu spezifizieren, welche der Objekte durch die Filtermechanismen (103) kommuniziert werden.
Das System (100) gemäß Anspruch 1, das ferner eine Bibliothek (321) aufweist, die dem Filtermechanismus (103) zugeordnet ist, wobei die Bibliothek (321) konfiguriert ist, um zu spezifizieren, welche der Objekte von dem Netz (118) zu dem Entdeckungsmechanismus (302) kommuniziert werden.
Das System (100) gemäß Anspruch 1, bei dem der Filter-Mechanismus (103) einen Boolschen Ausdruck umfasst zum Bestimmen, welche der Objekte innerhalb der Topologiedaten (316) von dem Netz (118) zu dem Entdeckungsmechanismus (302) durchgelassen werden.
Ein Filterverfahren (101) zum Entdecken und Anzeigen von Vorrichtungen und Verbindungen eines Netzes (118), das folgende Schritte aufweist: Vergleichen von Objekten, die von dem Netz empfangen werden, mit einer vordefinierten Bibliothek (321), um zulässige Objekte und nicht-zulässige Objekte zu bestimmen; Speichern der zulässigen Objekte als Topologiedaten (316), die die Vorrichtungen und die Verbindungen des Netzes (118) anzeigen; Verhindern, dass nicht-zulässige Objekte als Topologiedaten (316) gespeichert werden; und Erzeugen von Abbildungsdaten (328) aus den Topologiedaten (316) und Anzeigen der Abbildungsdaten (328).
Ein computerlesbares Medium für eine Verwaltungsstation (100), das ein Programm aufweist zum Entdecken und Anzeigen von Vorrichtungen und Verbindungen eines Netzes (118), wobei das Programm folgende Merkmale aufweist: einen Entdeckungsmechanismus (302), der konfiguriert ist, um Topologiedaten (316) zu entdecken und zu speichern, die die Vorrichtungen und die Verbindungen des Netzes (118) anzeigen; einen Entwurfsmechanismus (304), der konfiguriert ist, um die Topologiedaten (316) von dem Entdeckungsmechanismus (302) zu empfangen, wobei der Entwurfsmechanismus (304) konfiguriert ist, um die Anzeige (108) basierend auf den Topologiedaten (316) zu treiben; und gekennzeichnet durch einen Filtermechanismus (103), der konfiguriert ist, um zu verhindern, dass nicht-zulässige Objekte von dem Netz (118) zu dem Entdeckungsmechanismus (302) durchgelassen werden.