DE68928016T2

DE68928016T2 - Monitor für zustand und topologie eines fernmeldenetzes

Info

Publication number: DE68928016T2
Application number: DE68928016T
Authority: DE
Inventors: Paul Alvik; William Bishop; Ronald Dupont; Karen Forkish; Michael Gannon; Christopher Helgeson; Sandra Mumaw; Tim Radzykewycz; Paul Robins; Seck-Eng Tan
Original assignee: Network Equipment Technologies Inc
Current assignee: Network Equipment Technologies Inc
Priority date: 1988-01-29
Filing date: 1989-01-27
Publication date: 1997-12-11
Anticipated expiration: 2009-01-28
Also published as: AU3184989A; EP0398987A4; EP0398987A1; JPH03503588A; DE68928016D1; AU645000B2; CA1313561C; JP2758054B2; ATE152566T1; EP0398987B1; WO1989007377A1

Description

HINTERGRUND DER ERFINDUNG

Gebiet der Erfindung

Die vorliegende Erfindung betrifft eine Vorrichtung, um den Status eines Kommunikationsnetzes zu überwachen, und genauer um einer Bedienungsperson in graphischer Form ein Netzwerk betreffende Statusinformationen zu präsentieren.

Beschreibung des verwandten Standes der Technik

Grobe Kommunikationsnetzwerke bestehen aus vielen Vermittlungsknoten, die durch Kommunikations-Verbindungsleitungen untereinander verbunden sind. Die Vermittlungsknoten führen komplexe Kommunikationsaufgaben aus, wie z.B. Rufweiterleitung, Verbindungskontrolle und Datenkompression. Verschiedene Vermittlungen innerhalb des Netzwerkes führen in Abhängigkeit von der Art und Weise, in der die Knoten durch den Anwender konfiguriert wurden, innerhalb des Netzwerkes verschiedene Sätze dieser Kommunikationsaufgaben aus. Darüber hinaus sind die die Knoten miteinander verbindenden Verbindungsleitungen von verschiedensten Typen mit jeweils eigenen Eigenschaften, wie z.B. satelliten- oder erdgebundene Leitungen.
Die Vermittlungen und Verbindungsleitungen sind häufig durch einen gewissen Abstand geographisch voneinander getrennt. Wenn Vermittlungen verändert werden, neue Eigenschaften hinzugefügt oder Vermittlungen entfernt werden, kann die Konfiguration des Netzwerkes sich an Stellen weit entfernt von der Bedienungsperson merklich verändern. Darüber hinaus leiden die verteilten Vermittlungsknoten unter Alarmzuständen, wie z.B. dem Zusammenbruch von funktionalen Modulen oder einem Versagen von Kommunikationsprotokollen in Echtzeit, die einer Bedienungsperson des Systems mitgeteilt werden müssen. Ferner können Verbindungsleitungen von geographisch getrennten Stellen aus in Echtzeit hinzugefügt, entfernt oder verändert werden.
Eine Bedienungsperson, die Netzwerkdiagnosen oder Aufgaben der Fehlersuche durchführt, mub wirksamen Zugriff zu aktuellen Statusinformationen haben, die ein Netzwerk betreffen. Insbesondere sind die Topologie des Netzwerkes, Alarmzustände und die Konfiguration der verschiedenen Knoten und Verbindungsleitungen in dem Netzwerk kritische Informationen.
Die Aufgabe, Statusinformationen von einem groben Kommunikationsnetzwerk rechtzeitig zu erfassen und diese Information einer Bedienungsperson in verwendbarer Form zu präsentieren, kann sehr komplex sein. Diese Überwachungsaufgabe sollte vorzugsweise so wenig wie möglich mit der auf dem Netzwerk erfolgenden Kommunikationsaufgabe interferieren und die Kommunikationskanäle nicht überladen, wenn Überwachungsinformationen zu einer einzigen überwachungsstation in dem Netzwerk übermittelt werden. Darüber hinaus ist es bevorzugt, wenn die Überwachungsvorrichtung ohne umfangreiche Änderungen an Kommunikationsaufgaben implementiert wird, die in dem Netzwerk ablaufen, um die Überwachungs funktion zu unterstützen.
Die US-A-4,464,543 beschreibt ein Telekommunikationsnetzwerk mit einer Vielzahl von Tandemknotenvermittlungen, die durch Anschlußleitungen miteinander verbunden sind. Das System gemäß dieser Veröffentlichung offenbart eine Vorrichtung, durch die Fehlermitteilungen etc. von einer zentralen Stelle überwacht werden können, indem ein System von zusätzlichen Kommunikationsleitungen verwendet wird.
Die vorliegende Erfindung schafft eine Vorrichtung zum Erfassen und Anzeigen von Informationen, die einen Status eines Kommunikationsnetzwerkes betreffen, ohne daß die Kommunikationskanäle in dem Netzwerk überladen werden. Darüber hinaus wird die Information einer Bedienungsperson auf neue und nützliche Weise angezeigt. Schließlich wird die Vorrichtung mit minimalem Einfluß auf das Design der laufenden Kommunikationsaufgaben in dem Netzwerk implementiert.
Genauer gesagt schafft die Erfindung eine Vorrichtung zum Erfassen und Anzeigen von Informationen, die einen Status eines Kommunikationsnetzes betreffen, wobei das Netzwerk eine Vielzahl von verteilten Vermittlungsknoten und eine Vielzahl von Verbindungsleitungen umfaßt, die die Vermittlungsknoten miteinander verbinden, wobei jeder von den Vermittlungsknoten Aufgaben ausführt, zu denen Kommunikationsfunktionen, Verwaltung eines Ereignisprotokolles, das Ereignissätze für den Vermittlungsknoten auflistet, und Verwaltung einer Konfigurationsdatenbank zählen, die eine Konfiguration für den Vermittlungsknoten definiert, wobei die Vorrichtung aufweist:
einen Monitorknoten, der an einen ersten Vermittlungsknoten aus der Vielzahl von verteilten Vermittlungsknoten gekoppelt ist, mit einer Schnittstelle für Bedienereingaben, ersten Mitteln zur Verwaltung von Topologiedaten, die die Topologie des Netzwerkes anzeigen, und zur Unterstützung eines ersten Protokolls mit dem ersten Vermittlungsknoten, zweiten Mitteln zur Verwaltung einer Monitorliste von Ereignissätzen, die in die Ereignisprotokolle der Vermittlungsknoten in dem Netzwerk eingetragen sind, und zur Unterstützung eines zweiten Protokolls durch das Netzwerk mit der Vielzahl von verteilten Vermittlungsknoten, dritten Mitteln zur Verwaltung einer Monitordatenbank, die die Konfiguration der Vermittlungsknoten anzeigt, wie sie in den Konfigurationsdatenbänken der Vermittlungsknoten in dem Netzwerk eingetragen sind, und zur Unterstützung eines dritten Protokolls durch das Netzwerk mit der Vielzahl von verteilten Vermittlungsknoten, und mit Anzeigemitteln, die auf Bedienereingaben ansprechen, die einen gegenständlichen Vermittlungsknoten in dem Netzwerk identifizieren, und die an die Monitordatenbank, die Monitorliste von Ereignissätzen und die Topologiedaten gekoppelt sind, um dem Bediener Konfigurationsdaten über den gegenständlichen Vermittlungsknoten, die Netzwerktopologie und die Ereignissätze anzuzeigen;
Mittel an dem ersten Vermittlungsknoten, um die Topologiedaten in Abhängigkeit von den an der Vielzahl von Vermittlungsknoten durchgeführten Kommunikationsfunktionen zu erzeugen, und um die Topologiedaten in Abhängigkeit von Nachrichten gemäß dem ersten Protokoll an die ersten Mittel zu senden;
Mittel an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an das Vermittlungsknoten-Ereignisprotokoll des entsprechenden Vermittlungsknotens gekoppelt sind und auf Nachrichten gemäß dem zweiten Protokoll ansprechen, um Daten, die Ereignissätze anzeigen, die in das Ereignisprotokoll des Vermittlungsknotens eingetragen sind, zu verpacken und zu den zweiten Mitteln zu senden, wobei die Daten von jedem aus der Vielzahl von Vermittlungsknoten außer von dem ersten Vermittlungsknoten durch das Netzwerk zu dem ersten Vermittlungsknoten und durch den ersten Vermittlungsknoten zu den zweiten Mitteln gelangen; und
Mittel an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an die Vermittlungsknoten-Konfigurationsdatenbank an dem entsprechenden Vermittlungsknoten gekoppelt sind und auf Nachrichten gemäß dem dritten Protokoll ansprechen, um Daten zu verpacken und von der Vermittlungsknoten-Konfigurationsdatenbank zu den dritten Mitteln zu senden, wobei die Daten von jedem aus der Vielzahl von Vermittlungsknoten außer von dem ersten Vermittlungsknoten durch das Netzwerk zu dem ersten Vermittlungsknoten und durch den ersten Vermittlungsknoten zu den dritten Mitteln gelangen.
In bevorzugten Ausführungsbeispielen sind oder beinhalten die aufgelisteten Ereignisprotokolle Alarmzustände, wobei das Ereignisprotokoll eine Knotenliste von oder mit Alarmzuständen für die Vermittlungsknoten ist.
Zusätzliche Merkmale der vorliegenden Erfindung ergeben sich aus einer Durchsicht der folgenden Zeichnung, ausführlichen Beschreibung und Ansprüche.

KURZE BESCHREIBUNG DER FIGUREN

Fig. 1 ist ein Blockdiagramm, das einen Systemüberblick gemäß der vorliegenden Erfindung liefert.
Fig. 2 ist ein Diagramm der Mehrfachfenster auf der Anzeige des Monitorknotens gemäß der vorliegenden Erfindung.
Fig. 3 ist ein Blockdiagramm des Monitorknotens gemäß der vorliegenden Erfindung.
Fig. 4 ist ein Blockdiagramm eines Vermittlungsknotens gemäß der vorliegenden Erfindung.
Fig. 5 ist ein Blockdiagramm, das ein System illustriert, das eine Vielzahl von Monitorknoten gemäß der vorliegenden Erfindung beinhaltet.
Fig. 6 ist ein Systemüberblick für die Ereignisprotokollanwendung, die auf den Monitorknoten und den Vermittlungsknoten verteilt ist.
Fig. 7 ist ein Schnappschuß des Ereignisprotokolls auf den Vermittlungsknoten vor und nach einem Umbruch.
Fig. 8 illustriert den Nachrichten-Zwischenspeicher und die Kompression von Daten in dem Zwischenspeicher, die bei der Ereignisanwendung an dem Vermittlungsknoten erfolgt.
Fig. 9 illustriert die Nachrichtenstruktur für die "Eröffne Sitzung"-Nachricht in der Ereignisanwendung.
Fig. 10 illustriert die "Bestätige" Nachrichtsstruktur für die Ereignis anwendung.
Fig. 11 illustriert die "Nächstes Paket"-Nachrichtenstruktur für die Ereignisanwendung.
Fig. 12 illustriert die "Schließe Sitzung"-Nachrichtenstruktur für die Ereignisanwendung.
Fig. 13 illustriert die "Ereignispaket"-Nachrichtenstruktur für die Ereignisanwendung.
Fig. 14 ist ein Übergangszustandsdiagramm für die an dem Monitorknoten laufende Ereignisanwendung.
Fig. 15 ist ein Übergangszustandsdiagramm für den Teil der Ereignisanwendung, der auf den Vermittlungsknoten läuft.
Fig. 16 illustriert das Format zum Speichern von Ereignissätzen an dem Vermittlungsknoten und an dem Monitorknoten.
Fig. 17 ist ein Datenflußdiagramm für die Alarmtabellenanwendung an dem Monitorknoten und an der Vielzahl von Vermittlungs knoten.
Fig. 18 illustriert das Protokoll der Initialisierung der Sitzung zwischen der Alarmtabellenanwendung an dem Monitorknoten und der entsprechenden Anwendung an den verteilten Vermittlungsknoten.
Fig. 19 illustriert das normale Protokoll der Sitzung zwischen der Alarmtabellenanwendung an dem Monitorknoten und der entsprechenden Anwendung an den verteilten Vermittlungsknoten.
Fig. 20 illustriert ein Rücksetz-Protokoll zwischen der Alarmtabellenanwendung an dem Monitorknoten und der entsprechenden Anwendung an dem Vermittlungsknoten.
Fig. 21 ist ein Datenflußdiagramm für die Datenbankanwendung.
Fig. 22 illustriert die Datenstrukturen an dem Monitorknoten für die Datenbankanwendung.
Fig. 23 illustriert Datenstrukturen an den verteilten Vermittlungsknoten für die Datenbankanwendung.
Fig. 24 und 25 illustrieren das Protokoll für den Nachrichtenaustausch bei normalem Betrieb zwischen der an dem Monitorknoten laufenden DBA und der an den Vermittlungsknoten laufenden DBAPE.
Fig. 26 und 27 illustrieren das Protokoll für den Nachrichtenaustausch bei verlorenen Nachrichten zwischen der an dem Monitorknoten laufenden DBA und der an den Vermittlungsknoten laufenden DBAPE.
Fig. 28 und 29 illustrieren das Protokoll für den Nachrichtenaustausch bei außer Synchronisation befindlichen Nachrichten zwischen der an dem Monitorknoten laufenden DBA und der an den Vermittlungsknoten laufenden DBAPE.
Fig. 30 illustriert das Protokoll für den Nachrichtenaustausch bei pathologischem Versagen zwischen der an dem Monitorknoten laufenden DBA und der an den Vermittlungsknoten laufenden DBAPE.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Mit Bezugnahme auf die Figuren wird eine ausführliche Beschreibung von bevorzugten Ausführungsbeispielen der vorliegenden Erfindung geliefert.
Im einzelnen wird unter Bezugnahme auf die Fig. 1 bis 5 eine Beschreibung der Systemebene geliefert. Nach der Beschreibung der Systemebene werden die verteilten Anwendungen beschrieben, die in dem bevorzugten Ausführungsbeispiel laufen, das zu der vorliegenden Erfindung gehört.

I. Systemüberblick

Fig. 1 illustriert das Kommunikationssystem, in dem die vorliegende Erfindung arbeitet. Das Kommunikationssystem umfaßt insbesondere eine Vielzahl von verteilten Vermittlungsknoten 1, 2, 3, 4, sowie die Integrated Digital Network Exchanges (IDNX), die durch Network Equipment Technologies, Inc., 400 Penobscot Drive, Redwood City, CA 94063, geleitet wird. Die Vermittlungsknoten sind durch Verbindungsleitungen 5, 6, 7 miteinander und über Leitungen 8, 9, 10 mit anderen Vermittlungsknoten in dem Netzwerk verbunden.
Der Vermittlungsknoten 1 ist über eine Verbindungsleitung 12 mit einem Monitorknoten 11 verbunden. An den Monitorknoten 11 ist ein Bedienerinterface 13 gekoppelt, das für den Zugriff auf Konfigurationsprogramme verwendet wird, die in den Vermittlungsknoten in dem Netzwerk laufen, und das mit dem Vermittlungsknoten 1 über eine Verbindungsleitung 14 kommuniziert. Der Monitorknoten zeigt Statusinformationen an, die die Vielzahl von verteilten Vermittlungsknoten und Verbindungsleitungen in dem Netzwerk betreffen. Die Bedienungsperson nutzt die an dem Knoten 11 angezeigten Informationen, bedient die Konfigurationsprogramme durch das Interface 13, um Diagnosefunktionen, Fehlersuche und Konfigurationsaufgaben in dem gesamten Netzwerk durchzuführen.

II. Anzeigefenster

Der Monitorknoten 11 beinhaltet eine Anzeige, wie z.B. einen Monitor, der mit einer Sun Microsystems, Inc., Workstation versehen ist, die eine Vielzahl von Fenstern beinhaltet, wie es in Fig. 2 dargestellt ist. Das erste Fenster 20 auf der Anzeige ist eine graphische Wiedergabe der Topologie des Netzwerkes für die Bedienungsperson. Wie es in Fig. 2 dargestellt ist, beinhaltet das Netzwerk eine Vielzahl von verteilten Vermittlungsknoten 21, die geographisch über die kontinentalen Vereinigten Staaten verteilt sind. Das Fenster 20 zeigt eine Karte der Vereinigten Staaten mit Indikatoren für die Orte der Vermittlungsknoten und Leitungen, die die Verbindungen zwischen diesen anzeigen. Darüber hinaus beinhaltet das Fenster 20 hervorhebende Merkmale für bestimmte Knoten, wie es bei 22 dargestellt ist, um an dem Knoten stattfindende Alarmzustände anzuzeigen. In dem bevorzugten Ausführungsbeispiel werden Knoten unter Verwendung von Farbe hervorgehoben, wobei eine Legende 29 vorgesehen ist, um die Interpretation zu erleichtern. Die Legende 29 beinhaltet ferner informationenidentifizierende Symbole, um Netzwerkkomponenten graphisch darzustellen.
Ein zweites Fenster 23 auf der Anzeige illustriert eine Konfiguration eines gegenständlichen Knotens, nimlich Knoten X. Über das Benutzerinterface kann die Bedienungsperson einen gegenständlichen Knoten bestimmen, indem er z.B. eine Maus- und Cursortechnik verwendet, die üblicherweise bei Anzeigesystemen mit Fenstertechnik verwendet werden. Die Maus könnte verwendet werden, um den Cursor zu einem gegenständlichen Knoten auf der Netzwerktopologiekarte in Fenster 20 zu bewegen. Indem ein Schalter an der Maus gedrückt wird, kann die ausgewählte Knotenkonfiguration hervorgebracht und in dem Fenster 23 angezeigt werden. Die Knotenkonfiguration beinhaltet eine graphische Anzeige 25, die funktionale Elemente CRD1, CRD2. . . des Knotens illustriert. Darüber hinaus kann eine Textinformation 26, die Karten und Verbindungen in dem Netzwerk betrifft, unter Verwendung einer Maus und eines Fenstertechnikalgorithmus aufgelistet werden.
Ein drittes Fenster 27 auf der Anzeige zeigt eine Liste von Alarmzuständen, die im ganzen Netzwerk auftreten.
Ein viertes Fenster 28 auf der Anzeige wird als interaktives Benutzerinterfacefenster zu Vermittlungskonfigurationstools, Vermittlungsdiagnostiken und dgl. verwendet, wozu auch das Bedienerinterface 13 dienen kann. Dieser Bereich auf dem Schirm wird ebenfalls für Konfigurationsprogramme für den Monitorknoten verwendet.
Ein fünftes Fenster 29 auf der Anzeige liefert einen auf ikonischen Zeichen basierenden Menüservice für die Bedienungsperson.
Ein zusätzliches Textfenster 30 zeigt Monitorsystemnachrichten an, wie z.B. den Status von verschiedenen Monitoranwendungen.
Dieses Anzeigeformat liefert in einer verwendbaren Form Informationen, die den Status und Alarwzustände in dem Netzwerk betreffen.

III. Überblick über den Monitorknoten

Fig. 3 ist ein Blockdiagramm von Anwendungen, die gemäß der vorliegenden Erfindung an dem Monitorknoten laufen. Wie es oben bereits erwähnt wurde, beinhaltet der Monitorknoten einen Anzeigeprozessor 33, der die unter Bezugnahme auf Fig. 2 beschriebene Anzeige unterstützt. Informationen werden dem Anzeigeprozessor 33 von einer Alarmtabellenanwendung 34, einer Topologiedatenanwendung 35 und einer Datenbankanwendung 36 zugeführt. Der Monitorknoten beinhaltet darüber hinaus eine Ereignisprotokollanwendung 37, die ein Protokoll von Ereignissätzen von verteilten Vermittlungsknoten in dem Netzwerk verwaltet. Dies wird zur Berichterzeugung verwendet und nicht direkt von dem Anzeigeprozessor 33 verwendet.
Der Monitorknoten beinhaltet ferner ein Interfacegerät oder -geräte 38 zur Anwendereingabe, wie z.B. eine Tastatur und eine Maus, wie es oben beschrieben wurde, um einen gegenständlichen Knoten zur Anzeige in dem Knotenkonfigurationsfenster 23 des Anzeigeprozessors 33 zu identifizieren.
Der Monitorknoten ist über eine HDLC-Verbindung 39 mit einem Vermittlungsknoten in dem Netzwerk verbunden. Dementsprechend ist eine HDLC-Anschluß-Serveranwendung 40 vorgesehen, durch die Nachrichten von der Alarmtabellenanwendung, Topologiedatenanwendung, Datenbankanwendung und Ereignisprotokollanwendung zu den verteilten Vermittlungsknoten gesendet werden. Darüber hinaus werden Daten durch den HDLC-Anschluß 40 von den verteilten Vermittlungsknoten in Antwort auf die Anfragen empfangen.
Die Ereignisprotokollanwendung 37, Alarmtabellenanwendung 34, Topologiedatenanwendung 35 und Datenbankanwendung 36 sind verteilte Aufgaben, wobei ein Teil einer jeden Aufgabe an dem Monitorknoten und der Rest der Aufgabe an den Vermittlungsknoten des Netzwerkes läuft. Die Details dieser Aufgaben sind weiter unten angegeben.

IV. Überblick über einen Vermittlungsknoten

Fig. 4 zeigt Aufgaben, die an einem Vermittlungsknoten laufen, der an einen Monitorknoten in dem Netzwerk gekoppelt ist. Dementsprechend beinhaltet dieser Vermittlungsknoten einen HDLC-Anschluß 45, der an die HDLC-Verbindung 39 gekoppelt ist, um Kommunikation zu empfangen und Nachrichten für den Monitorknoten bereitzustellen. Darüber hinaus führt der Vermittlungsknoten, wie er in Fig. 4 dargestellt ist, Kommunikationsaufgaben aus, wie es schematisch bei 46 dargestellt ist, um Kommunikation durch das Netzwerk 47 zu verwalten. Ein Ereignisprotokoll 48 wird von dem Vermittlungsknoten in Antwort auf die Kommunikationsaufgaben 46 verwaltet. Darüber hinaus wird an dem Vermittlungsknoten eine Konfigurationsdatenbank 49 verwaltet, die die Konfiguration des lokalen Knotens anzeigt. Schließlich läuft an dem Vermittlungsknoten eine Topologieanwendung 50, um eine Datenbank zu verwalten, die die Topologie des Netzwerkes anzeigt und von der Kommunikationsanwendung 46 bei der Rufweiterleitung und ähnlichen Operationen verwendet wird.
Darüber hinaus laufen an dem in Fig. 2 dargestellten Vermittlungsknoten ein Alarmtabelleninterface 51, ein Ereignisprotokollinterface 52 und ein Datenbankinterface 53. Jedes dieser Interface 51, 52, 53, die angeschlossene Prozessorausführungseinheiten (attached processor executors, APE) genannt werden, ist dazu angepaßt, um Informationen von dem Ereignisprotokoll 48 oder der Konfigurationsdatenbank 49 vorzuverarbeiten und zu verpacken und diese Information in Antwort auf Anfragen von dem Monitorknoten zu dem Monitorknoten zu übertragen. Darüber hinaus dient jedes dieser Interface 51, 52, 53 als einzelner Monitorknoten. In dem in Fig. 4 gezeigten Ausführungsbeispiel dienen diese Interface als Monitor Nr. 1. Wenn ein zweiter Monitor zu dem Netzwerk hinzugefügt wird, sind ein zweites Alarmtabelleninterface für den zweiten Monitor, ein zweites Ereignisprotokollinterface für den zweiten Monitor und ein zweites Datenbankinterface für den zweiten Monitor erforderlich.
Die Topologieanwendung 50 antwortet direkt auf Anfragen, die sie von einem an den Vermittlungsknoten angeschlossenen Monitorknoten empfängt, um Topologiedaten bereitzustellen. Da diese Information für das gesamte Netzwerk verwaltet wird, ist der Knoten, an den der Monitorknoten über die HDLC-Verbindung 39 gekoppelt ist, der einzige Knoten, der Topologiedaten zu dem Monitorknoten senden muß.
Das Ereignisprotokoll verwaltet in dem bevorzugten Ausführungsbeispiel Ereignissätze für den Knoten und eine Alarmtabelle. Das Interface für die Alarmtabelle ist getrennt von dem Interface für das Ereignisprotokoll, um Integrität der Alarme sicherzustellen, wie es genauer unten diskutiert wird.
Fig. 5 ist ein schematisches Diagramm eines Netzwerkes mit zwei Monitoren. Weil die Monitoraufgaben gemäß der vorliegenden Erfindung mit Kommunikationsaufgaben in dem Netzwerk nur sehr wenig interferieren, ermöglicht die vorliegende Erfindung es, daß eine Vielzahl von Monitoren an ein einziges Netzwerk gekoppelt wird. Demgemäß ist ein erster Monitor MON1 65 an einen ersten Vermittlungsknoten 66 in dem Netzwerk gekoppelt. Der Vermittlungsknoten 66 ist an die Vermittlungsknoten 67 und 68 und durch die Knoten 67 und 68 an andere Vermittlungsknoten in dem Netzwerk gekoppelt. Ein zweiter Monitor MON2 69 ist an den Vermittlungsknoten 70 gekoppelt. Der Vermittlungsknoten 70 ist an den Vermittlungsknoten 71 und an andere Knoten in dem Netzwerk gekoppelt. Wie es oben bereits erwähnt wurde, hat jeder von den entsprechenden Monitoren MON1 und MON2 bediente Knoten in dem Netzwerk ein Alarmtabelleninterface 51 für jeden Monitor, ein Ereignisprotokollinterface für jeden Monitor und ein Datenbankinterface für jeden Monitor. Der Vermittlungsknoten 66 sendet Topologiedaten zu dem Monitor MON1 und der Vermittlungsknoten 70 sendet Topologiedaten zu dem Monitor MON2.

V. Monitorsystembetrieb

In dem bevorzugten Ausführungsbeispiel verwalten ein Server 33 für den Anzeigeprozess sowie ein Benutzereingabeinterface 38 des Monitorsystems die Anzeige des gegenwärtigen Netzwerkstatus und der gegenwärtigen Netzwerktopologie, stellen einen Menüservice bereit und stellen ein Konfigurationsmodul zur Verwendung durch die Bedienungsperson bereit. Der gegenwärtige Status des Netzwerkes wird durch Hinweise von der Alarmtabellenanwendung 34 über Alarme, die in den verteilten Vermittlungsknoten auftreten, von der Netzwerktopologieanwendung 35 über Knoten, die in dem Netzwerk den Betrieb aufnehmen und einstellen, und von der Datenbankanwendung 36 über Änderungen bei Konfigurationen von Verrnittlungsknoten bestimmt. Darüber hinaus liefert das Konfigurationsmodul Informationen an den Anzeigeprozessor 33, die anzeigen, wenn Knoten hinzugefügt oder von dem Netzwerk entfernt werden, und zur Modifikation der angezeigten Fenster.
In großen Netzwerken, in denen alle Knoten bis zum Maximum konfiguriert sind, ist die Anforderung an den Monitorknoten nach Platz für Daten unermeßlich. Um eine vernünftige, virtuelle Größe zu behalten, konstruiert der Anzeigeprozessor 33 Kartenkonfigurationsinformationen auf der Kartenebene und darunter nur, wenn Bilder gefordert sind, was eine Bedienungsperson anzeigt.
Der Monitorknoten beinhaltet ein unterlagertes Datenmanagementsystem, das auf einer kommerziell verfügbaren Datenbank beruht, die als ORACLE bekannt ist. Jede Anwendung an dem Monitor, die ORACLE verwendet, benötigt Lese-, Einfüge- und Aktualisierungsfunktionen an stark verschiedenen Tabellen, Reihen und Spalten. Das Interface zu dem Datenbankmanagementsystem an dem Monitor ist ein Funktionsaufruf, der auf SQL-Statements reagiert, die von den Anwendungen ausgegeben werden. Die Datenbank enthilt sämtliche Knotenkonfigurationsdaten von der Datenbankanwendung 36, Ereignissätze von der Ereignisprotokollanwendung 37 zusammen mit Textbeschreibungen. Für die Bedienungsperson des Monitorknotens wird ein standardmäßiges SQL-Fenster bereitgestellt, durch das der Anwender beliebige Anfrage an die Datenbank stellen kann.
Eine Zeitüberwachungsaufgabe zählt periodisch die Zahl der in der Datenbank aufgelisteten Ereignisse und initiiert eine Sitzung mit dem Anwender, wobei sie ihn auffordert, Ereignisse und Fehler in freien Bereichen des Speichersystems zu aktualisieren und zu löschen.
Das Interface zwischen dem Monitorknoten und dem Vermittlungsknoten ermöglicht es, Nachrichten zwischen dem Monitorknoten und Aufgaben in den Vermittlungsknoten zu versenden. Wie es oben bereits erwähnt wurde, ist das Interface eine HDLC- Verbindung mit Aufgaben, die an dem Monitorknoten und dessen angeschlossenem Vermittlungsknoten laufen, um das Interface zu verwalten.
Auf der Monitorseite der Verbindung werden Nachrichten von den an dem Monitor laufenden Anwendungen über die HDLC- Verbindung geschrieben. Darüber hinaus werden von der Verbindung empfangene Pakete zu den geeigneten Anwendungen an dem Monitorknoten verteilt. Auf der Vermittlungsknotenseite der Verbindung 39 empfängt eine Aufgabe einkommende Nachrichten von dem Netzwerk und von dem Monitor. Diese Aufgabe wirkt als "Ghostwriter" für alle Monitoranwendungen. Eingehende Pakete enthalten volle Netzwerknachrichten. Die das Monitorsystem bedienenden, verteilten Aufgaben fügen lediglich eine Identifizierung für den Knoten, auf dem sie laufen, in die Nachricht ein, die transparent an das Netzwerk gesendet wird. Eine Aufgabe an dem Vermittlungsknoten, an den der Monitorknoten angeschlossen ist, überträgt dann die Nachricht von dem Monitorknoten mit intaktem Nachrichtenvorsatz (header).
Der Monitorknoten beinhaltet Kern- und Systeminitialisierungsanwendungen, die in dem Blockdiagramm nicht gezeigt sind. Der Kern sorgt für Kommunikation zwischen den Aufgaben, Memory Management, Austesten und Protokollierung sowie Aufgabenmanagementfunktionen für die Vielzahl von Anwendungen, die an dem Knoten laufen. Der Kern verwendet ein UNIX IPC Anwenderdatagrammprotokoll (UDP) als dessen unterlagerten Transportmechanismus. Der Kern bestimmt, daß Nachrichten von Anwendungen, die an dem Monitor laufen, über die UDLC-Verbindungen zu den gekoppelten Vermittlungsknoten in das Netzwerk geliefert werden sollen.
Die Ereignisanwendung des Monitorsystems ruft Ereignisse von allen Knoten in dem Netzwerk ab. Die Anwendung besteht aus zwei Teilen: der Ereignisprotokollanwendung, die an dem Monitor läuft, und dem Ereignisprotokollinterface, das an den verteilten Vermittlungsknoten läuft. Der Monitorknoten empfängt Ereignisinformationen von den Vermittlungsknoten über das Netzwerk und protokolliert die Informationen in der ORACLE-Datenbank. Das Ereignisprotokollinterface, das an den Vermittlungsknoten läuft, ruft Ereignisinformationen von einem Ereignisprotokollmanager an den Verrnittlungsknoten ab und sendet die Informationen zu dem Monitorknoten weiter.
Detaillierte Angaben zu diesen Aufgaben werden unten gemacht.
Die Alarmtabellenanwendung besteht aus einer Anwendung, die an dem Monitorknoten läuft, und einer Interfaceanwendung, die an dem Vermittlungsknoten läuft. Diese Anwendung ruft Alarmtabellen von den verteilten Vermittlungsknoten in dem Netzwerk ab, wenn diese sich verändern, so daß das Anzeigesystem und darauffolgend andere Anwendungen, die an dem Monitor laufen, den sich ändernden Status des Netzwerkes verfolgen können. Die Alarmtabellenanwendung (ATA) ist die einzige Quelle von Alarminformationen für den Monitorknoten. Obwohl diese Information von dem Ereignisstring gewonnen werden kann, wird sie nicht auf diese Weise extrahiert. Darüber hinaus verwaltet die Alarmtabellenanwendung Informationen, die dem Fenster zugeführt werden, das eine Anzeige der aktiven Alarme in dem Netzwerk sortiert nach Grad der Bedeutung, Zeit und Knoten enthält.
Die Netzwerktopologieanwendung (NTA) ist die einzige Quelle von Informationen für den Rest der Monitorknotenanwendungen für Informationen über den gegenwärtigen Status der Netzwerktopologie, wie er an dem Monitorknoten bekannt ist. Sie ruft die Netzwerktopologiekarte von der Netzwerkverwaltungsaufgabe ab, die an dem Knoten läuft, mit dem der Monitorknoten verbunden ist. Diese Informationen werden auf der Basis einer regelmäßigen zyklischen Abfrage gewonnen.
Die Datenbasisanwendung (DBA) ruft Konfigurationsdatenbanken von den Vermittlungsknoten ab, die über das Netzwerk verteilt sind, und speichert sie in einem Monitorknotenformat auf dem Datenbanksystem des Monitorknotens. Die Konfigurationsdatenbanken werden hochgeladen, wann immer der Monitorknoten erkennt, daß eine Datenbank an einem Vermittlungsknoten sich geändert hat und der Monitorknoten nicht erkennen kann, welcher Teil der Datenbank sich geändert hat. Diese Anwendung ist zwischen dem Monitorknoten und der Vielzahl von Vermittlungsknoten verteilt. Die beiden Teile der Anwendung kommunizieren mit einem Protokoll, das für eine verläßliche, geordnete Lieferung der Datenbankblöcke sorgt. Wenn die Datenbanken an einem Vermittlungsknoten aktualisiert werden, werden darüber hinaus die Änderungen zu dem Monitorknoten gesandt.
Ein graphisches Konfigurationstool ermöglicht die Definierung und Anordnung von Knoten, Netzwerken und Ansichten für den Anzeigeprozessor. Das grundlegende Netzwerkobjekt ist ein Knoten. Bevor die Anzeige von Informationen über einen Knoten konstruiert wird, muß der Anwender den Knoten in die ORACLE-Datenbank des Monitorknotens eingeben. Sobald dieser Knoten sich in der Datenbank befindet, ist er für den Anzeigeprozessor verfügbar.
Eine graphische Konfiguratoranwendung, die in dem Anzeigesystem läuft, wird durch eine Bedienungsperson verwendet, um Knoten und Teilnetzwerke für Anzeigezwecke zu gruppieren, falls dies nötig ist. Die Netzwerke und Knoten werden in Ansichten angeordnet. Innerhalb einer Ansicht kann der Benutzer die Knoten an jedem Ort anordnen, wodurch es möglich wird, eine Ansicht zu erzeugen, die leicht zu entziffern ist.
Die Vermittlungsknotenseiten der entsprechenden Monitorknotenanwendungen teilen mehrere Architekturmerkmale. Da erste besteht darin, daß sie alle ein Protokoll verwenden, das einen geordneten, zuverlässigen Austausch von Daten mit dem Monitorknoten sicherstellt. Dieses Protokoll für alle Anwendungen ist ein Protokoll mit positiver Rückmeldung und einer Fenstergröße von 1. Dadurch wird das Protokoll eine einfache Kommando- Antwort-Sequenz, was für eine Kontrolle für die Menge an den Monitorknoten bedienenden Verkehr in dem Netzwerk zu einer gegebenen Zeit sorgt. Von größter Bedeutung ist die Menge an Nachrichten, die an dem Verrnittlungsknoten ankommen, an den der Monitorknoten angeschlossen ist. Dieses Protokoll verhindert es, daß eine Flut von Monitorinformationen den Knoten überlädt.
Ein zweites Architekturmerkmal der Anwendungen auf der Vermittlungsknotenseite besteht darin, daß jede Anwendung auf derselben Zentraleinheit in dem Vermittlungsknoten läuft wie die Aufgabe, die die Kommunikationsfunktionen des Knotens bedient, zu dem das Interface spricht. Dies vereinfacht den Entwurf des Interface und stellt sicher, daß Nachrichten zwischen dem Interface und der Aufgabe, zu dem es spricht, nicht verlorengehen können, und reduziert den Verkehr auf Bussen innerhalb des Moduls.
Falls möglich ist drittens die CPU, auf der das Interface läuft, ein Co-Prozessor und kein Master-Prozessor des Knotens. Dies optimiert die Menge an Speicher für Daten, die das Interface verwenden kann, und minimiert ferner die Einwirkung der Überwachungsaufgaben auf Rufverarbeitungsaufgaben in dem Knoten.
Ein viertes Architekturmerkmal der Monitoranwendungen erfordert es, daß jedes Interface eine einzelne Monitoranwendung bedient und zu einer einzigen Monitoranwendung spricht. Dies vereinfacht die Konstruktionsimplementierung der Interface. Es wurde oben bereits erwähnt, daß jeder Monitorknoten seinen eigenen Satz von Interfacen an dem Verrnittlungsknoten aufweist, wenn zwei Monitorknoten denselben Vermittlungsknoten verwalten.
Die detaillierte Implementierung der Netzwerktopologieanwendung (NTA), der Datenbankanwendung (DBA), der Alarmtabellenanwendung (ATA) und der Ereignisanwendung (EVA) sind unten angegeben.

VI. Konstruktion der Ereignisanwendung

1. Einleitung

Die Ereignisanwendung ist eine verteilte Anwendung, die verantwortlich ist für das Sammeln der Ereignisse, die an den Verrnittlungsknoten in dem in Fig. 6 illustrierten Netzwerk geschehen. Sie besteht aus zwei Hälften, einer (EVA) auf der Monitorseite und der anderen (EVAPE) auf der Seite des Knotennetzwerkes. Der Monitorteil empfängt die Ereignisse von dem Netzwerkteil und verteilt sie nach Bedarf durch das Monitorsystem.
Die Monitorseite der Ereignisanwendung besteht aus der Ereignisanwendungsaufgabe EVA 104. Die EVA kommuniziert mit der Netzwerktopologieanwendung NTA 105 und dem Monitordatenbanksystem DBS 106.
Auf der Netzwerkseite der Ereignisanwendung läuft eine Ereignis-APE-Aufgabe EVAPE 102 an jedem Knoten und spricht zu dem lokalen Ereignisprotokollmanager ELM 103.
Die EVA 104 an dem Monitor verwaltet eine Sitzung mit jeder EVAPE 102 aus dem Netzwerk, um eine zuverlässige Lieferung von Ereignissen sicherzustellen. Dieses Sitzungskonzept erlaubt ferner, daß die EVA 104 eine Flußkontrolle der EVAPEs vornimmt und so verhindert, daß der Monitorknoten mit Nachrichten aus dem Netzwerk überflutet wird.
Darüber hinaus können die EVAPEs die Wirksamkeit der Übertragung erhöhen, den Netzwerkverkehr verringern und effizienten Gebrauch von lokalen Zwischenspeicherbereichen machen, indem Ereignisnachrichten, die von der ELM 103 ankommen, verpackt werden, bevor sie zu der EVA 104 übertragen werden.

2. Genereller Systemüberblick

Fig. 6 gibt einen generellen Überblick über das zu implementierende System. Sie zeigt die logischen Module und die zwischen diesen ausgetauschten Nachrichten. Der Transferservice 101 sorgt für das transparente Austauschen von Nachrichten zwischen den Aufgaben, hier der EVA 104 und der EVAPE 102. Diese Aufgaben merken den Transferservice 101 nicht.

3. Die EVAPE

3.1 Erforderliche ELM-Merkmale

Die Konstruktion der Ereignisanwendung beruht auf einem funktionalen Merkmal des ELM 103. Er muß die zusätzliche Funktion aufweisen, daß er detektieren kann, wenn ein Umbruch erfolgt, und diesen Umbruch seiner Abnehmeraufgabe mitteilen, die die EVAPE 102 ist.
Wie in Fig. 7 dargestellt, wird ein Umbruch hier semantisch als eine Lücke in der chronologischen Abfolge von n Ereignissen aus dem Ereignisprotokoll verstanden, wobei angenommen wird, daß Ereignis 1 von n erfolgreich abgefragt wurde und der ELM 103 die Ereignisse 1 und 2 überschreiben könnte, während die EVAPE 102 auf CPU-Zyklen wartet, um die Ereignisse 1 und 2 zu lesen. Das nächste Ereignis, das die EVAPE 102 von dem ELM 103 erhält, sobald sie wieder läuft, ist folglich nicht das Ereignis 2, das sie tatsächlich möchte, sondern ein Ereignis, das nicht länger in der Abfolge mit Ereignis 1 ist, das bereits gelesen wurde. Ein Umbruch hat stattgefunden.
Der ELM 103 muß in dem Flagfeld der Ereignisprotokollnachricht die EVAPE 102 von diesem Umbruch informieren, der aus dem Verlust von einer unbekannten Anzahl von Ereignissen besteht. Die EVAPE 102 selbst kann einen Umbruch nicht detektieren.
Außer dem Markieren der Monitordatenbank werden keine weiteren Aktionen unternommen, wenn ein Umbruch erfolgt. Die verlorenen Ereignisse wegen eines Umbruches sind nicht wiederzubeschaffen.

3.2 EVAPE-Verpackungsschema

Eine Aufgabe einer EVAPE 102 kommuniziert mit dem lokalen ELM 103 an jedem Vermittlungsknoten in dem Netzwerk.
Sie erhält eine Anfrage von der gleichen Ereignisanwendungssaufgabe EVA 104 an dem Monitor aus der Ereignisliste zu lesen. Die EVAPE 102 wird dann mit einer bestimmten Anzahl von Ereignissen antworten, die in einem Ereignispaket enthalten sind.
Das Protokoll zwischen der EVA 104 und der EVAPE 102 wird im Abschnitt 3.2 genauer diskutiert.
Die EVAPE kommuniziert mit dem ELM auf die sogenannte verzögerte Weise, d.h., Ereignisse werden durch den ELM 103 nicht asynchron zu der EVAPE 102 geschickt. Die EVAPE 102 fordert stattdessen ein einzelnes Ereignis zur Zeit, bis eine bestimmte Zahl von Ereignissen erreicht ist, die gut in ein Paket von den Kommunikationsaufgaben von maximaler Größe (900 Bytes) paßt oder bis eine andere Bedingung eintritt (siehe Abschnitt 3.2).
Diese Zahl wird so bestimmt, daß sie 28 physikalischen Ereignissätzen (28*32 Bytes = 896 Bytes) entspricht, was in eine dynamisch einstellbare Zahl von logischen Ereignissen in Abhängigkeit von der Größe eines jeden Ereignisses (1 - 3 physikalische Sätze) übersetzt wird.
Das Absenden eines derartigen Bündels von Ereignissen anstatt jedes einzelnen Ereignisses, sobald es von dem Protokoll abgefragt wurde, erhöht den Durchsatz, ohne jedoch den Monitorknoten zu überfluten und macht besten Gebrauch von internen Zwischenspeichern, da der Knotenspeicher in Stücken von minimal 512 Byte zugeordnet ist.
Wenn eine Ereignisprotokoll-Nachricht (EventLogMsg) von dem ELM empfangen wurde, entpackt die EVAPE diese wie oben angedeutet, d.h. sie gewinnt im wesentlichen die Ereignisinformation (82 Bytes) zurück und für den Fall, daß die Ereigniseinheiten nicht alle verwendet werden, speichert sie diese in einer kompakteren Form in dem Zwischenspeicher, den sie verwendet, um die Nachricht zusammenzustellen, die als Antwort auf eine frühere Anfrage zu der EVA 104 gesendet werden soll. Ein "voll geladenes" Ereignis kann nicht komprimiert werden und wird so wie es einkommt in der EventlogMsg gespeichert.
Der Weg, wie die EVAPE Ereignisse komprimiert, ist in der folgenden Fig. 8 gezeigt.
Fig. 8 zeigt eine Ereignisprotokoll-Nachricht, die ein Ereignis mit zwei Einheiten enthält. Folglich werden nur zwei Einheiten in dem Nachrichtenzwischenspeicher der EVAPE 102 gespart, was den Platz für sechs weitere Einheiten (6*6 Bytes = 36 Bytes) speichert, die bei diesen Ereignissen nicht verwendet werden.

3.3 EVAPE-Zwischenspeicherschema

Wenn die EVAPE ihr Ereignispaket zusammengestellt hat und eine Anfrage von der EVA vorliegt, sendet sie es zu der EVA an dem Monitor. Während der Zeit, die die EVAPE warten muß, bis sie die nächste Sendeerlaubnis von der EVA erhält (hier Umlaufverzögerung genannt), beginnt sie weiter zwischenzuspeichern, um das nächste Paket zu erzeugen. Auf diese Weise können Ereignisse etwas schneller gesammelt werden, und es ist wahrscheinlich, daß die EVAPE weniger Ereignisse übersieht.
Es gibt natürlich eine Grenze dessen, was die EVAPE 102 im voraus zwischenspeichern kann. Sie wird nur versuchen, das nächste Paket zusammenzustellen, weil es Beschränkungen bei der Zuordnung des Knotenspeichers gibt und weil es im Mittel wahrscheinlich nicht so viele Ereignisse geben wird.
Der hier benötigte Zwischenspeicherbereich zum Zusammenstellen des nächsten Ereignispaketes während der Umlaufverzögerung beträgt 1 Kbyte. Der Speicher, der der EVAPE permanent zugeordnet ist, beträgt 2 Kbyte, da die EVAPE das Paket speichern muß, das gerade gesendet, aber noch nicht bestätigt wurde (siehe 4.2.2).

3.4 EVAPE-ELM Protokollgrundlage

Die EVAPE startet eine Sitzung mit dem ELM und der EVA, indem sie eine Nachricht zur Eröffnung der Sitzung (OpenSessionMsg) von der EVA an den Monitor erhält. Nachdem die EVA-EVAPE-Sitzung eingerichtet wurde, startet die EVAPE ihre Kommunikation mit dem ELM, indem an den ELM die Filteranfrage- Nachrichten (MsgFilterRequest) gesendet werden, die von der EVA empfangen wurden (siehe Abschnitt 4.2.1 für die Eröffnung der Sitzung EVA-EVAPE).
Die MsgFilterRequests zeigen verzögerten Betrieb an und informieren den ELM ein einziges Ereignis zur Zeit zu senden, bis er wieder zyklisch abgefragt wird.
Der ELM sendet das erste passende Ereignis als Antwort auf den letzten MsgFilterRequest in einer Ereignisprotokoll- Nachricht (EventLogMsg), falls die MsgFilterRequest alle in Folge empfangen wurden und falls genügend Speicher für den ELM verfügbar war, um einen Filtersteuerblock FCB zu bilden. Wenn es kein passendes Ereignis gibt, wird eine Kein-Ereignis- Nachricht (NoEventMsg) zurückgesandt. Wenn die MsgFilterRequest außer Sequenz sind oder wenn der ELM für FCBs außer Speicher ist, wird eine Kein-Service-Möglich-Nachricht (CantServMsg) zurückgesandt.
Um eine Lieferung von MsgFilterRequests in Folge sicherzustellen, speichert die EVAPE diese zwischen, wenn sie sie von der EVA erhält und bringt sie in Reihenfolge, falls erforderlich. Dies kann getan werden, weil die EVAPE über einen Parameter in der OpensessionMsg (siehe Fig. 9) weiß, wieviele MsgFilterRequest zu erwarten sind.
Die EVAPE fordert weitere Ereignisse von dem ELM durch Nächstes-Ereignis-Nachrichten (MsgNextEvent), wobei jeweils ein Ereignis zurückgeschickt wird.
Wenn seit der letzten zyklischen Abfrage kein Ereignis protokolliert wurde, sendet der ELM eine Kein-Ereignis- Nachricht (NoEventMsg).
Die von dem ELM zurückgeschickten Ereignisse sind alle in richtiger Reihenfolge solange nicht das Ereignisprotokoll zwischen zwei MsgNextEvent einen Umbruch hat, in welchem Falle der ELM in dem Flagfeld der EventlogMsg eine Mitteilung geben wird.
Die EVAPE muß einen Zeitgeber für ihre Beziehung mit dem ELM laufen lassen. Sie muß eine Zeitabschaltung vornehmen, wenn die EVAPE von dem ELM keine Antwort auf eine Nachricht empfängt. Dies ist ein Anzeichen dafür, daß der ELM möglicherweise nicht länger aktiviert ist. Die EVAPE versucht bis zu zweimal, erneut ihre Nachricht zu senden, bis sie entweder eine Antwort empfängt oder die EVA über die Situation informiert (ELM- Crashflag im Flagfeld der Ereignispaketnachricht).
Der Tod des ELM ist möglicherweise gekoppelt mit einem Verlust von Ereignissen, weil diese nicht protokolliert werden können, obwohl sie stattgefunden haben mögen. Der Ereignisprotokollzwischenspeicher ist offensichtlich nicht gelöscht.
Wenn der ELM wieder eingerichtet ist, muß die EVAPE eine neue Sitzung mit ihm etablieren, weil der ELM sich natürlich an nichts erinnert (keine FCB). Die EVAPE erhält ihre Sitzungsparameter (MsgFilterRequest) als Antwort von der EVA auf die Mitteilung der EVAPE, weil eine neue EVAPE-ELM-Sitzung eine Reinitialisierung der EVA-EVAPE-Sitzung impliziert.
Die von der EVAPE verwendete Zeitabschaltung, um einen versagenden ELM zu detektieren, ist so ausgewählt, daß sie kleiner ist als die Zeitabschaltung, die in dem EVA-EVAPE- Protokoll verwendet wird.

4. Die EVA

4.1 Allgemeines zur EVA

Die Monitorereignisanwendungsaufgabe (EVA) läuft auf dem Monitor und verwaltet eine Sitzung mit jeder EVAPE in dem Knotennetzwerk.
Die EVA sammelt die Ereignisse von jedem Knoten so, wie die EVAPEs sie senden. Sie nimmt alle Ereignisse in der Monitordatenbank DBS auf. Grundsätzlich müssen der Ereignistyp und Untertyp für die Zwecke der Anfrage und Erzeugung eines Berichtes in verständliche Informationen übersetzt werden. Die EVA speichert die Ereignissätze nur in ihrer ursprünglichen Form in der DBS. Eine Ereignissemantik wird durch eine gesonderte Anwendung (siehe Abschnitt 7 über das EVA-DB-Interface) bereitgestellt.
Die EVA besitzt ein Interface zu der Monitometzwerktopologieanwendung NTA 105, weil diese Anwendung weiß, wenn ein neuer Knoten in das Netzwerk kommt oder wenn einer verschwunden ist. Die NTA 105 informiert die EVA über jede dieser Situationen
Wenn ein Knoten in den Abschnitt hineinkommt, der von dem Monitor verwaltet wird (entweder nach einem Reset oder für den Fall eines neuen Knotens), sendet die NTA 105 eine Knoten-Ein- Nachricht (NodeUpMsg) zu der EVA. In analoger Weise empfängt die EVA eine Knoten-Aus-Nachricht (NodeDownMsg), wenn ein Knoten zusammenbricht und eine Knoten-Entfernt-Nachricht (NodeDeletedMsg), wenn ein Knoten aus dem Abschnitt herausgenommen wurde.
Im ersten Fall muß die EVA eine Sitzung mit der EVAPE eröffnen, die an dem neuen Knoten läuft. Zuvor muß die EVA über Fernkontrolle die EVAPE-Aufgabe erzeugen, indem eine Erzeugenachricht zu diesem Knoten gesendet wird. In den beiden letzteren Fällen kann sie das zyklische Abfragen des EVAPE beenden, weil der Knoten nicht länger erreichbar oder von Interesse ist.

4.2 EVA-EVAPE-Protokoll

Die EVA verwaltet eine Sitzung mit jeder EVAPE an den Knoten in dem Netzwerk. Jede Sitzung wird durch eine die Sitzung eröffnende Nachricht (OpenSessionMsg) von der EVA initialisiert. Die EVAPEs sind nicht in der Lage, eine Sitzung zu initueren.
Die EVA liefert die Filterabfrage-Nachrichten, die die EVAPE benötigt, um ihre Kommunikation mit dem ELM zu starten. Dies ermöglicht die Flexibilität, daß die Monitorseite kontrollieren kann, welche Ereignisse sie von welchem Knoten speichern will (fest verdrahtet).

4.2.1 Eröffnen von Sitzungen

Die EVA eröffnet alle Sitzungen mit einer Sequenz von Sitzungseröffnungs-Nachrichten und wartet auf Antwortpakete von allen EVAPEs. Dies könnte in einem Netzwerk mit 32 Knoten dazu führen, daß 32 Ereignispakete an dem Monitorknoten nahezu gleichzeitig ankommen, falls die Verbindungen es erlauben. Die EVA wird jedoch nur ein Paket z. Zt. akzeptieren.
Die OpensessionMsg hat als Parameter die Zahl der Filteranfrage-Nachrichten (MsgFilterRequest), die folgen (Filter- Count) und als ungenutztes Feld die Zahl von Ereignispaketen, die die EVAPE auf eine Anfrage von der EVA (PktGrant) senden darf. Diese Anzahl ist gleich eins. Was die Struktur einer OpenSessionMsg angeht, siehe Fig. 9.
Antworten der EVAPE von Ereignispaketen pro OpenSessionMsg (PktGrant = 1) sorgen inhärent für eine geordnete Anlieferung, was daher leicht zu implementieren ist. Zwei oder mehr ausstehende Pakete würden einen Fenstermechanismus erfordern, würden jedoch die Flexibilität ermöglichen, entfernten Knoten eine größere Fenstergröße zu geben, um den Wirkungsgrad zu verbessern. In alternativen Ausführungsbeispielen kann dies wünschenswert sein.
Nachdem eine OpenSessionMsg empfangen wurde, bestätigt die EVAPE durch Senden einer Bestätigungsnachricht (ConfirmMsg). Die Struktur der ConfirmMsg ist in Fig. 10 dargestellt. Sie besitzt ein Feld (PktSeqNbr), das die Sequenzzahl des zuletzt gesendeten Ereignispaketes enthält (um die Konsistenz zu prüfen). Als Antwort auf eine OpenSessionMsg ist in der ConfirmMsg die PktSeqNbr gleich null.
Wenn die EVA keine ConfirmMsg von der EVAPE empfängt, versucht sie nicht, die MsgFilterRequest zu senden. Stattdessen nimmt sie eine Zeitabschaltung vor und sendet erneut die Open- SessionMsg gemäß dem unten beschriebenen, üblichen Schema der erneuten Übertragung und Zeitabschaltung. Wenn sie eine ConfirmMsg enthält, sendet sie daraufhin die Anzahl von MsgFilter- Requests, die in der OpenSessionMsg spezifiziert sind.
Dies deckt ebenfalls den Fall von verlorenen MsgFilterReguests ab. Wenn die EVAPE nicht antwortet, wird die EVA eine Zeitabschaltung vornehmen und ab da erneut beginnen.
Die EVAPE bestätigt den Empfang aller MsgFilterRequests, indem eine weitere ConfirmMsg (PktSeqNbr 0) gesendet wird. Wenn die EVA keine empfängt, arbeitet sie wiederum nach dem allgemeinen Schema der erneuten Übertragung.
Die Phase der Eröffnung der Sitzung ist abgeschlossen, die EVA diese ConfirmMsg empfängt. Sie wird unverzüglich in die Paketübertragungsphase eintreten, indem sie durch eine Nächstes- Paket-Nachricht (NxtPktMsg) das erste Paket anfordert.

4.2.2 Übertragung von Ereignispaketen

Die EVA fordert ein Paket von der EVAPE durch eine Nächstes-Paket-Nachricht (NxtPktMsg) an, wie sie in Fig. 11 dargestellt ist.
Die NxtPktMsg hat einen Parameter Paket-Sequenz-Nummer (PktSeqNbr), die die Sequenznummer des erwarteten Paketes enthält. Die PktSeqNbr wird wie folgt manipuliert:
- Wenn PktSeqNbr die Sequenznummer des nächsten erwarteten Paketes ist, wird das nächste Paket in der Abfolge abgefragt, und das zuvor empfangene Paket mit PktSeqNbr-1 wird bestätigt.
- Wenn PktSeqNbr die Sequenznummer des zuletzt empfangenen Paketes ist, wird die erneute Aussendung des zuletzt gesendeten Paketes angeordnet.
Während die EVAPE auf die NxtPktMsg von der EVA wartet, fährt darin fort, den ELM zyklisch nach Ereignissen abzufragen und stellt das nächste Paket zusammen, wie es in Kapitel 2.2 beschrieben wurde. Wenn die NxtPktMsg ankommt, kann die EVAPE dieses Paket unverzüglich als Antwort aussenden, vorausgesetzt, daß die PktSeqNbr mit der dieses Paketes übereinstimmt.
Wenn die NxtPktMsg eine Erneut-Senden-Nachricht ist, dann sendet die EVAPE das zuletzt gesendete Paket erneut aus, das zu diesem Zweck gespeichert wird, bis es bestätigt wurde.
Auf diese Weise hält die EVAPE permanent zwei Ereignispakete, das zuletzt gesendete und das als nächstes zu sendende. Dies benötigt 2 Kbytes an Zwischenspeicherplatz.
Das Format der Ereignispaket-Nachricht (EvPktMsg), wie sie von der EVAPE zu der EVA gesendet wird, ist in Fig. 13 gezeigt.
Die EVA muß einen Zeitgeber für ihre Beziehung und zu der EVAPE laufen lassen, um verlorene Ereignispakete auf den Verbindungen zu detektieren (PktTime). Das Problem besteht darin, wie der Wert dieses Zeitgebers bestimmt wird, der für jede EVA- EVAPE-Sitzung unterschiedlich ist und von der Netzwerktopologie und den Verbindungstabellen abhängt. Da Pakete selten verlorengehen, kann PktTime jedoch großzügig hoch gewählt werden, so daß unabhängig von der Pfadlänge derselbe Wert für alle Sitzungen verwendet werden kann.
In einem Netzwerk mit 32 Knoten sollte eine PktTime von einer Minute groß genug sein, um den Fall des längsten Pfades zu handhaben, ohne daß zu große Verzögerungen für den Fall des mittleren Pfades hervorgerufen werden.

4.2.3 Schema der erneuten Aussendung

Wenn die EVA keine Antwort auf eine NxtPktMsg von der EVAPE während der PktTime empfängt, wird sie die NxtPktMsg bis zu zweimal (insgesamt drei Versuche) wiederholen, ohne die PktSeqNbr zu inkrementieren.
Wenn sie an diesem Punkt immer noch keine EVPktMsg empfangen hat, muß die EVA annehmen, daß die EVAPE gerade zusammengebrochen ist, der Knoten zurückgesetzt wurde, oder daß die HDLC- Verbindung, die den Monitor mit dem Netzwerk verbindet, verlorengegangen ist. Auf jeden Fall hat die EVA aus beliebigem Grund die Verbindung zu der EVAPE verloren. In jedem Fall ist der Mechanismus der Wiederherstellung derselbe.
Die EVA schließt ihre Sitzung mit der EVAPE. Sie überprüft dann, ob sie eine NodeDownMsg oder NodeDeletedMsg von der NTA 105 empfangen hat. Wenn dies der Fall ist, wird sie keine neue Sitzung mit der EVAPE eröffnen, bis sie eine NodeUpMsg von der NTA 105 für diesen Knoten empfängt. Ist dies nicht der Fall, versucht sie unverzüglich die gerade geschlossene Sitzung durch Aussendung einer OpenSessionMsg wiederzueröffnen.
Das gezeigte Schema gilt nicht nur für den Fall, daß auf eine NxtPktMsg keine Antwort erfolgt. Wann immer die EVA eine Zeitabschaltung vornimmt, weil es keine Antwort auf eine beliebige Nachricht gibt, wird derselbe Mechanismus für die Wiederaufnahme angewandt.
Die EVA muß in der DBS vermerken, wenn sie die Verbindung mit einer EVAPE verloren hat, weil möglicherweise Ereignisse verlorengegangen sind.
Wenn die EVA selbst zusammenbricht, dann führt sie eine erneute Initialisierung aller Sitzungen mit den EVAPEs so durch, als wenn sie zum ersten Mal eingeschaltet würde. Die DBS muß entsprechend markiert werden.

4.2.2 Schließen von Sitzungen

In dem vorhergehenden Abschnitt wurde bemerkt, daß die EVA ihre Sitzungen mit einer EVAPE schließt, wenn diese nicht länger erreichbar ist, d.h. wenn Pkttime dreimal in Folge abläuft oder wenn die EVA eine NodedownMsg oder NodeDeleteMsg von der NTA 105 empfängt.
Die EVA schließt eine Sitzung auch dann, wenn sie eine EvPktMsg empfängt, bei der das einen Zusammenbruch des ELM andeutende Flag gesetzt ist, was andeutet, daß die EVAPE keine Antwort von dem ELM empfängt. Die EVAPE hat ihr eigenes Wiedereröffnungsschema durchlaufen, bevor sie diese Nachricht aussendet.
Das Schließen einer Sitzung beinhaltet eine zu sendende Nachricht nur dann, wenn ein Knoten von dem Teil des Netzwerkes entfernt wurde, der durch den Monitor kontrolliert wird, und wenn die EVA noch Verbindung zu der EVAPE hat. In diesem Fall sendet die EVA eine Schließe-Sitzung-Nachricht (CloseSessionMsg) zu der EVAPE, um "aufzuräumen". Die CloseSessionMsg weist als Parameter die Sequenznummer der zuletzt empfangenen EvPktMsg auf (siehe Fig. 12 unten).

5. Endliches Zustandsmodell der EVAPE

Die folgende Fig. 15 zeigt das Zustandsdiagramm der EVAPE. Der endliche Zustandsraum der EVAPE weist drei Zustände auf, wobei "close" 1501 der anfängliche Zustand ist. Das Zustandsdiagramm zeigt die Eingangsnachrichten, die eine Übergangsbedingung bestimmen. Aus Gründen der Verständlichkeit ist nicht erwähnt, wo die Nachrichten in die Zustandsmaschine "eintreten" oder dieser "austreten" (d.h. Nachrichtenschlangen). Darüber hinaus sind zusätzliche Übergangsbedingungen und -aktionen nicht in die Zeichnung aufgenommen worden.
1. Wenn die EVAPE gestartet wird, ist sie in ihrem anfänglichen Zustand "close" 1501 und wartet auf eine OpenSessionMsg von der EVA. Die EVAPE bestätigt den Empfang, indem sie eine ConfirmMsg zu der EVA sendet und in den Zustand "open" 1502 schaltet.
2. In dem "open"-Zustand erwartet die EVAPE eine Anzahl von MsgFilterRequests von der EVA. Diese Zahl wurde in einem Parameter in der vorhergehenden OpenSessionMsg spezifiziert. Die EVAPE speichert alle eingehenden MsgFilterRequests, die ungeordnet ankommen können. Sie bringt sie in Reihenfolge, bevor sie sie zu dem ELM weitersendet. Wenn ein MsgFilterRequest auf dem Weg von der EVA verlorengegangen ist, wartet die EVAPE auf dessen Ankunft. Sie schickt die MsgFilterRequests nicht zu dem ELM bevor sie nicht alle empfangen hat (siehe Abschnitt 6 über die EVA-Protokollmaschine). Die EVA verbleibt in dem Zustand "open" 1502.
3. Nachdem alle MsgFilterRequests zu dem ELM weitergeleitet wurden, erhält die EVAPE eine Antwort zurück. Wenn dies eine CantServMsg ist, kann der ELM höchstwahrscheinlich zur Zeit keinen Speicher finden, um einen Filtersteuerblock FCB zuzuordnen. Deshalb versucht die EVAPE es noch bis zu zweimal mehr, die MsgFilterRequests zu senden. Ihr Zustand bleibt "open" 1502 bis zur dritten CantServMsg (siehe 5).
4. Wenn die EVAPE eine OpenSessionMsg in dem Zustand "open" 1502 empfängt, bestätigt sie durch Senden einer ConfirmMsg zu der EVA. Sie verbleibt in dem Zustand "open" 1502.
N.B.: Die OpenSessionMsg stammt höchstwahrscheinlich von einer anderen EVA.
5. Wenn die EVA die dritte CantServMsg empfängt, gibt sie auf und sendet eine RejectMsg an die EVA. Sie ändert ihren Zustand in "close" 1501.
6. Wie in (3) hat die EVAPE auf eine Antwort von dem ELM gewartet, nachdem sie alle MsgFilterRequests weitergeleitet hat. Diesmal hat der ELM entweder mit einer EventLogMsg oder eine NoEventMsg geantwortet. In jedem Fall bestätigt die EVAPE und vervollständigt die offene Phase durch Senden einer ConfirmMsg an die EVA. Zur selben Zeit fordert sie ein weiteres Ereignis von dem ELM, indem sie ihm eine MsgNextEvent sendet. Die EVAPE schaltet in den Zustand "next" 1503.
71 Wenn die EVAPE in dem Zustand "next" 1503 eine EventLogMsg oder eine NoEventMsg von dem ELM empfängt, fährt sie fort, den ELM zyklisch durch eine MsgNextEvent abzufragen. Nur wenn ihre Zwischenspeicher voll sind, beendet sie die zyklische Abfrage. Die EVAPE nimmt die zyklische Abfrage wieder auf, sobald sie einen freien Zwischenspeicher hat. Dies geschieht, wenn sie eine NxtPktMsg von der EVA empfängt, wodurch die zuvor gesendete EvPktMsg von der EVAPE bestätigt wird. Die EVAPE bleibt in ihrem gegenwärtigen Zustand.
8. Wenn die EVAPE eine NxtPktMsg von der EVA in ihrem Zustand "next" 1503 empfängt, antwortet sie mit einer EvPktMsg, die die von der EVA erwartet PktSeqNbr enthält und in der NxtPktMsg angedeutet ist. Dies kann eine erneüte Aussendung oder eine neue EvPktMsg sein.
Wenn die erwartete PktSeqNbr in der NxtPktMsg dieselbe ist wie die PktSeqNbr in der zuletzt gesendeten EvPktMsg, dann sendet die EVAPE dieses letzte Paket erneut aus. Sie inkrementiert ihren internen, aktuellen PktSeqCount (anfänglich eins) nicht.
Wenn die erwartete PktSeqNbr mit der nächsten, von der EVAPE auszusendenden PktSeqNbr übereinstimmt (aktueller Pkt- SeqCount), dann sendet die EVAPE eine EvPktMsg mit dieser PktSeqNbr. Sie inkrementiert ihre PktSeqNbr (Modulo 2) und macht den Zwischenspeicher frei, der die zuletzt gesendete und nun bestätigte EvPktMsg enthält. Damit hat sie Speicher zur Verfügung, um die nächste EvPktMsg zusammenzustellen.
Wenn die EVAPE keine Ereignisse hat, wenn sie einen NxtPktMsg empfängt, antwortet sie nicht. Nur nachdem sie die dritte NxtPktMsg empfangen hat, die nach derselben PktSeqNbr fragt, sendet sie eine EvPktMsg mit null Ereignissen und der gewünschten PktSeqNbr. Dieses Schema erfordert die geringste Anzahl von Nachrichten, die zwischen der EVAPE und der EVA ausgetauscht werden müssen, wenn es keine Ereignisse zu berichten gibt. Die EVAPE muß das dritte Mal antworten, weil die EVA ihre Sitzung nach drei Versuchen zurücksetzt (es wird angenommen, daß die EVAPE nicht erreichbar ist).
9. Wenn die EVAPE sich in dem Zustand "next" befindet und eine OpenSessionMsg empfängt, antwortet sie durch Senden einer ConFirmMsg und ändert ihren Zustand in "open". Die Open- SessionMsg stammt höchstwahrscheinlich von einer anderen EVA an einen anderen Monitor als von der, mit der die EVAPE bisher gesprochen hat. Dies kann passieren, wenn der Monitor herausgezogen wird, ohne daß das System sauber heruntergefahren wird. Wenn ein anderer Monitor (oder sogar derselbe) wieder an das Netzwerk gehängt wird, läuft die EVAPE noch, wenn dieser Knoten nicht herausgenommen wurde. Deshalb muß sie in dem Zustand "next" 1503 eine OpenSessionMsg akzeptieren.
10. Die EVAPE kann in den Zuständen "open" 1502 oder "next" 1503 eine CloseSessionMsg empfangen, die zu einer Veränderung des Zustandes in "close" 1501 führt. Der Knoten, wo die EVAPE lguft, wurde aus dem Netzwerkteil entfernt, der von dem Monitor verwaltet wird. Deshalb schließt die EVA ihre Sitzung mit der EVAPE.
N.B.: Dies sagt der EVAPE, den ELM nicht länger zyklisch abzufragen und ihre Zwischenspeicher freizumachen. Auf diese Weise benutzt sie weder CPU noch RAM während der Knoten nicht länger von dem Monitor verwaltet wird. Dasselbe Ergebnis wird erreicht, wenn die EVAPE einen längeren Zeitgeber erhält. Wenn dieser Zeitgeber abläuft und die EVAPE bis dahin nichts von der EVA gehört hat, schließt sie die Sitzung unter der Annahme, daß ihr Knoten von dem Bereich entfernt wurde. Die EVAPE räumt genauso auf wie zuvor erwähnt.
11. Wenn die EVAPE von dem ELM keine Nachricht auf eine MsgNextEvent erhält, wird sie es bis zu zweimal erneut probieren. Wenn sie immer noch nichts zurückerhält, nimmt sie an, daß der ELM nicht länger erreichbar ist (d.h. zusammengebrochen ist). Die EVAPE informiert die EVA, indem sie auf die nächste NxtPktMsg mit einer EvPktMsg antwortet, bei der das Flag ELM- Zusammenbruch gesetzt ist.
12. Wenn die EVAPE in dem Zustand "next" eine Cant- ServMsg von dem ELM empfängt, bedeutet dies, daß der ELM den FCB verloren hat (möglicherweise nach einem Zusammenbruch). Deshalb hört die EVAPE damit auf, den ELM durch MsgNextEvent zyklisch abzufragen und antwortet auf die NxtPktMsg mit einer EvPktMsg, bei der das Flag ELM-Zusammenbruch gesetzt wurde. Sie verändert ihren Zustand in "close" 1501.
13. Die EVAPE hat sich gerade zurückgesetzt und ist in ihrem ursprünglichen Zustand "close" 1501. Wenn sie eine NxtPktMsg empfängt, hat die EVA das Zurücksetzen noch nicht bemerkt. Deshalb sendet die EVAPE eine RejectMsg, um dies mitzuteilen.
Die EVAPE könnte alternativ die NxtPktMsg ignorieren, wenn sie in "close" 1501 ist. Nach einer dritten NxtPktMsg ohne eine Antwort würde die EVA die Sitzung in jedem Fall wieder eröffnen. Durch die RejectMsg erfolgt dies jedoch schneller.
Die folgenden Nachrichten können in den folgenden Zuständen ignoriert werden (d.h. die EVAPE unternimmt nichts und verwirft sie) und fehlen daher in dem Zustandsdiagramm an den entsprechenden Plätzen.

a) In "close" 1501

- EventLogMsg vom ELM (nur möglich nach einem Zusammenbruch der EVAPE)
- NoEventMsg vom ELM (nur möglich nach einem Zusammenbruch der EVAPE)
- CantServMsg vom ELM (möglich nach einem Zusammenbruch des ELM)
- MsgFilterRequest von der EVA (kann nur von einer anderen EVA/einem anderen Monitor kommen)

b) IN "open" 1502

- NxtPktMsg von der EVA (kann nur von einer anderen EVA/einem anderen Monitor)

c) In "next" 1503

- MsgFilterRequest (kann nur von einer anderen EVA/einem anderen Monitor kommen).

6. Endliches Zustandsmodell der EVA

Fig. 14 zeigt die Zustandsmaschine für das EVA-Protokoll. Tatsächlich ist die EVA eine Maschine mit mehrfachen endlichen Zuständen, was einen Automaten für jeden von dem Monitor verwalteten Knoten ermöglicht, da er eine Sitzung mit jeder EVAPE auf jenen Knoten halten muß. In der Zeichnung ist nur eine dieser Zustandsmaschinen gezeigt, die eine spezifische EVA-EVAPE- Sitzung repräsentiert. Der endliche Zustandsraum hat drei Zustände, wobei "close" der anfängliche Zustand ist. Die Eingangsnachrichten kommen entweder von der EVAPE oder NTA 105. Die Ausgangsnachrichten werden alle zu der EVAPE als Aktionen auf die entsprechenden Übergänge gesendet.
1. Eine bestimmte Sitzung ist in ihrem anfänglichen Zustand "close" 1401. Die EVA empfängt eine NodeUpMsg von der NTA 105, die ihr mitteilt, daß der Knoten, auf den sich diese Sitzung bezieht, eingeschaltet wurde. Sie ordnet einen Sitzungskontrollblock SCB für die EVAPE zu, die auf diesem Knoten läuft und öffnet eine Sitzung mit ihr durch Senden einer OpensessioMsg. Die EVA ändert den Sitzungszustand in "open" 1402.
2. Die EVA hat ihre Sitzung mit einer EVAPE gerade geschlossen und ist in dem Zustand "close" 1401 für diese Sitzung. Wenn der Knoten, an dem die EVAPE läuft, noch eingeschaltet ist (d.h., der Grund für das Schließen war ein nicht erreichbarer ELM), eröffnet die EVA die Sitzung erneut durch Senden einer OpenSessionMsg und Überführen der Sitzung in den Zustand "open" 1402.
3. Die EVA-EVAPE-Sitzung ist in dem Zustand "open" 1402. Die EVA wartet auf eine ConfirmMsg von der EVAPE, um den Empfang der OpenSessionMsg zu bestätigen. Wenn sie die ConfirmMsg empfängt, sendet die EVA die Zahl von MsgFilterRequests, die in der OpenSessionMsg der EVAPE angezeigt wurden (siehe ebenfalls (7)).
4. Nachdem die letzte MsgFilterRequest gesendet wurde, wartet die EVA auf eine ConfirmMsg oder eine RejectMsg von der EVAPE, wodurch angedeutet wird, daß alle MsgFilterRequests angekommen sind (siehe (8)) bzw. (5)).
Wenn die EVA keine ConfirmMsg erhält, bevor die Zeitabschaltung abläuft, nimmt sie an, daß eine oder mehrere Msg- FilterRequests verlorengegangen sind. Deshalb sendet sie die MsgFilterRequests bis zu zweimal erneut aus (siehe auch (6)).
5. Die EVA empfängt eine RejectMsg von der EVAPE in dem Zustand "open" 1402. Dies bedeutet, daß der ELM negativ auf die übersandte Filteranfrage geantwortet hat (siehe EVAPE- Zustandsdiagramm (5)). Die EVA schließt die Sitzung, indem der Zustand der Sitzung in "close" 1401 geändert wird.
6. Wenn die EVA dreimal nacheinander eine Zeitabschaltung vornimmt, während sie auf eine Antwort wartet, die ihre MsgFilterRequests bestätigt, schaltet sie für diese Sitzung in dem Zustand "close" 1401.
7. Wenn die EVA keine ConfirmMsg enthält, bevor die PktTime ihrer Zeitabschaltung abläuft, ändert sie den Zustand dieser Sitzung in "close" 1401 und beginnt von dort neu.
8. Wenn die EVA schließlich eine ConfirmMsg von der EVAPE als Antwort darauf erhält, daß alle MsgFilterRequest angekommen sind und das Filter okay ist, sendet sie die erste NxtPktMsg zu der EVAPE, die eine EvPktMsg mit erwarteter PktSeqNbr1 anfordert. Zur selben Zeit setzt die EVA ihren Zeitgeber PktTime. Dies eröffnet die Pakettransferphase. Die EVA bringt die Sitzung in den Zustand "next" 1403.
9. Wann immer die EVA in dem Zustand "next" 1403 eine EvPktMsg mit der erwarteten PktSeqNbr empfängt, inkrementiert sie ihren internen PktSeqCount (Modulu 2) und bittet die EVAPE um die folgende EvPktMsg durch Senden einer anderen NxtPktMsg mit einer PktSeqNbr, die gleich PktSeqCount ist. Die EVA setzt ihren Zeitgeber PktTime zurück und verbleibt in dem Zustand "next" 1403.
10. Wenn die EVA eine Zeitabschaltung vornimmt, während sie auf eine EvPktMsg wartet, fragt sie nach einer erneuten Aussendung derselben, unter der Annahme, daß das Paket verlorengegangen ist. Sie setzt den Zeitgeber zurück und bleibt in dem aktuellen Zustand. Sie inkrementiert ihren PktSeqCount nicht (siehe ebenfalls (14)).
Es ist möglich, daß der EVA-Zeitgeber abläuft, wenn die EvPktMsg nicht verlorengegangen aber entsetzlich spät ist. In solchen Fällen hat die oben erwähnte erneute Übertragung ein Dublikat erzeugt. Deshalb verwirft die EVA eine EvPktMsg mit einer PktSeqNbr, die sie bereits empfangen hat.
11. Die EVA empfängt eine NodeDownMsg (für den Knoten, auf dem die EVAPE läuft) von der NTA in dem Zustand "open" 1402 oder "next" 1403. Sie schließt die Sitzung, indem sie ihren gegenwärtigen Zustand in "close" 1401 überführt.
12. Die EVA empfängt eine NodeDeleted (für den Knoten, auf dem die EVAPE läuft) von der NTA 105, wenn ein Knoten aus dem von dem Monitor verwalteten Netzwerk herausgenommen wird. Die EVA räumt deshalb auf, indem sie eine CloseSessionMsg an die EVAPE sendet. Sie verändert ihren Zustand in "close" 1401.
13. Wenn die EVA eine EvPktMsg empfängt, bei der das Flag ELM-Zusammenbruch gesetzt ist, schließt sie ihre Sitzung mit der EVAPE, indem sie in den Zustand "close" 1401 schaltet. Die EVAPE ändert ihren Zustand in "close" 1501, wenn sie die EvPktMsg aus sendet.
14. Wenn der Zeitgeber PktTime dreimal in Folge abgelaufen ist, während die EVA auf eine EvPktMsg wartet, schließt sie ihre Sitzung mit der EVAPE intern, indem sie ihren Zustand in "close" 1401 ändert.
Sehr späte EvPktMst, die dazu geführt haben mögen, daß der Zeitgeber dreimal ablief, werden von der EVA in dem Zustand "close" 1401 verworfen.
15. Die EVAPE könnte sich zurückgesetzt haben, nachdem sie eine EvPktMsg an die EVA gesendet hat. Wenn die EVA die EvPktMsg empfängt, fordert sie ein weiteres Paket durch eine NxtPktMsg an. Die EVAPE antwortet darauf durch eine RejectMsg, weil sie nach dem Zurücksetzen in ihrem Zustand "close" 1501 ist. Nach Empfang der RejectMsg geht die EVA (ebenfalls) zu "close" 1401.
Die folgenden sind Nachrichten, die von der EVA in Abhängigkeit von dem Zustand der Sitzung verworfen werden können.

1. In "close" 1401

- NodeDownMsg von NTA 105 (no-op, Sitzung bereits geschlossen)
- NodeDeleteMsg von NTA 105 (no-op, Sitzung bereits geschlossen)
- EvPktMsg von EVAPE (nur möglich nach EVA- Zusammenbruch oder späten Paketen von gerade geschlossener Sitzung)
- RejectMsg von EVAPE (nur möglich nach EVA- Zusammenbruch)
- ConfirmMsg von EVAPE (EVA ist möglicherweise in der Phase open zusammengebrochen)
- NodeUpMsg von NTA 105 (nicht wahrscheinlich, würde jedoch nicht schaden, da die Sitzung bereits eröffnet wurde)
- EvPktMsg von EVAPE (unmöglich)

3. In "next" 1403

- NodeUpMsg von NTA 105 (nicht wahrscheinlich, würde jedoch nicht schaden, da die Sitzung bereits eröffnet wurde)
- ConfirmMsg von EVAPE (unmöglich)

7. EVA-DBS

Die EVA kommuniziert mit der Monitordatenbank DBS über einen Funktionsaufruf, um alle Ereignisse, die sie von den EVAPEs empfängt, in der DBS aufzunehmen.
Grundsätzlich übersetzt die EVA die Struktur eines Ereignisprotokollsatzes, wie er in einer EvPktMsg kommt, in die Struktur des Ereignissatzes in der DBS. Dies ist ein ziemlich unkomplizierter Prozeß. Er ist in Fig. 16 dargestellt.
Beim Hochlaufen ruft die EVA eine Funktion auf, die eine Tabelle liefert, die die Knotennummern in DBS-weite einzigartige NodeIDs abbildet. Ein Knoten kann für mehrere Netzwerke ausgelegt sein, so daß seine Knotennummer auf der Sicht der DBS nicht eindeutig ist. Eine eindeutige NodeId muß durch die EVA in jeden DBS-Ereignissatz eingefüllt werden.
Die EVAPE an dem Knoten muß den Zeitstempel für jedes Ereignis in eine absolute Zeit konvertieren (epoch secs). Dies ist nötig, weil die Zeitbasen von zwei beliebigen Knoten möglicherweise unterschiedlich sind. Deshalb können an dem Monitor zwei Ereigniszeitstempel von zwei verschiedenen Knoten nicht ohne Konversion in absolute Zeiten verglichen werden.
Die Einheiten eines Ereignisses werden zum Zwecke der Abfrage oder Berichterzeugung in verständliche Information umgesetzt. Dies kann über einen Funktionsaufruf in der EVA oder über einen getrennten Prozeß entweder vor der Speicherung der Ereignisse in der Monitor-DBS oder zur Zeit der Abfrage erfolgen.
Da der Ereignis-Textstring viel Speicherplattenplatz einnimmt, wenn er in der DBS gespeichert wird, sollte die Übersetzung möglicherweise erfolgen, wenn Ereignisse abgerufen werden. Ein Anwendungsprozeß könnte von dem Anwender eingeschaltet werden, der SQL-Statements akzeptiert, sie zu der DBS weiterleitet und eine Übersetzungsfunktion über die zurückgesandte, unbearbeitete Ereignisinformation laufen läßt, bevor sie für den Anwender angezeigt wird.
Ein Umbruch in der Abfolge der Ereignisse eines Knotens wird in die DBS als Lückensatz eingegeben, was im wesentlichen ein normaler Ereignissatz ist, bei dem das Ereignistypfeld "Ereignisprotokollücke" lautet, und bei dem die Felder für die NodeId und den Zeitstempel ausgefüllt wurden.
Auf gleiche Weise wird der Verlust der Verbindung zu dem ELM eines Knotens in die DB als möglicher Verlust von Ereignissen eingetragen. Da es nicht sicher ist, daß Ereignisse während der Zeit der fehlenden Verbindung verlorengegangen wurden, wird ein anderer Ereignistyp verwendet, wie "unbekannter Zustand".

VII. Alarmtabellenanwendung

Einleitung

Der Zweck der Alarmtabellenanwendung ATA ist es, die aktiven Alarme in dem Netzwerk zu sammeln und zu verteilen.
Die ATA sammelt Alarme von den IDNX-Alarmprotokollen, die von der ELM-Aufgabe IDNX-Ereignisprotokollmanager kreiert und verwaltet werden. Eine Alarmtabelle APE (ATAPE) wird in jedem IDNX-Knoten erzeugt, um Alarmprotokolländerungen zu überwachen und diese Änderungen in Antwort auf Anfragen an die ATA-Aufgabe des Monitors zu senden. Die Monitor-Netzwerktopologieanwendung NTA informiert die ATA über den Zustand der überwachten Knoten.
Alarme werden zu dem Monitormenü und der Anwendung für die Graphikinterfacekonsole MAGIC verteilt sowie zu den Monitoranwendungen Netzwerkalarmmonitor NAM. MAGIC verwendet diese Informationen, um ihren graphischen Darstellungen der Netzwerkkomponenten Farbdynamiken zuzuordnen, die Alarmzustände anzeigen. NAM zeigt die Alarminformation in einem durchrollbaren Suntools-Text-Unterfenster. Die ATA speichert keine Alarminformationen in der ORACLE-Datenbank.
Es ist wert zu erwähnen, daß eine vernünftige Alternative zu diesem Schema darin bestanden hätte, Alarminformationen von der Monitor-Ereignisanwendung EVA zu empfangen, die gleichfalls Ereignisse von den IDNX-Ereignisprotokollen sammelt. (Das IDNX- Alarmprotokoll wird von dem Ereignisprotokoll abgeleitet.) Dieser Ansatz hätte die ATAPE eliminiert und der EVA und ihren zugeordneten EVAPEs eine größere Belastung auferlegt. Bei Berücksichtigung einer Anzahl von schwierigen Synchronisationsproblemen zwischen der IDNX und Monitoransichten von aktuellen Alarmzuständen wurde dieser Ansatz verworfen. Die Synchronisationsmerkmale sind:
1. Eine Erholung von dem unausweichlichen Problem "Ereignisprotokoll-Umbruch" erforderte einen Mechanismus, um Alarmtabellen anzulegen, um verlorene Information wiederzugewinnen. Dies brachte mehrere haarige Synchronisationsprobleme mit sich.
2. Die Abhängigkeit der ATA von der EVA würde die Freiheit der EVA einschränken, Filter zur Ereignissammlung zu verwenden, um den Netzwerkverkehr zu reduzieren.
3. Der ELM würde modifiziert werden müssen, um Alarme zu melden, die von der Bedienungsperson manuell gelöscht wurden.
4. Der Monitor müßte die "Alarmlöschungs"-Ereignisse erkennen können. Dies ist redundant zu der ELM-Logik, die die Alarmtabelle verwaltet

2. Externe Referenzspezifikation

Fig. 17 illustriert die logische Beziehung zwischen der ATA 170 und anderen Prozessen, mit denen sie kommuniziert, sowie den Datenfluß zwischen der IDNX-Ereignisprotokollanwendung ELM 172 und jenen Anwendungen, an die die ATA Alarme verteilt.
An dem Monitorknoten kommuniziert die ATA mit dem ORACLE- Datenbankmanagementdienst 173, der Netzwerktopologieanwendung NTA 174, einem Netzwerkalarmmonitor NAM 175 und einem Menü- und Graphikinterface, das MAGIC 176 genannt wird. In den IDNX- Knoten, die in dem Netzwerk verteilt sind, unterstützt die angeschlossene Prozessor-Ausführungseinheit für die Alarmtabelle ATAPE 177 ein Protokoll mit der ATA an dem Monitorknoten. Darüber hinaus ist an jedem der IDNX-Knoten der Objektmanager OM 178 erforderlich, um die ATAPE durch Nachrichten von der ATA 170 bzw. der ATAPE 177 zu erzeugen und zu löschen.
Die externen Interface von ATA/ATAPE sind in diesem Abschnitt beschrieben. Die Diskussion des internen Designs von ATA und ATAPE ist in Abschnitt 3 beschrieben.

2.1 ATA- und ATAPE-Interface zu dem OM

Der IDNX-Objektmanager OM ist verantwortlich für die Erzeugung und Löschung von IDNX-Aufgaben. Er wird daher aufgefordert, die ATAPE zu erzeugen und zu löschen.
Wenn die ATA von der NTA darüber informiert wird, daß ein IDNX-Knoten überwacht werden muß, sendet sie eine CREATE_MSG an den OM an dem Knoten. Es gibt keine Antwort auf diese Nachricht, so daß die ATA annimmt, daß die Aufgabe gestartet wurde. Wenn das Protokoll der Eröffnung der Sitzung mit der ATAPE fehlschlägt, wird die ATA erneut versuchen, die APE-Aufgabe zu erzeugen.
Die ATA sendet die CREATE_MSG zu der COPROCESSOR_PRE- FERRED_INSTANCE des OM, so daß die ATAPE auf einem IDNX- Coprozessor erzeugt wird, falls einer verfügbar ist. Die Absicht ist es, die Belastung der IDNX-Master-CPU zu minimieren.
Wenn die ATA von der NTA darüber informiert wurde, daß ein IDNX-Knoten nicht länger überwacht wird, dann wird die ATA ihre ATAPE an dem Knoten löschen. Da die ATA nicht weiß, auf welcher CPU die APE läuft, und da die OM DELETE_MSG zu dem OM gesendet werden muß, der die ATAPE erzeugt hat, fordert die ATA die ATAPE auf, die DELETE-MSG zu dem OM zu senden. Es gibt keine Antwort auf die DELETE-MSG; die ATAPE wird weiterlaufen, bis der OM die Nachricht empfängt und die Aufgabe belegt und löscht. Wenn die Löschung der ATAPE fehlschlägt (z.B., die Nachricht der ATA zu der APE geht verloren), dann wird die ATA versuchen, die APE erneut zu löschen.
Die ATAPE-Aufgabe wird durch die ATA erneut erzeugt, wenn entweder die ATAPE abnormal endet oder die CPU zurückgesetzt wird, auf der sie läuft. Dies ist Teil des ATA-ATAPE- Fehlerrückgewinnungsprotokolls, das in den internen Referenzspezifikationen beschrieben wird.
Mehrere Monitor-Workstations pro IDNX-Netzwerk können mit der Einschränkung unterstützt werden, daß nur ein Monitor mit einem gegebenen IDNX-Knoten verbunden ist. Um den Entwurf und die Implementierung der Monitor-APES zu vereinfachen, erzeugt jeder Monitor seinen eindeutigen Satz von APE-Aufgaben an jedem Knoten, der überwacht wird. Alle IDNX-Aufgaben sind durch eine Ursprungsaufgabe id und eine eindeutige Aufgabeninstanz zugeordnet; diese Werte sind in den OM-Nachrichten CREATE und DELETE spezifiziert. Die Monitor-APE-Instanzen werden von der Knotennummer des IDNX-Knotens abgeleitet, mit dem der Monitor verbunden ist. Dies stellt sicher, daß jede APE-Aufgabe mit einer eindeutigen Instanz erzeugt wird und mit einem einzigen Monitor kommuniziert.

2.2 Das ATAPE-Interface zu dem ELM

Die ATAPE sammelt Alarminformationen von dem ELM- Alarmprotokoll. Wenn die ATA eine "Sitzung" mit der ATAPE eröffnet, kopiert die ATAPE das ELM-Alarmprotokoll in eine lokale Alarmtabelle sowie in eine Nachricht/Nachrichten, die an die ATA zu senden sind. Die ATAPE fragt dann die Alarmprotokoll-"Übersichts"-Information ab, um Änderungen (gelöschte, geänderte oder neue Alarme) in dem Alarmprotokoll zu detektieren. Wenn eine Änderung detektiert wird, liest die ATAPE das Alarmprotokoll neu und überträgt die Änderungen sowohl in seine Alarmtabelle als auch zu der ATA.
Die ATAPE liest das ELM-Alarmprotokoll unter Verwendung der Nachricht EVENTLOG_ALARM_TABLE. Die ATAPE sendet diese Nachricht zu dem ELM, wobei sie einen Off set in der Tabelle spezifiziert, und der ELM schickt die Nachricht zurück, die acht Alarme enthält, die an dem Offset beginnen. Dieser Austausch geht weiter, bis das gesamte Alarmprotokoll gelesen wurde.
Der ELM verwaltet "Übersichts"informationen, die dem Alarmprotokoll zugeordnet sind. Diese Übersichtsinformationen werden unter Verwendung der Nachricht EVENT_LOG_ALARM_SUMMARY abgefragt. Der ELM antwortet, indem er die Übersichtsinformation einschließlich einer Gesamtzahl von aktiven und gesamten Alarmen in die Nachricht kopiert und sie zurücksendet. Die ATAPE vergleicht die beiden Gesamtzahlwerte mit der Gesamtzahl, die aus der letzten Übersichtsabfrage abgeleitet wurde. Wenn die Übersichten sich verändert haben, dann liest die ATAPE die neue Alarmtabelle; anderenfalls wartet sie ein bißchen und fragt die Übersichten erneut ab. Die ATAPE fährt fort, Übersichtsinformationen abzufragen und ihre Kopie des Alarmprotokolls zu aktualisieren, bis sie durch die ATA gelöscht wird.
Wenn die ATAPE auf der Master-CPU erzeugt wird, dann kommuniziert sie mit der Master-ELM-Aufgabe. Wenn die ATAPE auf einem Coprozessor erzeugt wird, dann kommuniziert sie mit der Schatten-ELM-Aufgabe. Das Interface zu diesen beiden Aufgaben ist im wesentlichen identisch.

2.3 ATA-Interface mit MAGIC

Die ATA verteilt die Alarminformation, die von den ATAPE- Aufgaben gesammelt wurde, an MAGIC. MAGIC erwartet, nur über den am meisten kritischen Alarm bei einer bestimmten Netzwerkkomponente informiert zu werden, falls diese Komponente mehrfache Alarme auslöst. Sobald MAGIC ein Alarm berichtet wurde, erwartet MAGIC es, daß es über alle Änderungen im Alarmstatus dieser Komponente einschließlich des Löschens aller Alarme informiert wird. Wenn MAGIC durch den DBA-Prozeß darüber informiert wird, daß es eine neue Netzwerkkomponente gibt, fragt es ATA bezüglich der Alarminformation über diese Komponente an.
Wenn Alarminformationen von den ATAPE-Aufgaben gesammelt werden, verteilt ATA die Information an MAGIC in einer gewissen Zahl von GI_STATUS_MSGs. Diese Nachricht beinhaltet die id des Netzwerkkomponentengerätes in ASCII-Format (z.B. NxxCyy.zz) und seinen aktuellen Alarmzustand. Mehrfache Gerät-id/Alarm-Sätze werden in eine einzige Nachricht gepackt, solange dort Platz vorhanden ist (bis zur MAX_SCLP_MSG_SIZE). Die an MAGIC berichteten Alarmpegelwerte sind:
1. => gelöschter Alarm
2. => informeller Alarm
3. => geringer Alarm
4. => großer Alarm
5. => kritischer Alarm
Bis ATA Alarme an MAGIC meldet, nimmt MAGIC an, daß es keine Alarme in dem Netzwerk gibt; folglich ist der anfängliche Alarmzustand des Netzwerkes ein "gelöschter" Alarmzustand. Wenn das ATA-Programm (erneut) startet, führt es einen Quittungsaustausch mit der MAGIC-Anwendung durch (falls MAGIC läuft), was sicherstellt, daß MAGIC alle Alarmzustände in einen "gelöschten" Alarmzustand initialisiert. Auf diese Weise resynchronisieren die Programme ihre Sichtweise von Alarmzuständen für alle Netzwerkgeräte. Der Quittungsaustausch besteht aus einer GI_STATUS_MSG von ATA, bei der die Geräte-id auf "ALL" und der Alarmpegel auf "cleared alarm" gesetzt ist, woraufhin eine GI_RESENDALL_MSG von MAGIC folgt, um die ATA aufzufordern, den gegenwärtigen Alarmzustand aller alarmgebenden Netzwerkkomponenten zu senden. Wenn die ATA Alarme von den ATAPEs sammelt, wird diese Information an MAGIC gesandt.
Wenn MAGIC (erneut) startet, sendet es an ATA eine GI_RESEND_SPEC_MSG, was den aktuellen Alarmzustand aller alarmgebenden Netzwerkkomponenten erfragt.
MAGIC erfragt spezifische Alarminformationen von der ATA mit einer GI_RESENT_SPEC_MSG. Diese Nachricht enthält eine Liste von Geräte-ids von Netzwerkkomponenten, für die MAGIC den aktuellen Alarmzustand wünscht. Die ATA antwortet mit einer Anzahl von GI_STATUS_MSGs.
Die ATA validiert die GI_RESENT_SPEC_MSG von der MAGIC- Anwendung. Wenn eine Information in der Nachricht detektierbar verschlechtert wurde, protokolliert ATA eine Fehlermeldung für das Nachrichtenfenster des Monitorsystems.
Die ATA ist verantwortlich für die Unterscheidung zwischen IDNX digroup- und Anschluß-Geräten. Die Alarmsätze, die von dem ELM gesammelt werden, machen diese Unterscheidung nicht. Die ATA modifiziert die Geräte-id, falls der Alarm ein Anschlußalarm ist, in die Form NxxCyyPzz. Wenn der Alarm ein digroup- Alarm ist, wird die Form NxxCyy.zz verwendet.

2.4 ATA-Interface zu NAM

Die ATA verteilt die Alarminforamation, die von den ATAPE- Aufgaben gesammelt werden, an NAM. NAM erwartet, über alle aktiven Alarme, alle modifizierten aktiven Alarme (Z.B. wenn der Alarm erneut getriggert wurde, bestimmte Alarmsatzinformationen wie z.B. das Zählfeld modifiziert wurden) und alle aktiven Alarme informiert zu werden, die gelöscht wurden. NAM zeigt die meisten der Informationen, die in den Alarmsätzen enthalten sind, die von den ATAPE-Aufgabe empfangen wurden, in einem Suntools Textunterfenster an.
Wenn Alarminformationen von den ATAPE-Aufgabe gesammelt werden, verteilt ATA diese Information an NAM in einigen NAM_UPDATE_MSGs. Diese Nachricht beinhaltet die Alarmsatzstruktur, die von den ELM-Alarmprotokollen abgefragt wurde, sowie eine bezogen auf den Alarm auszuführende Funktion. Mehrfache Alarmsatz/Funktionssätze werden in einer einzigen Nachricht plaziert, solange dort Platz ist (bis zu MAX_SCLP_MSG_SIZE).
Die zu NAM gelangenden Funktionen sind:
NAM_ADD => füge den Alarm zu dem Text- Unterfenster hinzu.
NAM_MODIFY => modifiziere einen bereits in dem Text-Unterfenster angezeigten Alarm.
NAM_DELETE => lösche eine Alarm von dem Text-Unterfenster.
Bis ATA Alarme an NAM meldet, nimmt NAM an, daß es keine Alarme in dem Netzwerk gibt; folglich ist der anfängliche Alarmzustand des Netzwerkes ein Zustand "kein" Alarm. Wenn das ATA-Programm (erneut) startet, führt es einen Quittungsaustausch mit der NAM-Anwendung durch (falls NAM läuft), was sicherstellt, daß NAM alle Alarme löscht, die gegenwärtig in seinem Text-Unterfenster angezeigt werden. Auf diese Weise resynchronisieren die Programme ihre Sicht des Alarmzustandes des Netzwerkes. Der Quittungsaustausch besteht aus einer ATA_RESET_MSG von ATA, gefolgt von einer NAM_RESET_MSG von NAM, die die ATA auffordert, alle gegenwärtig aktiven Alarme zu senden, die sie gesammelt hat. Wenn die ATA Alarme von den ATAPEs sammelt, wird diese Information an NAM gesendet.
Wenn NAM (erneut) startet, sendet er der ATA eine NAM_RESET_MSG, wodurch alle gegenwärtig aktiven Alarme erfragt werden, die von der ATA gesammelt wurden.
Die ATA ist verantwortlich für die Unterscheidung zwischen IDNX digroup- und Anschlußgeräten. Die Alarmsätze, die von ELM gesammelt werden, machen diese Unterscheidung nicht. Die ATA modifiziert die Geräte-id in der Alarmsatzstruktur, indem Bit 30 des Feldes ElmNetAddr gesetzt wird, wenn der Alarm ein digroup-Alarm ist.
Die ATA ist dafür verantwortlich, NAM zu informieren, wenn ein Knoten von der Monitordomäne entfernt wird. Dies erfolgt dadurch, daß NAM eine NAM_DELETE_NODE_MSG sendet, die die Nummer des Knotens enthält, der gelöscht wurde.

2.5 ATA-Interface zu NTA

Die Monitor-Netzwerktopologie anwendung (NTA) informiert die ATA, wenn der Status eines IDNX-Knotens, der durch den Monitor überwacht wird, sich verändert hat. bies schließt das Hinzufügen eines Knotens zu dem Netzwerk, das Löschen eines Knotens von dem Netzwerk und den Verlust oder den Gewinn von einer Verbindung zu einem Knoten in dem Netzwerk ein.
Wenn die ATA (erneut) startet, sendet sie der NTA eine ATA_RESET_MSG (wenn sie eingeschaltet ist). Die NTA antwortet mit einer NTA_NODES_IN_NET_MSG, wodurch die ATA über die Knotennummer des IDNX-Knotens informiert wird, an den der Monitor angeschlossen ist (genannt der "Nachbarknoten"), sowie über die Liste von Knoten, die gegenwärtig überwacht werden und zu denen der Monitor Verbindung hat. Die ATA erzeugt ATAPE-Aufgaben an jedem Knoten, der in der Liste enthalten ist.
Nach dem Quittungsaustausch bei einem (erneuten) Start der ATA mit der NTA informiert die NTA die ATA über Änderungen in dem Status eines beliebigen Knotens in dem Netzwerk mit einer von drei Nachrichten. Jede Nachricht spezifiziert eine einzige Knotennummer. Die Nachrichten sind:
NTA_NODE_UP_MSG => wann immer ein neuer Knoten zu der Monitordomäne hinzugefügt wird oder wann immer Verbindung zu einem Knoten wiedergewonnen wurde, der "nach unten gegangen war".
NTA_NODE_DOWN_MSG => wann immer ein Knoten nach unten geht, d.h. Verbindung zu dem Knotenunterbrochen wurde.
NTA_NODE_DELETED_MSG => wann immer ein Knoten von der Monitordomäne gelöscht wurde.
Die ATA verwendet diese Information, um zu bestimmen, auf welchen Knoten ATAPE-Aufgaben zu erzeugen sind und ob es Zweck hat, zu versuchen, mit einer ATAPE-Auf gabe zu kommunizieren, mit der sie gegenwärtig eine Sitzung hat. Wenn eine NODE_DOWN Nachricht empfangen wird, setzt die ATA ihre Sitzung mit der ATAPE auf dem Knoten aus. Wenn eine NODE_UP Nachricht empfangen wird, erzeugt die ATA entweder eine neue ATAPE und etabliert eine Sitzung mit ihr oder nimmt eine bereits aktivierte Sitzung wieder auf, die unterbrochen wurde. Wenn eine NODE_DELETED Nachricht empfangen wurde, löscht die ATA die ATAPE auf dem Knoten.
Die NTA informiert die ATA ebenfalls, wenn die HDLC- Verbindung zu dem Nachbarknoten nicht mehr verfügbar geworden ist oder daraufhin wieder verfügbar wurde. Wenn die HDLC- Verbindung nicht mehr verfügbar wird, sendet die NTA eine NTA_HDLC_LINK_DOWN Nachricht und die ATA unterbricht alle Sitzungen mit ihren ATAPEs.
Wenn die HDLC-Verbindung wieder verfügbar wird, sendet die NTA eine NTA_HDLC_LINK_UP Nachricht. Diese Nachricht hat dasselbe Format wie die NTA_NODES_IN_NET_MESSAGE. Wenn die Nummer des Nachbarknotens sich nicht geändert hat, nimmt die ATA die Sitzungen mit den ATAPE-Aufgaben auf den Knoten wieder auf, die in der Nachricht aufgelistet sind. Wenn die Nummer des Nachbarknotens sich geändert hat, löscht die ATA alle ATAPE-Aufgaben, die sie erzeugt hat, und erzeugt neue ATAPE-Aufgaben auf den Knoten, die in der Nachricht aufgelistet sind, wobei eine neue Aufgabeninstanznummer von der Nummer des neuen Nachbarknotens abgeleitet wird.
Wenn die NTA-Anwendung (erneut) startet, sendet sie an die ATA eine NTA_RESET_MSG, die dasselbe Format hat wie die NTA_NODES_IN_NET_MSG. Wenn die Nummer des Nachbarknotens sich nicht geändert hat, nimmt die ATA Sitzungen mit ATAPE-Aufgaben auf beliebigen Knoten wieder auf, von denen sie zuvor keinen Alarm gesammelt hatte. Wenn die Nummer des Nachbarknotens sich geändert hat, löscht die ATA alle die ATAPE-Aufgaben, die sie erzeugt hat, und erzeugt neue ATAPE-Aufgaben auf den Knoten, die in der Nachricht aufgelistet sind, wobei eine neue Aufgabeninstanznummer von der Nummer des neuen Nachbarknotens abgeleitet wird.
Wenn die ATA eine NTA_RESET_MSG empfängt, liest sie ebenfalls die Knotentabelle in der ORACLE-Datenbank, die die Knotennummern der IDNX-Knoten enthält, die gegenwärtig in der Monitordomäne definiert sind. Dies wird getan, um sicherzustellen, daß keine Knoten von der Domäne entfernt wurden, während die NTA-Anwendung nicht aktiv war. Wenn die ATA eine Sitzung mit einer ATAPE auf einem beliebigen Knoten hat, der nicht in der ORACLE-Knotentabelle ist, dann wird dieses ATAPE gelöscht.
Die ATA validiert jede Nachricht, die von der NTA- Anwendung empfangen wird. Wenn eine beliebige Information in der Nachricht detektierbar verschlechtert wurde, sendet die ATA die Nachricht zu dem Sender zurück unter Verwendung der Kernfunktion Report BadMessage(). Die ATA sendet zu der NTA ebenfalls eine ATA_RESET_MSG, um zu versuchen, sich von dem möglichen Verlust von Information zu erholen. Eine Fehlernachricht wird ebenfalls zu dem Nachrichtenfenster des Monitorsystems geschickt.

2.6 Datenbank-Interface

Die ORACLE-Datenbank wird verwendet, um Knotennummern von der Knotentabelle abzufragen, wann immer eine NTA_RESET_MSG empfangen wird. Das Format der SQL-Anfrage ist: "SELECT NODE.NODENMBR FROM NODE, NET_NODE WHERE NET_NODE.NODEID = NODE.NODEID".

3. Interne Konstruktionsspezifikation

Es gibt zwei logische Komponenten der Alarmtabellenanwendung. Die erste (resident in den Monitoren) ist die ATA. Die zweite ist die ATAPE, die in jedem der IDNX-Knoten in dem Monitornetzwerk resident ist.
Die ATA verteilt Alarm an MAGIC und an NAM. Die ATAPE sammelt Alarmtabelleninformationen von dem IDNX Ereignisprotokollmanager ELM und leitet sie zu der ATA weiter.

3.1 Das ATA-Interface zu der ATAPE

Wenn die ATA (erneut) gestartet wird, erzeugt und initiiert sie eine Sitzung mit ATAPE-Aufgaben auf jedem der IDNX- Knoten, der in der Monitordomäne definiert ist, und fragt deren Alarmtabellen ab. Abgesehen von Fehlern bei der Sitzungsverbindung sendet die ATAPE danach periodisch Statusmeldungen (Leeroder Alarmänderungen) zu der ATA.
Die Formate der Nachrichten, die zwischen der ATA und der ATAPE ausgetauscht werden, sind im Anhang A definiert.

3.1.1 Initialisierung der Sitzung

Wenn die ATA mehr als eine ATAPE zur Zeit erzeugt (d.h. mehrere neue Knotennummer werden über eine NAT_NODES_IN_NET_MSG geliefert), dann staffelt sie die Eröffnung einer jeden ATAPE- Sitzung um eine kurze, kumulative Verzögerungszeit. Dies ist der einzige Mechanismus, der verwendet wird, um die einzelnen ATAPE-Sitzungsaktivitäten zu staffeln. Eine Sitzung wird eröffnet, indem der in Fig. 18 illustrierte Austausch verwendet wird.
Wenn die ATAPE eine ATA_OPEN_MSG Nachricht empfängt, kopiert sie das ELM-Alarmprotokoll in eine lokale Alarmtabelle und konstruiert eine bestimmte Anzahl von ATA_ALARM_MSG Nachrichten für die ATA. Die Nachrichten werden zu der ATA in Antwort auf ATA_NEXT_MSG Nachrichten gesendet, jeweils eine Alarmnachricht zur Zeit. Jede Alarmnachricht enthält so viele ELM-Alarmsätze wie möglich (bis zu MAX_SCLP_MSG_SIZE). Die Alarmnachrichten werden durch die ATAPE zwischengespeichert, bis eine ATA_NEXT_MSG durch die ATA empfangen wird, was den Empfang der Nachricht bestätigt. Nachrichtenzahlen (Modulo 256) werden verwendet, um positiv oder negativ die ATA-ALARM-MSG von der ATAPE zu bestätigen. Wenn eine negative Bestätigung von der ATA empfangen wird, sendet die ATAPE die letzte ATA_ALARM-MSG erneut aus.
Die letzte ATA_NEXT_MSG in diesem Sitzungsinitialisierungsaustausch wird als ausstehende Anfrage nach einer Alarmtabellen-Statusnachricht verwendet. Dies wird weiter in dem folgenden Abschnitt beschrieben.
Die ATAPE ist verantwortlich für das Übersetzen der Zeitstempel der Alarmsätze von dem internen Zeitformat der IDNX in die Monitorsekunden seit epoch SSE Format. Die IDNX verwaltet eine SSE Uhr, die indirekt durch die Monitor-NTA-Anwendung initialisiert wird.

3.1.2 Normale Sitzungsprozeduren

Das normale Sitzungsprotokoll ist dazu ausgelegt, ein Gleichgewicht zwischen minimalem Netzwerkverkehr und zeitgerechtem Sammeln von Alarmen von den IDNX-Knoten zu erzielen. Es ist in Fig. 19 dargestellt.
Das normale Szenario erfordert es, daß die ATAPE einen freilaufenden Zeitgeber startet, nachdem eine ATA_NEXT_MSG empfangen wurde und falls keine Alarmtabellenänderungen zu senden sind. Wenn der Zeitgeber abläuft und wenn keine Alarmtabellenänderungen akkumuliert wurden, sendet die ATAPE eine ATA_IDLE_MSG zu der ATA. Dies ist eine unnumerierte Nachricht, die keine Antwort von der ATA erfordert. Sie informiert die ATA lediglich darüber, daß die ATAPE noch antwortet. (Die ATA verwaltet einen Inaktivitäts-Zeitgeber, um sich von dem Fall zu erholen, wo die Verbindung mit der ATAPE unterbrochen wurde. Dies wird in dem nächsten Abschnitt diskutiert.)
Während der freilaufende Zeitgeber der ATAPE dekrementiert wird, fährt sie fort, in regelmäßigen Abstgnden das Alarmprotokoll des ELM auf Änderungen zu überprüfen. Wenn Änderungen detektiert werden, werden sie in die lokale Alarmtabelle des APE kopiert und daraufhin werden ATA_ALARM_MSG Nachrichten konstruiert, um die Änderungen zu der ATA zu übertragen. Die ATAPE wird so viele geänderte Alarmsätze in die ATA_ALARM_MSG einfügen wie möglich (limitiert durch MAX_SCLP_MSG_SIZE). Die Antwort von der ATA auf eine ATA_ALARM_MSG ist eine ATA_NEXT_MSG, wobei der Nachrichtensequenzzähler um eins inkrementiert ist.
Sobald das Alarmprotokoll anfänglich während der Sitzungsinitialisierung zu der ATA übertragen wurde, werden nur noch Änderungen (neue, geänderte oder gelöschte Alarme) an dem Alarmprotokoll zu der ATA übertragen. Die ATAPE verwaltet eine interne Betrachtung einer Alarmtabelle, die andeutet, welche Alarmsätze zu der ATA übertragen werden müssen, wenn der nächste Satz von ATA-ALARM-MSGs konstruiert wird.
Das Format der ATA-ALARM-MSG spezifiziert, daß aktive Alarmsätze unter Verwendung der Strukturdefinition ATAAlarmEntry gesendet werden. Gelöschte Alarme werden in komprimierter Form gesendet. Da die ATA ihre eigene innere Kopie des ELM- Alarmprotokolls ebenfalls verwaltet, führt dies dazu, daß übertragen wird, welcher Alarmprotokollsatz gelöscht wurde. Die Inhalte der gelöschten Alarmsätze werden nicht gesendet.
Die Synchronisation zwischen dem ATAPE-Interface mit dem ELM und seinem Interface mit der ATA ist empfindlich gegenüber der Tatsache, daß es eine reale Möglichkeit gibt, daß eine gegebene Kopie des ELM-Alarmprotokolls nicht konsistent ist. Das liegt daran, daß der ELM das Alarmprotokoll aktualisieren kann, während die ATAPE es liest (es erfordert einige Austausche mit dem ELM, um die gesamte Tabelle zu lesen). Folglich verifiziert die ATAPE, daß Alarmübersichten zwischen der Zeit, zu der sie anfängt, das Alarmprotokoll zu lesen, und der Zeit, zu der sie das Lesen des Alarmprotokolls beendet hat, sich nicht geändert haben. Wenn die Alarmübersichtsinformation sich geändert hat, liest die ATAPE das Alarmprotokoll erneut und fährt so fort, bis sich das Alarmprotokoll stabilisiert hat. Es gibt eine Grenze für die Anzahl von Wiederholungen, zu denen die ATAPE das Alarmprotokoll neu liest bevor eine Antwort an die ATA gesendet wird (um zu vermeiden, daß ihr Interface mit der ATA eine Zeitabschaltung erfährt, oder Alarmaktualisierungen für die ATA unnötig verzögert werden). Wenn diese Grenze erreicht ist, wird die ATAPE verifizieren, daß das Alarmprotokoll, obwohl es noch in einem Fließzustand sein kann, konsistent ist (z.B. es gibt keine "doppelten" Alarmsätze. Doppelte Alarme geschehen, wenn ein Alarmsatz durch einen kritischeren Alarm vorweggenommen wird und dann in die Tabelle erneut eingefügt wird, während die ATAPE das Alarmprotokoll liest).

3.1.3 Erholung von einem Sitzungsfehlergewinnung und Sitzungsbeendigung

3.1.3.1 Wiedergewinnung einer verlorenen Nachricht

Die ATA ist verantwortlich für das Wiedergewinnen von Nachrichten, die verlorengegangen sind infolge von Verbindungsausfällen, unüblichen Netzwerkverzögerungen oder Versagen einer IDNX-Aufgabe und eines Knotens. Zu diesem Zweck initialisiert die ATA einen Inaktivitäts-Zeitgeber, sobald sie eine Nachricht zu der ATAPE sendet. Dieser Zeitgeber hat eine relativ lange Ablaufperiode, da diese Art der Wiedergewinnung für sehr selten gehalten wird. Wenn der Zeitgeber abläuft, sendet die ATA ihre letzte Nachricht erneut aus und startet ihren Inaktivitäts- Zeitgeber erneut. Die ATA versucht das Wiedergewinnen dreimal, bevor beschlossen wird, daß die Sitzung nicht wieder aufgenommen werden kann.
Wenn der Versuch zur Wiederherstellung fehlschlägt, informiert die ATA die ATAPE, sich selbst zu löschen, erzeugt die ATAPE-Aufgabe neu und eröffnet wieder eine Sitzung mit ihr. Dieses Verfahren wird wiederholt bis die ATAPE entweder antwortet oder die NTA die ATA informiert, daß der Knoten ausgefallen ist oder daß er von dem Monitornetzwerk entfernt wurde.

3.1.3.2 Rücksetzen von Anwendungen

Wenn die ATA erneut startet, erzeugt und öffnet sie Sitzungen mit den ATAPE-Auf gaben. Wenn die ATAPE bereits aus einer vorhergehenden Einsetzung durch die ATA existiert, dann reinitialisiert die ATAPE ihre Sitzung mit der ATA und sendet eine vollständige Kopie ihrer Alarmtabelle an die ATA.
Wenn die ATAPE-Aufgabe auf nicht normale Weise endet und durch den OM neu gestartet wird, dann ist es möglich, daß eine neue ATAPE anfänglich eine andere Nachricht als eine ATA_OPEN_MSG von der ATA empfängt. In diesem Falle sendet die ATA eine ATA-RESET_MSG. Dies bewirkt, daß die ATA die Sitzung mit einer ATA_OPEN_MSG Antwort reinitialisiert. Wenn die ATA die neue Alarmtabelle von der ATAPE empfängt, vergleicht sie die Tabelle Satz für Satz mit ihrer internen (alten) Kopie der Tabelle. Unterschiede werden bemerkt und geeignet zu den MAGIC- und NAM-Anwendungen weitergeleitet. Dieser Austausch ist in Fig. 20 illustriert.
Die ATAPE verwaltet einen sehr langen Inaktivitäts- Zeitgeber an ihrem Interface mit der ATA. Der Zeitgeber ist lang genug, um die ATA-ATAPE-Sitzung über normale Verbindungsausfälle zu erhalten. Der Zweck des Zeitgebers besteht darin, daß die ATAPE-Aufgabe sich selbst löscht, wenn es nach einem hinreichend langen Intervall keine ATA gibt, mit der gesprochen werden kann. Dies begegnet der Möglichkeit, daß die ATA_DELETE_MSG von der ATA zu der ATAPE durch das Netzwerk verworfen wurde. Es begegnet ebenfalls der Lösung der Verbindung des Monitors zu dem Netzwerk für eine lange Zeitdauer (z.B. der Anwender hat sich für das Wochenende von dem Monitor abgemeldet).
Die ATAPE verwaltet auch einen Inaktivitäts-Zeitgeber an ihrem Interface zu dem ELM. Wenn der ELM nicht auf die Anfrage nach Übersichtsinformationen antwortet, wird die Anfrage einige-Male neu gesendet. Dies wird getan, weil die ATAPE die Übersichtsinformation angefordert haben kann, bevor der Schatten- ELM seine Initialisierung mit dem Master-ELM vervollständigt hat. Wenn der ELM nicht antwortet, während die ATAPE das Alarmprotokoll liest, dann wird die ATAPE-Aufgabe sich selbst auf nicht normale Weise beenden. Die ATA wird die ATAPE neu starten, wie es in dem vorstehenden Abschnitt beschrieben wurde.

3.1.3.3 Sitzungsbeendigung

Die ATA löscht die ATAPE, wenn sie von der NTA eine NTA_NODE_DELETED_MSG empfängt. Die ATA sendet eine ATA_DELETE_MSG an die ATAPE. Die ATAPE sendet die TASK_DELETE Nachricht an den OM an der CPU, auf der sie läuft, und fährt mit normaler Sitzungsverarbeitung fort. Der OM übernimmt und löscht daraufhin die Aufgabe.

3.2 ATA-Programminternas

Dieser Abschnitt beschreibt die Hauptdatenstrukturen und Verfahren, die in der ATA erzeugt werden, um die in den vorstehenden Abschnitten beschriebene Funktionalität zu erfüllen. Das ATA-Programm wurde geschrieben, um oberhalb einer IDNX-artigen Kernebene zu laufen, wie sie in der Monitorumgebung bereitgestellt wird. Alle Dienste der Systemebene, die von der Anwendung gefordert werden, werden durch diese Kernebene erhalten. Es gibt keinen statischen Speicher, der in das Programm eingebettet ist; der gesamte Datenraum wird über ReqMem () Aufrufe an die Kernebene erhalten.

3.2.1 ATA-Hauptdaten strukturen

Die Datenstrukturen sind im Anhang B definiert und werden in der folgenden Beschreibung berücksichtigt.
Die Hauptdatenstrukturen in der ATA-Anwendung sind die globalen Datenbereiche, die Knotentabelle (NT), die Sitzungskontrolltabelle (SCT) und ihr zugeordneter Sitzungskontrollblock (SCB) sowie die Netzwerkalarmtabelle (NAT).

3.2.1.1 Globaler Datenbereich

Die globale Datenstruktur ist die primäre Datenstruktur für die Anwendung. Sie enthält Zeiger (direkte und indirekte) zu allen anderen Daten, die durch die Anwendung verwaltet werden, bis auf Datenvariablen für lokale Routinen, die auf dem Stackbereich der Anwendung zugeordnet werden.
Der Zeiger für den Zeitgeberblock (ptimers) zeigt auf einen Zeitgeber auf Kernebene, der für die ATA-Anwendung verwaltet wird. Dieser Zeitgeber wird verwendet, um die Aktivität der ATAPE-Sitzung zu verwalten. Eine zugeordnete Zeitgeber-Variable (SessnTimer) ist ebenfalls in dem globalen Datenbereich definiert. Der Kern-Zeitgeber wird gestartet, wenn die Anwendung beginnt und läuft gemäß Vorgabe bei regulären Intervallen für die Lebensdauer der Anwendung ab. Jedesmal, wenn der Zeitgeber zurückgesetzt wird, wird die Zeit, zu der er abläuft, in der Variable SessnTimer gespeichert. Eine Beschreibung der Verwendung dieses Zeitgebers wird aufgeschoben, bis der Sitzungskontrollblock der ATAPE beschrieben wird.
Die anderen Variablen in dem globalen Datenbereich sind für Informationen, die die Anwendung benötigt und die im Bereich der Anwendung global sind, sowie Sitzungszeitgeberwerte, die Zahl von erneuten Versuchen, die bezogen auf die ATAPE- Sitzungen durchgeführt werden, der Zustand der NAM- und MAGIC- Anwendungen, sowie die Knotennummern für den Monitor und seinen Nachbarknoten.
Das Programm verfolgt den Zustand der Anwendungen, denen es Alarme zuführt, um zu vermeiden, daß Fehler auftreten, indem versucht wird, ihnen Nachrichten zu senden, wenn sie nicht aktiv ist. Wenn die ATA (erneut) startet, bestimmt sie den Zustand von NAM und MAGIC unter Verwendung des Kernservice Find- Task(). Wenn die Aufgabe läuft, wird der Start- Quittungsaustausch durchgeführt und die Bool'sche Variable (NamUp oder MagicUp) wird auf TRUE gesetzt. Wenn die Antwortquittung empfangen wird, fordert ATA den Kern (Kernel) auf, mitzuteilen, daß er die Anwendung beenden sollte, indem er dem Kern eine SEND_NOTIFY_MSG sendet. Der Kern sendet diese Nachricht zurück, wenn die Anwendung endet. Bevor Alarminformationen zu den MAGIC- und NAM-Anwendungen gesendet werden, konsultiert die ATA ihre entsprechenden Bool'schen Zustandsvariablen in dem globalen Datenbereich.

3.2.1.2 Knotentabelle

Die Knotentabelle (NT) assoziiert primär IDNX- Knotennummern mit einem Index in der Sitzungskontrolltabelle. Dies wird verwendet, um den geeigneten Sitzungskontrollblock abzufragen, um die Sitzung mit einer bestimmten ATAPE-Aufgabe zu verwalten.
Die Knotentabelle verfolgt außerdem den Zustand eines jeden Knotens, wobei dies nur teilweise implementiert wurde und nur einen zufälligen Teil in der Funktionalität des Programmes bedient.

3.2.1.3 Sitzungskontrolltabelle und Sitzungskontrollblock

Die Sitzungskontrolltabelle ist ein Array fester Länge von Sitzungskontrollblöcken. Der Sitzungskontrollblock ist die steuernde Datenstruktur für eine bestimmte ATAPE-Sitzung.
Die ATAPE-Sitzungen sind zustandsgetrieben und die SCB- Variable, Sessnsts, definiert den gegenwärtigen Zustand für eine ATAPE. Wenn die ATA eine ATAPE-Sitzung unterbricht, weil eine NODE_DOWN Nachricht von der NTA empfangen wurde, dann wird der aktuelle Status in der SCB-Variable, Sessnpendsts zwischengespeichert und die Sessnsts wird gesetzt, um einen unterbrochenen Sitzungszustand anzuzeigen. Die möglichen Sitzungszustände sind:
NULL_SESSN während einer Fehler-Wiederherstellung verwendeter Zustand, wenn eine ATAPE-Aufgabe gelöscht wurde und nach einem kurzen Intervall erneut erzeugt werden soll.
DORMANT_SESSN Zustand zwischen der Erzeugung einer ATAPE-Aufgabe und einer Sitzungsinitialisierung.
OPENING_SESSN Zustand während die ATA darauf wartet, daß die ATAPE auf die OPEN_MSG antwortet.
ACTIVE_SESSN Zustand während dessen die ATA erwartet, von der ATAPE Alarm- und Leermeldungen zu empfangen.
SUSPENDED_SESSN Zustand während dem die Sitzung unterbrochen wurde, wobei eine Wiederverbindung zu dem ATAPE-Knoten ansteht.
Es gibt eine Anzahl von Variablen in dem SCB, die verwendet werden, um die Sitzung zu kontrollieren, so wie die Knotennummer, auf dem die ATAPE residiert, der zur Fehlerwiederherstellung verwendete Wiederholzähler und der Zähler für aktuelle Sitzungsnachrichten, der verwendet wird, um außer Reihenfolge befindliche Nachrichten zu detektieren.
Die SCB-Zeitgeber-Variable wird verwendet, um die verschiedenen Sitzungs-Startläufe und Fehlerwiederherstellungsaktivitäten zu treiben, die die ATA durchführt während die ATAPE- Sitzungen verwaltet werden. Wenn eine spezielle Aktivität (so wie das Senden der ATA_OPEN_MSG) erfolgen soll, setzt die ATA die SCB-Zeitgeber-Variable. Dann überprüft die ATA die Zeitgebervariable für die gesamte Sitzung in dem globalen Datenbereich, um zu bestimmen, wann der Sitzungs-Zeitgeber abläuft. Wenn dieser vor dem ATAPE-Zeitablaufwert abläuft, dann ist nichts zu tun. Wenn der Sitzungs-Zeitgeber nach dem ATAPE- Zeitablaufwert abläuft, dann setzt die ATA den Sitzungs- Zeitgeber so, daß er zu der früheren Zeit abläuft. Wenn der globale Sitzungs-Zeitgeber abläuft, tastet die ATA jeden ATAPE- Zeitgeberwert ab, um zu bestimmen, welche ATAPE-Sitzung eine durchzuführende Aktivität erfordert.
Es gibt drei miteinander verbundene Listen, die in dem SCB definiert sind, um eingehende Alarmnachrichten von den ATAPE- Auf gaben und abgehende Alarmnachrichten zu den MAGIC- und NAM- Aufgaben zwischenzuspeichern. Die ATA muß einen ganzen Schnappschuß der Alarmtabelle verarbeiten, bevor die Alarminformation an MAGIC und NAM weitergegeben wird. Die Risiken, daß dies nicht getan wird, stehen in Beziehung zu der Architektur und dem Algorithmus, die von dem ELM verwendet werden, um dessen Alarmtabelle zu verwalten. Die Symptome, die daraus resultieren würden, daß nicht auf diese Weise zwischengespeichert wird, könnten redudante und fehlerhafte Informationen sowohl für NAM als auch für MAGIC beinhalten.
Die SCB-Variable AlarmTblLen wird verwendet, um eine variable Alarmtabellengröße über dem IDNX-Netzwerk unterzubringen. Obwohl die Alarmtabelle eine feste Größe aufweist, ist vorhergesehen worden, daß die Alarmtabellengröße vergrößert wird, um die Anforderungen von größeren, komplexeren Netzwerken zu erfüllen. Wenn dies getan wird, ist es für ATAPE-Aufgaben auf unterschiedlichen Maschinen möglich, Alarmtabellen unterschiedlicher Größe zu überwachen. Die ATAPE berichtet daher die Größe der Alarmtabelle während der Sitzungsinitialisierung an die ATA als Teil des ATA_OPEN_MSG Quittungsaustausches. Diese Größe bestimmt die Länge der ATA-Kopie der Alarmtabelle (NAT - dies wird nachfolgend diskutiert) und die maximale Zahl von Alarmnachrichten, die die ATA in einem einzigen Schnappschuß der Alarmtabelle von der ATAPE zu empfangen erwartet (SCB- Variable MaxAlarmMsgs).
Auf die Netzwerkalarmtabelle für eine gegebene ATAPE wird durch die SCB-Variable pNat gezeigt. Diese Tabelle wird in dem nächsten Abschnitt diskutiert.

3.2.1.4 Netzwerkalarmtabelle

Die Netzwerkalarmtabelle (NAT) enthält ein Bild der relevanten Alarminformation, die in der ELM-Alarmtabelle verwaltet wird. Es gibt eine NAT pro ATAPE.
Jeder Satz in der Tabelle enthält eine Zustandsvariable, die verwendet wird, um aktive von inaktiven Alarmen zu unterscheiden und festzustellen, ob das erste Bild des ELM- Alarmprotokolls von der ATAPE empfangen wurde. Den Pegel des Alarms (inaktiver Alarm oder die Bedeutung eines aktiven Alarms), den Alarmsatz in AtaAlarmEntry-Format, sowie zwei Zeiger, die verwendet werden, um eine Serie von verknüpften Listen von Alarmsätzen zu verwalten, die durch die NAT-Struktur gewunden sind.
Die ATA verwaltet ein Bild der Alarmtabelle und keine Liste von aktiven Alarmen, was sowohl während der Implementierung als auch während der Ausführung nützlich ist. Aktualisierungen für die NAT werden erreicht, indem direkt der Alarmtabellenindex verwendet wird, der in den ATAPE-Sätzen ATA_ALARM_MSG bereitgestellt wird.
Die Zeiger für die verbundenen Listen in dem NAT-Satz werden verwendet, um alle Alarme für ein gegebenes Netzwerkgerät miteinander zu verknüpfen. Der erste Alarrnsatz in einer beliebigen Liste repräsentiert den am meisten kritischen Alarm für dieses Gerät. Aktualisierungen für die NAT haben nicht nur eine Überprüfung der Alarminformation sondern auch der Zeiger für die Verbindungsliste bezogen auf die anderen Alarme in der Tabelle für das bestimmte Geräte zur Folge. Die durch die Listen und die für deren Verwaltung erforderliche Logik eingeführte Komplexität beschleunigt die Verteilung von Alarmen zu MAGIC. Allgemein wird ein Alarm an MAGIC gemeldet, wenn er sich an der Spitze einer verknüpften Liste befindet oder zuvor aktiv war und nun gelöscht wurde.
Die ATA muß erkennen, wenn ein aktiver Alarmsatz zugunsten eines kritischeren Alarms von der Alarmtabelle gestoßen wurde. Dieser Alarm kann für dasselbe Gerät sein, muß es aber nicht. In den meisten Fällen muß ATA dies als die Entfernung (oder Löschung) eines Alarms und die Hinzufügung eines neuen Alarms interpretieren und die Ergebnisse geeignet an MAGIC und NAM melden.

3.3 ATAPE-Programminternas

Dieser Abschnitt beschreibt die Hauptdatenstruktur und -routinen, die in der ATAPE erzeugt werden, um die in den vorstehenden Abschnitten beschriebene Funktionalität auszuführen.

3.3.1 ATAPE-Hauptdatenstrukturen

Die Datenstrukturen sind im Anhang C definiert und werden in der folgenden Beschreibung erwähnt.
Die Hauptdatenstrukturen in der ATAPE-Anwendung sind der globale Datenbereich, der Sitzungskontrollblock SCB, der ELM- Kontrollblock ECB und die Alarmtabelle AT.

3.3.1.1 Globaler Datenbereich

Die globale Datenstruktur ist die primäre Datenstruktur für die ATAPE. Sie enthält Zeiger direkt und indirekt zu allen anderen Daten, die durch die Anwendung verwaltet werden, außer zu Datenvariablen von lokalen Routinen, die auf dem Stack der Aufgabe zugeordnet sind.
Die Zeitgeberblockvariable ptimers zeigt auf einen Block von Zeitgebern, die von dem Kern für die ATAPE-Aufgabe verwaltet werden. Die ATAPE hält vier Zeitgeber:
SessnWatchdog wird verwendet als lange Zeitabschaltung bei der ATA-ATAPE-Sitzung. Wenn er abläuft, sendet die ATAPE der ATA eine Alarmnachricht (leer, wenn es keine Alarmänderungen gibt), um eine Antwort von der ATA zu erbitten. Der Zeitgeber wird dann zurückgesetzt. Wenn er erneut abläuft, löscht die ATAPE sich selbst.
SessnIdle wird verwendet, um zu bestimmen, wann eine Antwort zu der ATA gesendet werden muß, um eine Zeitabschaltung des Sitzungsinterfaces zu vermeiden. Wenn dieser Zeitgeber abläuft, wird entweder eine Leer- oder eine Alarmänderungsnachricht gesendet.
ElmWatchdog wird verwendet, um eine Situation ohne Antwort mit dem ELM zu bestimmen.
ElmPoll wird verwendet, um die Alarmübersichtsanfragen in regulären Abständen zu treiben.
Die Datenstrukturen SCB, ECB und AT werden hierauffolgend diskutiert
Die Variable Alarrnspending ist ein Flag zwischen der ELM- Interfacelogik und der ATA-Interfacelogik, um anzuzeigen, daß geänderte Alarme für die ATA anstehen. Die Variable Chngd- AlarmCnt zeigt die Anzahl von Alarmsätzen an, die sich geändert haben.
Die Semaphore AtLocked wird von der ELM-Interfacelogik verwendet, um das Aussenden von Änderungen in der Alarmtabelle zu verhindern, bis eine konsistente Kopie erhalten wurde. Wenn die ATA-Interfacelogik detektiert, daß Alarmänderungen aufgetreten sind (AlarmsPending), wird sie versuchen, eine Alarmnachricht zu senden. Wenn die Semaphore Atlocked gesetzt ist, wird eine leere Alarmnachricht erzeugt.

3.3.1.2 Der Sitzungskontrollblock

Der Sitzungskontrollblock enthält alle Variablen, die nötig sind, um das ATA-ATAPE-Sitzungsinterface zu verwalten.
Das Sitzungsinterface ist zustandsgetrieben. Die möglichen Zustände sind:
DORMANT_SESSN Zustand nach dem Hochlaufen des ATPE und bevor sie eine ATA OPEN MSG von der ATA empfängt
OPENING_SESSN Zustand nachdem die ATAPE die ATA_OPEN_MSG empfangen hat und bevor sie die erste ATA- NEXT-MSG von der ATA empfängt.
IDLING_SESSN Zustand, wenn keine Alarmänderungen auszusenden sind.
ALARMING_SESSN Zustand, wenn entweder Alarmänderungen zu senden sind oder der SeenWatchdog- Zeitgeber abgelaufen ist und eine Nullalarmnachricht gesendet wurde. In jedem Fall wird eine Antwort von der ATA erwartet.
Die anderen Variablen in dem Sitzungskontrollblock steuern die Nachrichtenabfolge und Nachrichtenzwischenspeicherung, die erforderlich ist, um die bereits beschriebene Funktionalität zu erreichen

3.3.1.3 Der ELM-Kontrollblock

Der ELM-Kontrollblock ECB kontrolliert das Interface zu der ELM-Aufgabe. Dieses Interface ist zustandsgetrieben und die beiden Zustände (POLLING_SUMMARIES und READING_ALARMS) definieren, ob die ATAPE zyklisch Übersichten abfragt (Warten auf Alarmänderungen) oder die Alarmtabelle liest und Änderungen in ihrer lokalen Alarmtabelle aufnimmt.
Die Variablen Totalalarmcnt und ActiveAlarmCnt reflektieren die letzte Alarmübersichtsinformation, die von dem ELM empfangen wurde, und werden mit dem nächsten Satz von Übersichtsinformationen verglichen, um Änderungen in der Alarmtabelle zu detektieren. Dieser Untersatz der ELM-Übersichtsinformation reicht aus, um alle neuen, geänderten und gelöschten Alarme in der ELM-Alarmtabelle zu detektieren.
Die Zeigervariable pReqSummMsg wird verwendet, um den Nachrichtenzwischenspeicher zu verfolgen, der verwendet wird, um die Alarmtabelle zu lesen. Dieselbe Nachricht, die von der ATAPE gesendet wurde, wird durch den ELM zurückgesendet und von der ATAPE wieder gesendet, bis die gesamte Alarmtabelle geschrieben ist.
Die Variablen ReqAlarmBlk und RetryCnt werden verwendet, um Fehler zu detektieren und eine Wiederherstellung von Fehlern bei dem Austausch mit dem ELM zu erreichen.
Die Variable ElmTid identifiziert mit welchem ELM (Master oder einer von mehreren möglichen Schatten-ELMs) die ATAPE kommuniziert.

3.3.1.4 Die Alarmtabelle

Die Alarmtabelle (AT) enthält ein Bild der relevanten Alarminformation, die in dem ELM-Alarmprotokoll enthalten ist. Es enthält ebenfalls ein Flag in jedem Alarmsatz, das anzeigt, ob der Alarmsatz sich geändert hat, seit der letzte Schnappschuß genommen und dem Sitzungsinterface zugeleitet wurde.

VIII. Konstruktion der Monitordatenbankanwendung

1. Einleitung

Die DBA ist verantwortlich für die Verwaltung von akkuraten Informationen über IDNX-Konfigurationsdatenbanken und den Echtzeit-Verbindungsstatus in dem Netzwerk. Sie empfängt die physikalischen Datenbankblöcke von der APE (angeschlossene Prozessor-Ausführungseinheit) und übersetzt diese Informationen in DBMS (ORACLE)-Anfragen, d.h. gibt den physikalischen Blöcken logische Bedeutungen.
Fig. 21 ist ein Blockdiagramm der Anwendungen und des Datenflusses während eines Hochladens einer Datenbank von einem IDNX-Knoten zu dem Monitorknoten. Der Monitorknoten beinhaltet die Datenbankanwendung DBA 2100, ein DBA-Übersetzungsmodul 2101 und die Monitordatenbank, die auf ORACLE 2102 basiert. Darüber hinaus befindet sich an dem Monitorknoten die Netzwerktopologieanwendung NTA 2103. An jedem der IDNX-Vermittlungsknoten, die in dem Netzwerk verteilt sind, gibt es eine an die Datenbankanwendung angeschlossene Prozessor-Ausführungseinheit DBAPE 2104, die IDNX-Knotendatenbank DBC 2105 und eine IDNX- Kommunikationsaufgabe 2106, die in Echtzeit Verbindungsinformationen erzeugt.
Die IDNX-Datenbank DBC besteht aus einer Vielzahl von 128- Byte-Blöcken und Kontrollsummen für Daten, die in den Blöcken enthalten sind. Der Betrieb der Anwendungen, die wie in Fig. 21 gezeigt laufen, wird unten beschrieben.

2. Erhalten der Daten

Die DBA muß Datenbanken hochladen und akzeptiert Änderungen an Datenbanken auf solch eine Weise, um einen Nachrichtenüberlauf an dem IDNX-Knoten zu verhindern, an den der Monitor angeschlossen ist. Sie kann mit den Knoten in dem Netzwerk seriell oder parallel arbeiten. Das aktuelle Protokoll und die aktuellen Nachrichten sind unten beschrieben. Das Protokoll erlaubt eine effiziente Verwendung von Bandbreiten und IDNX- Resourcen.
Die DBA muß von der Netzwerktopologieanwendung (NTA) benachrichtigt werden, wenn Knoten, die zu überwachen sind, von dem Monitor abgeschnitten werden, und dann wieder, wenn sie wieder erreichbar sind. Dies beinhaltet Versagen der Verbindung zwischen dem Monitor und der IDNX, die DBA muß zuerst über das Versagen informiert werden und dann wieder, wenn die Verbindung wieder zum Stehen kommt.
Die DBA muß Kontinuität selbst während DBA- Zusammenbrüchen, Monitor-Zusammenbrüchen und sogar bei IDNX- Knotenzusammenbrüchen bewahren.

3. Übersetzung der Daten

Die Übersetzung von der physikalischen Datenbank in das DBMS-Format ist ein Prozeß mit zwei Schritten, zuerst von phyikalischen Blöcken in logische Einheiten und zweitens von den logischen Einheiten in DBMS-Tabelleneinträge. Um die Daten zu übersetzen, muß die DBA eine Kopie der physikalischen Datenbank eines Knotens zu allen Zeiten als Referenz halten, um Änderungen zu detektieren.
Der Schlüssel hier besteht darin, den Aufwand bei der Übersetzung begrenzen zu können, wenn sich nur ein paar Blöcke ändern. Der Übersetzungsprozeß bei Schritt 2 ist es, wo dies erreicht werden kann.
Der aktuelle Übersetzungsprozeß verwendet die IDNX- Strukturen, um das physikalische Layout der Datenbank zu definieren. Die eingehenden Datenblöcke von dem Knoten werden mit der Kopie der Datenbank verglichen, die lokal gehalten wird, und der Ort der geänderten Bytes wird auf die IDNX-Strukturen abgebildet. Daraus geht hervor, welche logischen Änderungen gemacht wurden und ein spezieller Code zur Handhabung eines jeden Typs von logischer Änderung wird aufgerufen, um die Übersetzung in DBMS SQL Daten zu bewirken. Da bestimmte Werte in einigen logischen Satzfeldern in Abhängigkeit von anderen Feldern unterschiedliche Bedeutungen haben (z.B. das Statusfeld eines Kartensatzes hängt von dem Kartentypfeld ab), ist die Abbildung von physikalisch auflogisch nicht trivial.

4. Interface zu anderen Monitoraufgaben

Die Netzwerktopologieanwendung (NAT) ist dafür verantwortlich, der DBA Knoten-Ein- und Knoten-Aus-Ereignisse mitzuteilen. Wenn die DBA ein Knoten-Ein-Ereignis empfängt, erzeugt sie entweder eine DBAPE auf dem Zielknoten und erhält die anfängliche Kopie der Datenbank für den Knoten oder sie prüft mit der DBAPE Änderungen an der Datenbank des Knotens. Wenn Änderungen detektiert werden, sendet die DBA eine Nachricht zu der NTA, die anzeigt, daß die Knotendatenbank sich geändert hat und daß ein Hochladen erfolgen wird. Nach dem (möglicherweise auch nicht) Hochladen der Datenbank sendet die DBA eine Nachricht zu der NTA, die anzeigt, daß die Initialisierung beendet ist. Funktional bedeutet dies, daß die DBMS-Datenbank an dem Monitor vollständig aktualisiert wurde und für den Knoten in einem gültigen Zutand ist. Nur dann teilt die NTA den anderen Monitoraufgaben mit, daß der Knoten "ein" ist.
Wenn eine Änderung an einer Knotendatenbank von der DBA aufgenommen wurde, muß sie eine Nachricht an MAGIC (das Graphikinterface zu dem Anwender) senden, die die geänderten Daten anzeigt, um das Benutzerinterface aktualisiert zu halten. Wenn die DBA Änderungen an der DBMS vornimmt, verfolgt sie die Änderungen und wenn diese beendet sind, informiert sie MAGIC mit von MAGIC definierten Nachrichten, Objekte hinzuzufügen, zu löschen und zu modifizieren.

5. DBA-Datenstrukturen

Die DBA verfolgt die Knotendaten in einer verknüpften Liste von Knotenstrukturen, die schematisch in Fig. 22 illustriert ist. Wenn eine Nachricht von NTA ankommt, einen neuen Knoten 2201 hinzuzufügen, wird eine neue Datenstruktur 2202 zugewiesen und zu der Liste hinzugefügt. Wenn später NTA eine Nachricht zum Löschen eines Knotens 2203 sendet, werden dessen Daten 2204 von der Liste gelöscht, und die Zuordnung wird weggenommen. Die Anzahl von Knoten, die die Anwendung handhaben kann, ist daher nur durch die Menge an verfügbarem Speicher begrenzt, es gibt keine festverdrahteten Grenzen. Die Knotenstruktur besteht aus Kontrollsummen 2205, Datenbankblöcken 2206, anhängigen Blöcken 2207 und verschiedenen DBA-Daten 2208 und ORACLE-Daten 2209. Die Datenbankblöcke bestehen aus all den Datenbankblöcken der Knotendatenbank sowie den Echtzeitdaten (in Blockformat). Die Kontrollsummen sind die Kontrollsummen für jeden dieser Blöcke. Der Bereich der anhängigen Blöcke besteht aus einer Liste von Blocknummern, Blockdaten und Kontrollsummen für Blöcke, die empfangen aber noch nicht verifiziert worden sind. Um verifiziert zu werden, muß die nächste Gruppe von Blöcken oder eine "alles okay"-Nachricht von der APE ankommen. Sobald Blöcke verifiziert wurden, werden sie in den Datenbankblockbereich transferiert und die Kontrollsummen werden aktualisiert. Der vermischte Bereich für ORACLE wird verwendet, um eine ORACLE-Kontrollsumme und Tabellenindices (für die Wirksamkeit) zu halten. Der vermischte Bereich für DBA enthält die Knotennummer, den Knoten ein/aus Zustand, einen Zeiger zu der zuletzt gesendeten ITC-Nachricht, Zeitgeberzähler und 'ack'-Ausfälle.
Sobald die APE das Hochladen der Daten beendet hat, sendet sie eine "all ok"-Nachricht. Dies triggert die DBA, mit der Übersetzung (Block 2101) der Daten in die DBMS zu beginnen. Wenn diese Übersetzung beendet ist und die DBMS 2102 erfolgreich aktualisiert wurde, werden die Knotendaten als der letzte bekannte stabile Zustand des Knotens auf Platte gespeichert. Eingehende Änderungen werden im RAM vorgenommen und wenn sie beendet sind, wird das RAM-Bild des Knotens mit dem Platten- Bild (das die Information in der DBMS reflektiert) verglichen, um für die Übersetzung die Unterschiede zu finden. Das Plattenbild wird ebenfalls verwendet, um eine Wiederherstellung nach Systemzusammenbrüchen zu erreichen. Die ORACLE-Kontrollsumme wird verwendet, um gegen die DBMS-Änderung zu schützen (von einem Crash oder einer erneuten Initialisierung), während der Plattenteil sich nicht ändert. Wenn dies geschieht, stimmt die in dem Plattenteil gehaltene ORACLE-Kontrollsumme nicht mit der Kontrollsumme überein, die in ORACLE gehalten wird, und ein vollständiges Neuladen der DBMS von lokalen Daten wird ausgelöst.

6. Die Datenbank Ape

Die Datenbank APE (DBAPE) ist das Surrogat der Monitordatenbankanwendung in der IDNX-Welt. Sie läuft auf derselben CPU wie die IDNX DBC-Aufgabe, die für die IDNX-Datenbank verantwortlich ist. Die CPU ist die Coprozessor-CPU, falls eine verfügbar ist, kann aber die Master-CPU sein, wenn keine andere existiert, so daß die DBAPE in einem "COPROCESSOR PREFERRED"- Modus läuft.
Die APE hat drei Hauptdatenstrukturen, die in Fig. 23 bei Block 2301 dargestellt sind. Eine ist der Satz von allen kürzlich bestätigten Kontrollsummen 2302, die sie zu der Monitor- DBA geschickt hat. Die nächste ist eine Liste von Blöcken (verschmutzte Flags 2302), die in die Monitor-DBA hochgeladen werden müssen. Die letzte ist ein Satz von Echtzeitdaten 2304, die als ein Ergebnis von Verbindungsstatusänderungen von den Verbindungsaufgaben 2307 empfangen werden. Diese Echtzeitdaten sind in für die Datenbank in der Größe angepaßte Blöcke gepackt, Kontrollsummen 2306 werden berechnet und danach werden die Blöcke als "zusätzliche" physikalische Datenbankblöcke behandelt.

7. Datenbankinitialisierung und Reinitialisierung

Wenn die APE hochläuft, wird der Satz von allen Echtzeitinformationen initialisiert und die Liste von Blöcken, die hochgeladen werden müssen (die "schmutzigen" Blöcke) wird gelöscht. Die APE wartet dann während sie beliebige Echtzeitdaten sammelt, bis eine Nachricht von der Monitor-DBA empfangen wird.
Die APE liest die DBC-Datenblöcke und Kontrollsummen direkt aus dem Speicher, was keine formale Interaktion mit der DBC selbst ist, und die Echtzeitdatenblöcke werden von ihren eigenen internen Datenstrukturen gelesen. Wenn eine Anfrage nach Initialisierung ankommt, werden die Datenblöcke alle für ein Hochladen markiert, und dann gepackt und zu der DBA gesandt. Wenn eine Anfrage nach Änderungen ankommt, werden die DBA-Kontrollsummen mit den DBC-Kontrollsummen (und Echtzeitkontrollsummen) verglichen, die Datenblöcke, deren Kontrollsummen abweichen, werden für ein Hochladen markiert, und dann werden alle für ein Hochladen markierten Blöcke (entweder von dieser Sitzung oder einer nicht beendeten vorherigen) gepackt und zu der DBA gesendet.

8. Datenbankänderungen

Wenn Änderungen an der IDNX-Datenbank oder den Echtzeitinformationen erfolgen, kann die APE eine Änderungsmeldung für die DBA initiieren. Alle 20 Sekunden vergleicht die APE Kontrollsummen und markiert beliebige geänderte Blöcke als "schmutzig" (Zeilen 2305). Änderungen von Echtzeitinformationen werden direkt von den IDNX-Kommunikationsaufgaben 2307 zu der APE gesendet. Wenn Änderungen gefunden werden, können die Blökke zu der DBA gesendet werden. Dies kann jedoch nur passieren, wenn es keine ausstehenden Nachrichtenübertragungen gibt, die gerade erfolgen, um ein Überfluten des Netzwerkes mit Nachrichten zu verhindern. Nur eine ausstehende Nachricht z. Zt. ist erlaubt. Wenn keine Antwort empfangen wird, dürfen keine weiteren Nachrichten gesendet werden, bis Kontakt mit der DBA wiederhergestellt wird.

9. Nachrichten und Protokolle

Die Nachrichten und Protokolle sind ausgelegt, daß sie den Nachrichtenverkehr über dem Netzwerk sowie die Zeit und die in der IDNX verwendeten Resourcen minimieren.
Es gibt drei Nachrichten von der DBA an die DBAPE. Jeweils eine triggert (möglicherweise) einen Fluß von Datenpaketen von der APE. Im Falle von Änderungen an der IDNX-Datenbank kann dieser Transfer durch die APE initiiert werden, jedoch immer mit einem bestätigenden (Acking) Protokoll, das eine Flut von Nachrichten für die DBA verhindert. Es gibt drei Nachrichten von der DBAPE zurück zu der DBA. Alle Nachrichten starten mit einem ITC-Nachrichtenvorsatz.
Die unten zu findenden Paketforrnate erlauben mehr als 255 128 Byte-Blöcke pro Datenbank. Die Blocknummern sind in einer 'short' und nicht in einer 'char' enthalten. Die Freigabe '7' Datenbank hat bereits nahezu 250 Blöcke und die Echtzeitdaten verwenden zwei zusätzliche Blöcke, so daß diese Vorsichtsmaßnahme vernünftig erscheint.

APE-Interface:

Drei Arten von Nachrichten werden von der APE zu der Anwendung gesendet - etwas hat sich geändert, nichts hat sich geändert (keine weiteren Änderungen), und DBC hat versagt (nur zur Information).
Die manderungs'-Nachricht wird entweder in Antwort auf eint ne Anfrage von der Anwendung gesendet oder durch die APE initiiert, wenn Änderungen in der IDNX-Datenbank detektiert werden. Sie beinhaltet die Nachrichtenaustauschnummer (0, wenn die APE initiiert), die gesamte Anzahl von Blöcken, die sich geändert haben, die Anzahl von Blöcken in dieser Nachricht, die Blockzahlen, ihre Kontrollsummen und ihre Daten.
Die "keine Änderungen"-Nachricht wird in Antwort auf eine Anfragen von der Anwendung nur gesendet, wenn es keine Änderungen in der Datenbank gibt, oder als letzte Meldung, nachdem Änderungen gesandt wurden, um anzudeuten, daß es keine weiteren Änderungen gibt und daß die Daten konsistent sind. Sie beinhaltet die Nachrichtenaustauschnummer und die aktuelle globale Datenbank-Kontrollsumme.
Die 'DBC hat versagt'-Nachricht wird in Antwort auf eine Anfrage oder durch die APE gesendet, wenn ein DBC-Versagen detektiert wurde. Sie beinhaltet nur die Nachrichtenaustauschnummer.

DBA-Interface:

Drei Arten von Nachrichten werden von der Anwendung zu der APE gesendet - eine Bestätigung eines empfangenen Datenpaketes, eine Anfrage, die gesamte IDNX-Datenbank hochzuladen und eine Anfrage nach Änderungen in der Datenbank.
Die 'ack'-Nachricht wird in Antwort auf ein Datenpaket (manderungen'-Nachricht) von der APE gesendet. Sie beinhaltet die Nachrichtenaustauschnummer, die die Anwendung erwartet, und die Anzahl von Blzcken, die Blocknummer, und die Block- Kontrollsummen der APE-Nachricht, die sie bestätigt.
Die 'sende alles'-Nachricht wird zu der APE gesendet, wenn die Anwendung keine Kopie der IDNX-Datenbank hat ('havedata' ist FALSE). Dies fordert die APE dazu auf, alle Datenbankblöcke hochzuladen. Sie beinhaltet nur die Nachrichtenaustauschnummer, die die Anwendung erwartet.
Die 'sende Änderungen'-Nachricht wird zu der APE gesendet, wenn die Anwendung eine Kopie der IDNX-Datenbank hat ('havedata' ist TRUE), und Änderungen aktualisieren will. Die APE wird aufgefordert, nur Blöcke hochzuladen, die sich geändert haben. Sie beinhaltet die Nachrichtenaustauschnummer, die die Anwendung erwartet, die globale Datenbank-Kontrollsumme und die Blockkontrollsummenwerte der Anwendung.

NTA-Interface:

Drei Arten von Nachrichten werden von der Anwendung zu der NTA gesendet - eine Rücksetznachricht, wenn die Anwendung sich zurückgesetzt hat und wissen muß, welche Knoten in dem Netzwerk sind, eine Nachricht, daß die Datenbank gültig ist, wenn die APE das Hochladen und Übersetzen der Daten für einen Knoten beendet hat, und eine Nachricht, daß die Datenbank sich geändert hat (Änderungen), wenn die APE detektiert, daß eine Datenbank eines Knotens sich geändert hat und hochgeladen werden muß.
Die 'nta'-Nachricht wird für alle NTA-Nachrichten verwendet. Sie besteht nur aus einem 'data'-Feld, das die IDNX- Knotennummer für eine 'gültige' oder 'geänderte' Nachricht enthält. Dieses Feld ist für die 'Rücksetz'-Nachricht undefiniert.
Diese Nachrichten werden von der NTA erwartet:
Die NTA_ALL_NODE_UP_MSG alarmiert die DBA, daß ein spezifischer Knoten eingeschaltet und erreichbar ist.
Die NTA_NODE_DOWN_MSG alarmiert die DBA, daß ein spezifischer Knoten abgeschaltet oder unerreichbar ist.
Die NTA_NODE_DELETED_MSG alarmiert die DBA, daß ein spezifischer Knoten von der Monitordomäne entfernt wurde.
Die NTA_HDLC_LINK_DOWN alarmiert die DBA, daß die HDLC- Verbindung ausgefallen ist.
Die NTA_ALL_LINK_UP_MSG alarmiert die DBA, daß die HDLC- Verbindung eingeschaltet ist.
Die NTA_ALL_NODES_IN_NET_MSG gibt Informationen über alle Knoten, die in der Monitordomäne eingeschaltet sind.
Die NTA_RESET_MSG alarmiert die DBA, daß die NTA zurückgesetzt wurde.

10. Nachrichtenprotokolle

Da die Nachrichten, die zwischen der DBA und ihrer APE hin- und hergehen, auf der Datagrammebene erfolgen, müssen gesonderte Protokolle verwendet werden, um sicherzustellen, daß Nachrichten in Reihenfolge oder sogar daß Nachrichten überhaupt ankommen. Das DBA-DBAPE-Protokoll beschäftigt sich mit dem Nachrichtenlieferproblem, indem es erfordert, daß Nachrichten entweder durch eine spezifische 'ack'-Nachricht von der DBA oder durch eine Antwort von der DBAPE bestätigt werden. Ein anderes Problem liegt darin, daß Nachrichten in dem Netzwerk verzögert werden können. Eine frühere Nachricht kann nach einer später gesendeten ankommen und möglicherweise alte oder nicht mehr aktuelle Neuigkeiten bringen.
Um sicherzustellen, daß die Datenbank jeweils den korrekten und aktuellen Status der Knoten reflektiert, verwendet das Nachrichtenaustauschprotokoll, das zwischen der DBA und ihrer APE verwendet wird, ein Signaturbyte (das Exchangenum), um sicherzustellen, daß alte Nachrichten nicht beachtet werden. Das Exchangenum ist eine Bytegröße ohne Vorzeichen, die von 1 nach 255 umläuft und dann zurück nach 1 geht (null wird übersprungen). Der spezielle Wert null wird für nicht abgerufene Nachrichten von der APE reserviert. Das Exchangenum wird inkrementiert, wenn diese Nachricht empfangen wird und ansonsten nur, wenn ein Fehler in einem Nachrichtenaustausch auftaucht.
Wie es in Fig. 23 illustriert ist, verfolgt die DBA das Exchangenum, das es zu empfangen erwartet. Die APE schickt nur zurück, was ihr zugesandt wurde. Dies vereinfacht die Synchronisierung für den Fall, daß die APE oder die DBA zusammenbricht. Deshalb setzt die APE, wenn sie die Nachricht initiiert, das Exchangenum auf null (Fig. 25), da sie das zu verwendende Exchangenum nicht kennt.
Wenn z.B. Nachrichten übertragen werden und das aktuelle Exchangenum 22 ist und eine 'ack'-Nachricht von der DBA zu der APE in dem Netzwerk verzögert wird, könnte die DBA eine Zeitabschaltung vornehmen und das 'ack' zurücksenden. In diesem Fall wird das Exchangenum für das neue 'ack' auf 23 inkrementiert. Wenn beide Nachrichten von der APE empfangen werden, wird eine Antwort für jede zurückgesandt. Nur die Antwort mit dem Exchangenum von 23 wird von der DBA akzeptiert, die mit 22 wird nicht beachtet (siehe Fig. 26 - 30).

11. Protokoll

Während normalem Betrieb sendet die DBA eine 'Sende Änderungen'-Nachricht zu der APE mit einer vollständigen Liste von Kontrollsummen. Die APE vergleicht die Kontrollsummen mit den DBC-Kontrollsummen und den Echtzeit-Kontrollsummen und beginnt damit, die geänderten Blöcke hochzuladen. Jede Hochladenachricht enthält bis zu sechs Datenbankblöcke, ihre Nummern und ihre Kontrollsummen. Nach Empfang der Änderungen bestätigt die DBA die Nachricht, indem die Blocknummern und Kontrollsummen zurückgesendet werden, die sie empfangen hat. Die Daten werden in dem anhängigen Bereich gehalten. Die APE empfängt das 'ack' und verwendet die Kontrollsummen in der 'ack'-Nachricht, um seinen Kontrollsummenbereich zu aktualisieren. Dies stellt sicher, daß ihre Idee von den bekannten Kontrollsummen und den der DBA bekannten dieselbe ist. Das Empfangen des 'ack' macht die APE frei, den nächsten Stapel von geänderten Blöcken zu senden. Wenn diese nächste Nachricht von der DBA empfangen wird, werden die in dem anhängigen Bereich gehaltenen Blöcke für gültig angenommen und in den Hauptdatenbankblockbereich geladen. Die neuen Blöcke nehmen ihren Platz in dem abhängigen Bereich ein und werden wie zuvor bestätigt. Dies geht so weiter, bis eine 'all ok'-Nachricht von der APE empfangen wird. Die anhängigen Daten werden in den Hauptbereich geladen und die Übersetzungsroutinen werden aufgerufen. Die aktuellen Zahlen für ein vollständiges Hochladen eines Knotens sind: 252 Datenbank- und Echtzeitblöcke bei 6 Blöcken pro Nachricht, oder 42 Nachrichten.
Wenn die Kommunikation schwierig ist (viele Verluste oder verzögerte Pakete), wird die DBA weiterhin versuchen, Nachrichten zu dem Knoten zu senden, solange die NTA noch anzeigt, daß der Knoten eingeschaltet ist. Nach jeweils drei erneuten Versuchen wird sie sich bemühen, die APE erneut zu starten. Die APE wird sich selbst töten, wenn der Kontakt zu dem Monitor für mehr als 40 Minuten verlorengegangen ist.

12. Szenarios

Während normalem Betrieb kann es mehrere pathologische Zustände geben. Dieser Abschnitt beschreibt, wie das Protokoll diese Situationen handhabt.

12.1 Der Monitor oder die DBA bricht zusammen

Die DBA rettet die Knotendaten nach jedem erfolgreichen Hochladen auf Platte. Nach einem Zusammenbruch werden die Daten von der Platte für die zuletzt bekannte stabile Konfiguration wiederhergestellt. Dann sendet die DBA 'sende Änderungen"- Nachrichten an alle erreichbaren APES und nur geänderte Blöcke werden hochgeladen. Wenn die NTA der DBA neu konfigurierte Knoten mitteilt, sendet die DBA 'sende alles'-Nachrichten zu diesen Knoten, um ihre gesamte Datenbank hochzuladen. Die DBA versucht nicht, Knoten zu erreichen, die gegenwärtig ausgeschaltet sind.

12.2 Der Verbindungszustand oder der Knotenzustand ändert sich

In diesem Fall informiert die NTA die DBA über Zustände bezüglich Verbindung unten und nicht oben und/oder Knoten unten und nicht oben. Die DBA markiert den Knoten oder die Knoten als aus und versucht nicht, diese Knoten zu erreichen. Wenn ein "oben" Zustand von der NTA empfangen wird, sendet die DBA geeignete 'sende Anderungen'-Nachrichten zu allen Knoten oder den in Frage kommenden Knoten.

12.3 Der IDNX-Knoten oder die DBAPE bricht zusammen

Dies ist für den Monitor ein virtuell transparentes Ereignis. Wenn der Knoten oder die APE zusammenbricht, gehen keine Daten verloren und das schlimmste Problem besteht nur darin, daß die APE keine Änderungsnachrichten initiiert, bis diese durch die DBA-Zeitabschaltung angefragt werden.

12.4 Die DBC bricht zusammen

Da die APE sich nicht direkt auf die DBC verläßt, ist dies für den Monitor ein transparentes Ereignis.

IX. Konstruktion der Netzwerktopologieanwendung

1. Einleitung

Die Netzwerktopologieanwendung NTA ist eine Aufgabe, die an dem Monitor läuft, der dafür verantwortlich ist, Informationen über die Topologie des Knotennetzwerkes zu verwalten. Die NTA kommuniziert mit der Netzwerkmanageraufgabe an dem lokalen Knoten, um die Topologiekartendaten abzufragen. An dem Knoten ist kein spezielles Interface (APE) erforderlich. Wenn Änderungen in der Topologie geschehen, aktualisiert die NTA ihre interne Topologiekarte und informiert andere Aufgaben von den Änderungen.

2. Abfrage der Topologieinformation

Die Netmgr-Aufgaben in jeden Knoten verwalten eine Karte der Netzwerktopologie. Diese Karte ist ein Array von MAXNODES mal MAXLINKS (250 * 32). Für jede Knotennummer enthält jede Reihe die Liste der Nachbarknoten, die mit einer null abgeschlossen ist. Ein Knoten ohne Nachbarn befindet sich nicht in dem Netzwerk, d.h. er ist aus oder DOWN. Mit der Verbindung zu jedem Knoten sind Verbindungskosten und Verbindungsattribute (SATELLITE vs. TERRESTRIAL, etc.) verbunden.
Mit jeder Reihe aus der Topologiekarte ist eine Versionsnummer verbunden (Rowversion), die jedesmal inkrementiert wird, wenn die Reihe verändert wird. Eine Kontrollsumme aller Versionsnummern (gesamte Kontrollsumme) wird verwaltet, um die aktuelle Konfiguration der Topologiekarte anzuzeigen.
An dem Monitor verwaltet die NTA ihre eigene Version der aktuellen Topologiekarte. Beim Hochlaufen der NTA-Aufgabe wird die Karte so initialisiert, daß alle Reihen eine null aufweisen, wobei jede RowVersion gleich null ist (NO_PATH_EXISTS). Periodisch (sagen wir alle 30 Sekunden) fragt die NTA den Knoten NetMgr oder seinen Nachbarknoten zyklisch ab, um zu sehen, ob sich die gesamte Kontrollsumme geändert hat. Wenn dem so ist (und beim Hochlaufen von NTA), fragt dann die NTA die NetMgr nach ihren RowVersions und für jede, die sich geändert hat, fordert die NTA geänderte Reihen und aktualisiert ihre Topologiekarte.
Die NTA muß erkennen, wenn die Verbindung zwischen dem Monitor und dem lokalen Knoten nach unten geht (bspw. eine Fehlermeldung, wenn versucht wird, den Knoten abzufragen, oder eine Nachricht von der Netzwerkinterfaceaufgabe). Wenn dies geschieht, reinitialisiert NTA ihre aktuelle Karte (alle Knoten DOWN) und sendet Aktualisierungen zu anderen Aufgaben (später beschrieben).

2.1 Anforderungen an die Knotensoftware

Der NetMgr muß Nachrichtentypen handhaben, um die Total- Checksum, RowVersions und RowData zu erfragen.

3. Kommunikation mit anderen Anwendungen

Wenn ein neuer Knoten in dem Netzwerk hochkommt, überprüft die NTA zuerst in der Monitordatenbank, ob der Knoten in dieser Monitordomäne ist. Wenn dies nicht der Fall ist, informiert die NTA keine anderen Aufgaben. Wenn der Knoten konfiguriert wurde, wird ein weiterer Test durchgeführt, um zu bestimmen, ob die auf dem neuen Knoten laufende Softwareversion mit dem Monitor kompatibel ist. Wenn dies der Fall ist, informiert die NTA dann die Datenbankanwendung DBA mit einer "Knoten ein"-Nachricht (NTA-NODE-UP-MSG). Wenn die DBA eine aktuelle Kopie von der Datenbank des Knotens hat, sendet sie eine Nachricht zu der NTA. Dann sendet die NTA "Knoten ein"-Nachrichten zu der Ereignisanwendung EVA, der Alarmtabellenanwendung ATA und MAGIC.
Wenn sie hochlaufen (oder eine Rücksetz-Nachricht von der NTA empfangen), sollten die EVA, die DBA, die ATA und MAGIC annehmen, daß alle Knoten unten sind und dann den kompletten Satz von Knoten anfordern, die oben sind, indem eine Rücksetz- Nachricht an NTA gesendet wird. Wenn die NTA erneut startet, muß sie eine Rücksetz- oder Reset-Nachricht an die anderen Aufgaben senden, um sie darüber zu informieren, daß sie den kompletten Satz anfordern.
Wenn ein Knoten nach unten geht, sendet die NTA "Knoten AUS"-Nachrichten (NTA-NODE-DOWN-MSG) an jede der anderen Anwendungen.

4. Konfigurationstool-Interaktion

Wenn ein Knoten zu der Monitordomäne durch das Konfigurationstool hinzugefügt oder davon entfernt wird, aktualisiert er die Domänendatenbank und sendet eine Nachricht an NTA. Dies bewirkt, daß NTA die Datenbank neu liest, um zu bestimmen, welche Knoten hinzugefügt oder von der Domäne entfernt wurden.
Wenn ein Knoten hinzugefügt wurde, überprüft NTA seine Topologiekarte, um zu bestimmen, ob der Knoten gegenwärtig in dem Netzwerk ist und eine kompatible Softwareversion hat. Wenn dem so ist, folgt sie dann derselben Prozedur wie für eine "Knoten ein"-Änderung in der Topologie. Wenn dem nicht so ist, wird nichts getan.
Wenn ein Knoten entfernt wurde, überprüft NTA ihre Topologiekarte, um zu bestimmen, ob der Knoten gegenwärtig in dem Netzwerk ist und eine kompatible Softwareversion hat. Wenn dem so ist, sendet NTA "Knoten entfernt"-Nachrichten (NTA-NODE- DELETED-MSG) an die anderen Anwendungsaufgaben. (Dies kann genauso wie "Knoten aus" von einigen Aufgaben behandelt werden.) Wenn dem nicht so ist, wird nichts getan.

5. Aktualisierung der Monitordatenbank

Die NTA verwaltet eine interne Topologiekarte für ihren eigenen Gebrauch (z.B. um zu bestimmen, was sich in dem Netz geändert hat). Sie erzeugt oder aktualisiert keine Tabellen in der Monitordatenbank. Wenn andere Anwendungen einen Bedarf entwickeln, die gesamte Topologiekarte zu kennen, dann kann eine Nachricht definiert werden, um diese Information zu übertragen.

X. Schlußfolgerung

Die vorgehende Beschreibung der bevorzugten Ausführungsbeispiele der vorliegenden Erfindung wurde zum Zwecke der Illustration und Beschreibung gegeben. Sie soll nicht erschöpfend sein oder die Erfindung auf die genau offenbarte Form beschränken. Für den Fachmann ergeben sich offensichtlich viele Änderungen und Variationen. Die Ausführungsbeispiele wurden ausgewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktische Anwendung auf beste Weise zu erklären, um dadurch andere Fachleute in die Lage zu versetzen, die Erfindung für verschiedene Ausführungsbeispiele und mit verschiedenen Modifikationen zu verstehen, wie sie für den speziell angedachten Fall verwendbar sind. Der Bereich der Erfindung soll durch die folgenden Ansprüche und ihre Äquivalente definiert werden. ANHANG A Formate von Nachrichten zwischen der ATA und der ATAPE 37 C.F.R. §1.96(a)(2)(ii) ANHAND B Hauptdatenstrukturen in ATA 37 C.F.R §1.96(a)(2)(ii)

Claims

1. Vorrichtung zum Erfassen und Anzeigen von Informationen, die einen Status eines Kommunikationsnetzes betreffen, wobei das Netzwerk eine Vielzahl von verteilten Vermittlungsknoten (1-4) und eine Vielzahl von Verbindungsleitungen (5-7) umfaßt, die die Vermittlungsknoten miteinander verbinden, wobei jeder von den Vermittlungsknoten Aufgaben ausführt, zu denen Kommunikationsfunktionen (46), Verwaltung eines Ereignisprotokolles, das Ereignissätze (48) für den Vermittlungsknoten auflistet, und Verwaltung einer Konfigurationsdatenbank (49) zählen, die eine Konfiguration für den Vermittlungsknoten definiert, wobei die Vorrichtung aufweist:

einen Monitorknoten (11), der an einen ersten Vermittlungsknoten (1) aus der Vielzahl von verteilten Vermittlungsknoten gekoppelt ist, mit einer Schnittstelle (38) für Bedienereingaben, ersten Mitteln (35) zur Verwaltung von Topologiedaten, die die Topologie des Netzwerkes anzeigen, und zur Unterstützung eines ersten Protokolls mit dem ersten Vermittlungsknoten, zweiten Mitteln (37) zur Verwaltung einer Monitorliste von Ereignissätzen, die in die Ereignisprotokolle der Vermittlungsknoten in dem Netzwerk eingetragen sind, und zur Unterstützung eines zweiten Protokolls durch das Netzwerk mit der Vielzahl von verteilten Vermittlungsknoten, dritten Mitteln (36) zur Verwaltung einer Monitordatenbank, die die Konfiguration der Vermittlungsknoten anzeigt, wie sie in den Konfigurationsdatenbänken der Vermittlungsknoten in dem Netzwerk eingetragen Bind, und zur Unterstützung eines dritten Protokolls durch das Netzwerk mit der Vielzahl von verteilten Vermittlungsknoten, und mit Anzeigemitteln (33), die auf Bedienereingaben ansprechen, die einen gegenständlichen Vermittlungsknoten in dem Netzwerk identifizieren, und die an die Monitordatenbank, die Monitorliste von Ereignissätzen und die Topologiedaten gekoppelt sind, um dem Bediener Konfigurationsdaten über den gegenständlichen Vermittlungsknoten, die Netzwerktopologie und die Ereignissätze anzuzeigen;

Mittel (50) an dem ersten Vermittlungsknoten (1), um die Topologiedaten in Abhängigkeit von den an der Vielzahl von Vermittlungsknoten durchgeführten Kommunikationsfunktionen zu erzeugen, und um die Topologiedaten in Abhängigkeit von Nachrichten gemäß dem ersten Protokoll an die ersten Mittel (35) zu senden;

Mittel (52) an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an das Vermittlungsknoten-Ereignisprotokoll (48) des entsprechenden Vermittlungsknotens gekoppelt sind und auf Nachrichten gemäß dem zweiten Protokoll ansprechen, um Daten, die Ereignissätze anzeigen, die in das Ereignisprotokoll (48) des Vermittlungsknotens eingetragen sind, zu verpacken und zu den zweiten Mitteln (37) zu senden, wobei die Daten von jedem aus der Vielzahl von Vermittlungsknoten außer von dem ersten Vermittlungsknoten durch das Netzwerk zu dem ersten Vermittlungsknoten und durch den ersten Vermittlungsknoten (1) zu den zweiten Mitteln gelangen; und

Mittel (53) an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an die Vermittlungsknoten-Konfigurationsdatenbank (49) an dem entsprechenden Vermittlungsknoten gekoppelt sind und auf Nachrichten gemäß dem dritten Protokoll ansprechen, um Daten zu verpacken und von der Vermittlungsknoten-Konfigurationsdatenbank (49) zu den dritten Mitteln (36) zu senden, wobei die Daten von jedem aus der Vielzahl von Vermittlungsknoten außer von dem ersten Vermittlungsknoten durch das Netzwerk zu dem ersten Vermittlungsknoten und durch den ersten Vermittlungsknoten (1) zu den dritten Mitteln gelangen.

2. Vorrichtung nach Anspruch 1, bei der wenigstens ein Knoten aus der Vielzahl von Vermittlungsknoten eine Vielzahl von Verarbeitungseinheiten (51-53) umfaßt, wobei an dem einen Knoten durchgeführte Aufgaben auf die Vielzahl von Verarbeitungseinheiten verteilt sind, und bei der ferner die Aufgabe der Verwaltung des Ereignisprotokolls des Vermittlungsknotens sowie die Mittel, die an dem einen Knoten mit dem Ereignisprotokoll des Vermittlungsknotens gekoppelt sind und die auf das zweite Protokoll ansprechen, um Daten, die Ereignissätze anzeigen, die in das Ereignisprotokoll des Vermittlungsknotens eingetragen sind, zu verpacken und durch das Netzwerk zu den zweiten Mitteln zu senden, auf einer Verarbeitungseinheit (52) laufen.

3. Vorrichtung nach Anspruch 2, bei der die Kommunikationsfunktionen an dem einen Knoten auf einer anderen Verarbeitungseinheit als der einen Verarbeitungseinheit laufen.

4. Vorrichtung nach Anspruch 1, bei der wenigstens ein Knoten aus der Vielzahl von Vermittlungsknoten eine Vielzahl von Verarbeitungseinheiten (51-53) umfaßt, wobei an dem einen Knoten laufende Aufgaben auf die Vielzahl von Verarbeitungseinheiten verteilt sind, und bei der ferner die Aufgabe der Verwaltung der Konfigurationsdatenbank des Vermittlungsknotens sowie die Mittel, die an die Vermittlungsknoten-Konfigurationsdatenbank an dem einen Knoten gekoppelt sind und auf das dritte Protokoll ansprechen, um Daten zu verpacken und von der Konfigurationsdatenbank des Vermittlungsknotens durch das Netzwerk zu den dritten Mitteln zu senden, auf der einen Verarbeitungseinheit laufen.

5. Vorrichtung nach Anspruch 4, bei der die Kommunikationsfunktionen an dem einen Knoten auf einer anderen Verarbeitungseinheit als der einen Verarbeitungseinheit laufen.

6. Vorrichtung nach einem der Ansprüche 1 bis 5, bei der die Ereignissätze, die aufgelistet werden, Alarmzustände sind, wobei jedes Ereignisprotokoll eine Knotenliste von Alarmzuständen für den jeweiligen Vermittlungsknoten ist.

7. Vorrichtung nach Anspruch 1, bei der das Ereignisprotokoll des Vermittlungsknotens eine Vermittlungsknotenliste von Alarmzuständen für den Vermittlungsknoten beinhaltet, wobei ferner vorgesehen sind: vierte Mittel (34) an dem Monitorknoten zur Verwaltung einer Monitorliste von Alarmzuständen, die in die Vermittlungsknotenlisten von Alarmzuständen in dem Netzwerk eingetragen sind, und zur Unterstützung eines vierten Protokolls durch das Netzwerk mit der Vielzahl von verteilten Vermittlungsknoten, Mittel (51) an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an die Vermittlungsknotenliste von Alarmzuständen (48) innerhalb des Ereignisprotokolls an dem Vermittlungsknoten gekoppelt sind und auf Nachrichten gemäß dem vierten Protokoll aneprechen, um Daten, die Alarmzustände anzeigen, die in das Ereignisprotokoll des Vermittlungsknotens eingetragen sind, zu verpacken und zu den vierten Mitteln zu senden, wobei jeder aus der Vielzahl von verteilten Vermittlungsknoten außer dem ersten Vermittlungsknoten die Daten, die Alarmzustände anzeigen, durch das Netzwerk zu dem ersten Vermittlungsknoten und durch den ersten Vermittlungsknoten zu den vierten Mitteln sendet.

8. Vorrichtung nach Anspruch 6 oder 7, bei der die Anzeigemittel einen Anzeigemonitor sowie Graphikverarbeitungsmittel umfassen, um eine Vielzahl von Anzeigefenstern auf dem Displaymonitor zu erzeugen, und wobei ein erstes Fenster (20) aus der Vielzahl von Anzeigefenstern die Netzwerktopologie graphisch anzeigt, ein zweites Fenster (23) aus der Vielzahl von Anzeigefenstern die Konfigurationsdaten über den gegenständlichen Knoten graphisch anzeigt, und ein drittes Fenster (27) aus der Vielzahl von Anzeigefenstern die Monitorliste von Alarmzuständen graphisch anzeigt.

9. Vorrichtung nach Anspruch 8, bei der die Graphikverarbeitungsmittel weiter Mittel umfassen, um die in dem ersten Fenster angezeigte Netzwerktopologie in Abhängigkeit von wenigstens einem Alarmzustand in der von den zweiten Mitteln verwalteten Monitorliste von Alarmzuständen hervorzuheben.

10. Vorrichtung nach Anspruch 1 oder 6, bei der die Mittel, an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, zum Verpacken und Senden von Daten von der Konfigurationsdatenbank des Vermittlungsknotens zu den dritten Mitteln umfassen:

Mittel zum Detektieren von Änderungen an der Konfigurationsdatenbank des Vermittlungsknotens und

Mittel, die auf das dritte Protokoll ansprechen, um eine Nachricht zu erzeugen, die wenigstens einen Teil der detektierten Änderungen enthält.

11. Vorrichtung nach Anspruch 10, bei der die Konfigurationsdatenbank (49) des Vermittlungsknotens eine Vielzahl von Blöcken von Daten und eine jedem Block zugeordnete Blockkontrollsumme umfaßt, wobei die Mittel zum Detektieren von Änderungen an der Konfigurationsdatenbank des Vermittlungsknotens umfassen:

Mittel, die auf Nachrichten gemäß dem dritten Protokoll ansprechen, um eine gesamte Kontrollsumme für alle Blöcke in der Konfigurationsdatenbank des Vermittlungsknotens zu erzeugen;

und Mittel zum Vergleichen einer zur Zeit erzeugten gesamten Kontrollsumme mit einer zuvor erzeugten gesamten Kontrollsumme, um Änderungen an der Datenbank zu detektieren.

12. Vorrichtung nach Anspruch 1 oder 6, bei der die Mittel (52), an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, zum Verpacken und Senden von Daten, die Ereignissätze anzeigen, die in das Ereignisprotokoll des Vermittlungsknotens eingetragen sind, zu den zweiten Mitteln, Mittel umfassen, um Ereignissätze zu detektieren, die in das Ereignisprotokoll des Vermittlungsknotens eingetragen sind, sowie Mittel, die auf das zweite Protokoll ansprechen, um eine Nachricht zu erzeugen, die wenigstens einen Teil der Ereignissätze enthält.

13. Vorrichtung nach Anspruch 7, bei der die Mittel, an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, zum Verpacken und Senden von Daten, die Alarmzustände anzeigen, die in die Vermittlungsknotenliste eingetragen sind, zu den vierten Mitteln, Mittel umfassen, um Alarmzustände zu detektieren, die in das Ereignisprotokoll des Vermittlungsknotens eingetragen sind, sowie Mittel, die auf das vierte Protokoll ansprechen, um eine Nachricht zu erzeugen, die wenigstens einen Teil der Alarmzustände enthält.

14. Vorrichtung nach Anspruch 12 oder 13, bei der die Vermittlungsknotenliste eine Alarmtabelle und einen der Alarmtabelle zugeordneten numerischen Indikator umfaßt, der eine Anzahl von Alarmzuständen in der Tabelle anzeigt, wobei die Mittel zum Detektieren von Alarmzuständen Mittel zum Vergleichen eines aktuellen numerischen Indikators mit einem vorhergehenden numerischen Indikator umfassen, um Änderungen in der Alarmtabelle zu detektieren.

15. Vorrichtung nach Anspruch 1, bei der die Vielzahl von Vermittlungsknoten eine Vielzahl von Verarbeitungseinheiten (51-53) umfaßt, wobei Aufgaben, die an dem Vermittlungsknoten laufen, auf die Vielzahl von Verarbeitungseinheiten verteilt sind, und wobei weiter die Aufgabe der Verwaltung der Konfigurationsdatenbank des Vermittlungsknotens sowie die Mittel, die an die Vermittlungsknoten-Konfigurationsdatenbank an dem Vermittlungsknoten gekoppelt sind und auf das dritte Protokoll ansprechen, um Daten zu verpacken und von der Vermittlungsknoten- Konfigurationsdatenbank durch das Netzwerk zu den dritten Mitteln zu senden, auf einer Verarbeitungseinheit (53) laufen.

16. Vorrichtung nach Anspruch 15, bei der die Kommunikationsfunktionen an dem einen Knoten auf einer anderen Verarbeitungseinheit als der einen Verarbeitungseinheit laufen.

17. Vorrichtung zum Erfassen und Anzeigen von Informationen, die einen Status eines Kommunikationsnetzes betreffen, wobei das Netzwerk eine Vielzahl von verteilten Vermittlungsknoten (66-68; 70, 71) sowie eine Vielzahl von Verbindungsleitungen umfaßt, die die eine Netzwerktopologie definierenden Vermittlungsknoten miteinander verbinden, wobei jeder der Vermittlungsknoten Kommunikationsfunktionen (46) ausführt, ein Ereignisprotokoll (48) verwaltet, das Alarmzustände für den Vermittlungsknoten beinhaltet, und eine Konfigurationsdatenbank (49) verwaltet, die eine Konfiguration für den Vermittlungsknoten identifiziert, wobei die Vorrichtung umfaßt: erste Überwachungsmittel (65), die an einen ersten Vermittlungsknoten (66) aus der Vielzahl von verteilten Vermittlungsknoten gekoppelt sind, um durch den ersten Vermittlungsknoten von Netzwerkknoten und Verbindungsleitungen Informationen zu erfassen und einem Bediener anzuzeigen, die die Netzwerktopologie, Alarmzustände in dem Netzwerk und Konfigurationen für ausgewählte Knoten in einem ersten Teilsatz (66-68) aus der Vielzahl von verteilten Vermittlungsknoten betreffen, wobei die ersten Überwachungsmittel eine Schnittstelle (38) für Bedienereingaben, erste Mittel (35) zur Verwaltung von Topologiedaten, die die Topologie des Netzwerkes anzeigen, und zur Unterstützung eines ersten Protokolls mit dem ersten Vermittlungsknoten, zweite Mittel (34) zur Verwaltung einer Monitorliste von Alarmzuständen, die in die Vermittlungsknotenliste von Alarmzuständen in dem Netzwerk eingetragen sind, und zur Unterstützung eines zweiten Protokolls durch das Netzwerk mit dem ersten Teilsatz aus der Vielzahl von verteilten Vermittlungsknoten, dritte Mittel (36) zur Verwaltung einer Monitordatenbank, die die Konfiguration der Vermittlungsknoten anzeigt, wie sie in die Vermittlungsknoten-Konfigurationsdatenbank in dem Netzwerk eingetragen ist, und zur Unterstützung eines dritten Protokolls durch das Netzwerk mit dem ersten Teilsatz aus der Vielzahl von verteilten Vermittlungsknoten, sowie Anzeigemittel (33) umfassen, die auf Bedienereingaben ansprechen, die einen gegenständlichen Vermittlungsknoten in dem ersten Teilsatz aus der Vielzahl von Vermittlungsknoten identifizieren, und die an die Monitordatenbank, die Monitorliste von Alarmzuständen sowie die Topologiedaten gekoppelt sind, um dem Bediener Konfigurationsdaten über den gegenständlichen Vermittlungsknoten, die Netzwerktopologie und die Alarmzustände anzuzeigen; von den ersten überwachungsmitteln (65) unabhängige zweite überwachungsmittel (69), die an einen zweiten Vermittlungsknoten (70) aus der Vielzahl von verteilten Vermittlungsknoten gekoppelt sind, um durch den zweiten Vermittlungsknoten von Netzwerkknoten und Verbindungsleitungen Informationen zu erfassen und einem Bediener anzuzeigen, die die Netzwerktopologie, Alarmzustände in dem Netzwerk sowie Konfigurationen für ausgewählte Knoten in einem zweiten Teilsatz (70, 71) aus der Vielzahl von verteilten Vermittlungsknoten betreffen, wobei die zweiten Überwachungsmittel eine Schnittstelle (38) für Bedienereingaben, erste Mittel (35) zur Verwaltung von Topologiedaten, die die Topologie des Netzwerkes anzeigen, und zur Unterstützung eines vierten Protokolles mit dem zweiten Vermittlungsknoten, zweite Mittel (34) zur Verwaltung einer Monitorliste von Alarmzuständen, die in die Vermittlungsknotenliste von Alarmzuständen in dem Netzwerk eingetragen sind, und zur Unterstützung eines fünften Protokolles durch das Netzwerk mit dem zweiten Teilsatz aus der Vielzahl von verteilten Vermittlungsknoten, dritte Mittel (36) zur Verwaltung einer Monitordatenbank, die die Konfiguration der Vermittlungsknoten anzeigt, wie sie in die Vermittlungsknoten- Konfigurationsdatenbank in dem Netzwerk eingetragen sind, und zur Unterstützung eines sechsten Protokolles durch das Netzwerk mit dem zweiten Teilsatz aus der Vielzahl von verteilten Vermittlungsknoten, sowieanzeigemittel (33) umfassen, die auf Bedienereingaben ansprechen, die einen gegenständlichen Vermittlungsknoten in dem Netzwerk identifizieren, und die an die Monitordatenbank, die Monitorliste von Alarmzustanden und die Topologiedaten gekoppelt sind, um dem Bediener Konfigurationsdaten über den gegenständlichen Vermittlungsknoten, die Netzwerktopologie und die Alarmzustände anzuzeigen; Mittel (50) an dem ersten Vermittlungsknoten (66), um die Topologiedaten in Abhängigkeit von den an dem ersten Teilsatz (66-68) aus der Vielzahl von Vermittlungsknoten durchgeführten Kommunikationsfunktionen zu erzeugen, und um die Topologiedaten in Abhängigkeit von Nachrichten gemäß dem ersten Protokoll an die ersten Mittel (35) an den ersten überwachungsmitteln (65) zu senden; Mittel (50) an dem zweiten Vermittlungsknoten (70), um die Topologiedaten in Abhängigkeit von den an dem zweiten Teilsatz (70, 71) aus der Vielzahl von Vermittlungsknoten durchgeführten Kommunikationsfunktionen zu erzeugen, und um die Topologiedaten in Abhängigkeit von Nachrichten gemäß dem vierten Protokoll zu den ersten Mitteln (35) an den zweiten Überwachungsmitteln (69) zu senden; und Mittel (51) an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an die Vermittlungsknotenliste von Alarmzuständen an dem entsprechenden Vermittlungsknoten gekoppelt sind und auf Nachrichten gemäß wenigstens einem von dem ersten oder dem fünften Protokoll ansprechen, um Alarmzustände anzeigende Daten zu verpacken und zu den zweiten Mitteln (34) an wenigstens den ersten oder zweiten Überwachungsmitteln (65; 69) zu senden, wobei die Daten von den ersten und zweiten Teilsätzen aus der Vielzahl von verteilten Vermittlungsknoten durch das Netzwerk zu dem ersten Vermittlungsknoten (66) oder dem zweiten Vermittlungsknoten (70) und durch den ersten Vermittlungsknoten (66) zu den zweiten Mitteln (34) an den ersten Überwachungsmitteln (65) oder durch den zweiten Vermittlungsknoten (70) zu den zweiten Mitteln (34) an den zweiten Überwachungsmitteln (69) gelangen; und Mittel (53) an jedem aus der Vielzahl von verteilten Vermittlungsknoten in dem Netzwerk, wobei die Mittel an die Vermittlungsknoten-Konfigurationsdatenbank an dem entsprechenden Vermittlungsknoten gekoppelt sind, und auf Nachrichten gemäß wenigstens einem von dem dritten oder sechsten Protokoll ansprechen, um Daten von der Vermittlungsknoten- Konfigurationsdatenbank (49) zu verpacken und zu den dritten Mitteln (36) an wenigstens den ersten oder zweiten Überwachungsmitteln zu senden, wobei die Daten von den ersten und zweiten Teilsätzen (66-68; 70, 71) aus der Vielzahl von verteilten Vermittlungsknoten durch das Netzwerk zu dem ersten Vermittlungsknoten (66) oder dem zweiten Vermittlungsknoten (70) und durch den ersten Vermittlungsknoten zu den dritten Mitteln (36) an den ersten Überwachungsmitteln (65) oder durch den zweiten Vermittlungsknoten zu den dritten Mitteln (36) an den zweiten Überwachungsmitteln (69) gelangen.