DE69015967T3

DE69015967T3 - Passiver netzwerkmonitor und entsprechendes überwachungsverfahren.

Info

Publication number: DE69015967T3
Application number: DE69015967T
Authority: DE
Inventors: Robert Douglas
Original assignee: Concord Communications LLC
Current assignee: Concord Communications LLC
Priority date: 1989-05-19
Filing date: 1990-05-18
Publication date: 2000-07-27
Anticipated expiration: 2010-05-19
Also published as: EP0425655B1; EP0425655B2; WO1990014725A1; DE69015967D1; ATE117147T1; JPH05500291A; DE69015967T2; EP0425655A1

Description

Passiver Netzwerkmonitor und entsprechendes Überwachungsverfahren

Beschreibung

Die Erfindung betrifft allgemein ein Verfahren zur passiven Überwachung eines in Betrieb befindlichen Datenkommunikationsnetzwerks, wie durch die Merkmale des Oberbegriffes des Anspruches 1 oder des Anspruchs 2 definiert, und einen Monitor für ein passives Beobachten des Betriebes eines Datenkommunikationsnetzwerks gemäß den Merkmalen, die im Oberbegriff des Anspruches 18 definiert sind.
Ein Verfahren und ein Monitor dieses allgemeinen Typs sind aus dem US-Patent 4,745,598 bekannt, welches eine Technik zum Überwachen einer logischen Ringstruktur in einem logischen Bereichsnetzwerk offenbart. Token-Verfahrensbefehle werden in solcher Weise überwacht, dass dann, wenn eine Station, die momentan die Sendeerlaubnis besitzt, ausfällt, der logische Ring wieder hergestellt werden kann.
Datenkommunikationsnetzwerke erlauben den Informationsaustausch und die gemeinsame Benutzung von Computerressourcen und ermöglichen es somit einer Organisation, Nutzen aus ihrer gesamten Computerleistungsfähigkeit zu ziehen. Bei Computerressourcen ist es zunehmend üblich, dass diese in örtlichen Bereichsnetzwerken (LANs) angeordnet werden, speziell dann, wenn ein Daten transfer unter mehreren Ressourcen oder Stationen erforderlich ist, die an verschiedenen Plätzen innerhalb eines Gebäudes oder einer Gruppe von Gebäuden gelegen sind.
Da die Organisationen häufig entweder eine Computerausrüstung verwenden, die durch eine Anzahl unterschiedlicher Hersteller hergestellt wurden, oder wünschen, Informationen mit anderen Organisationen auszutauschen, die eine unterschiedliche Ausrüstung verwenden, wurde es in den späten 1970iger Jahren offensichtlich, dass ein Weg zur Unterstützung einer Hochgeschwindigkeits-Datenkommunikation zwischen unterschiedlichen Typen von Computern benötigt werden wird.
Dies rief das Institut of Electrical and Electronic Engineers (IEEE) auf den Plan, um dessen Projekt 802 zu beginnen. Das IEEE erreichte sehr schnell zwei Schlussfolgerungen. Erstens stellt die Maßnahme, unterschiedliche Computer zum Kommunizieren zu bringen, ein komplexes Problem dar, und zwar auf Grund der Vielfalt in der Konstruktion. Es erfordert Architekturentscheidungen nicht nur auf niedrigen Ebenen, wie beispielsweise einer Zustimmung zu geeigneten Modulationsschemata, sondern auch auf höheren Ebenen. Zweitens ist keine einzelne Architektur für alle Anwendungen ideal.
Das IEEE hat somit ein LAN-Referenzmodell entwickelt mit drei "Schichten". Eine erste Schicht, die als physikalische Schicht bezeichnet wird, befasst sich mit der Natur des Übertragungsmediums. Eine zweite Schicht, die als die Medienzugriffssteuer- (MAC)-Schicht bezeichnet wird, befasst sich mit Einzelheiten der Signalgabe in Verbindung mit der physikalischen Schicht. Es werden Nachrichten oder Botschaften unter vielen Stationen in Gruppen von elementaren Symbolen ausgetauscht. Die grundlegende Botschaft oder Nachricht wird als ein Rahmen (frame) bei der MAC-Schicht bezeichnet, was die Möglichkeit schafft, dass Rahmentypen sowohl Steuerrahmen als auch Datenrahmen enthalten.
Die Datenrahmen enthalten die Informationen, die über das Sendenetzwerk ausgetauscht werden sollen, während die Steuerrahmen dazu verwendet werden, an jede Station Befehle oder Instruktionen auszugeben, primär, um sicherzustellen, dass keine zwei Stationen versuchen, zur gleichen Zeit zu senden. Eine dritte Schicht, die als logische Verbindungsgliedsteuer-(LLC)-Schicht bezeichnet wird, befasst sich mit der Erstellung, Aufrechterhaltung und Beendigung von logischen Übertragungsstrecken zwischen den Stationen.
Die IEEE traf auch die Schlussfolgerung, dass keine einzelne MAC-Schicht-Architektur für alle Situationen ideal sein würde. Es kann die Performance bei einigen Anwendungen für niedrigere Kosten geopfert werden, wie beispielsweise bei einem typischen Büro, jedoch geben in anderen Umgebungen, wie beispielsweise einer typischen Fabrik, die Anwender mehr Geld dafür aus, um ein Netzwerk zu erhalten, welches robuster ist. Es wurde das IEEE-802.4-Token-Durchgangs -Buszugriffsverfahren für diese kritischen Umgebungen entwickelt.
Obwohl der 802.4-Standard eine ziemlich robuste Kommunikationsumgebung spezifiziert, treten dennoch Ausfälle auf, und zwar auf Grund einer Fehlfunktion der Ausrüstung, eines Fehlbetriebes des Netzwerkes oder auf Grund von Programmierfehlern. Es besteht ein Bedarf dafür, zu identifizieren, welche Station die Quelle solcher Ausfälle oder Fehler ist, speziell deshalb, weil eine einzelne fehlerhafte Station die Verwendung des Netzwerks durch andere Stationen verhindern kann. Die Fehlerquelle muss häufig schnell lokalisiert werden, speziell dann, wenn die Profitabilität der Organisation in kritischer Weise vom Betrieb des LAN abhängt, wie dies häufig in einer Produktions-Umgebung oder Bereich der Fall ist.
Das Fehleridentifizierungsproblem wird ferner durch das Vorhandensein einer Ausrüstung gravierender, die durch viele unabhän gige Gesellschaften hergestellt wurde. Obwohl alle solchen LAN- Ausrüstungen in Einklang mit einem Standardprotokoll arbeiten, ist es häufig schwierig, dauerhaft Diagnoseinformationen über jede Station in solch einer Situation zu erhalten. Dies trifft speziell dann zu, wenn mehrere Vertreiber sich dazu entschlossen haben, das Standardprotokoll auf unterschiedliche Wege zu implementieren oder miteinander in Konflikt stehende Diagnoseprozeduren erfordern.
Es ist auch erforderlich, die Verwendung des LAN zu verstehen, um Performance-Flaschenhälse zu lokalisieren und zu korrigieren. Solche Flaschenhälse treten häufig auf Grund von Belastungsungleichmäßigkeiten auf und speziell auf Grund solcher, die durch einen schweren oder umfangreichen Verkehr zu und von bestimmten Stationen verursacht werden, die als Brücken (bridges) bezeichnet werden. Die Brücken dienen als Gateways für Nachrichten von einem Netz zu einem anderen und bilden daher häufig einen Flaschenhals. Als ein Ergebnis suchen Netzwerkmanager häufig Antworten auf die Fragen, wie beispielsweise: (1) Bis zu welchem Ausmaß verwendet jede Station das Medium? (2) Sollte das Netzwerk in eine Vielzahl miteinander verbundener Netzwerke für einen Belastungsausgleich aufgebrochen werden? und (3) wie viel des Verkehrs wird über die Brücken geroutet?
Bestimmte Diagnosewerkzeuge, die Monitore genannt werden, sind momentan verfügbar, um beim Identifizieren und Isolieren von Netzwerkfehlern als auch von Performance-Flaschenhälsen eine Hilfe zu geben. Die Monitore bestehen allgemein aus zwei Typen, wobei jeder Typ bestimmte Vorteile hat.
In Verbindung mit dem ersten Typ eines Monitors werden Diagnose- und Performance-Informationen in einer gewissen Form durch jede Station gesammelt. Diese Informationen werden zu ei ner zentralen Stelle gesendet oder übertragen und mit Informationen von anderen Stationen kombiniert.
Es existieren mehrere Nachteile dieser Annäherung. Erstens ist es schwierig, die Informationen physikalisch von jeder Station zu sammeln. Wenn das LAN selbst dazu verwendet wird, um die Informationen auszusenden, verhindern bestimmte Typen von LAN- Fehlern ebenfalls das Sammeln von Diagnosedaten und verhindern somit eine richtige Diagnose des Ärgernisses. Wenn andererseits ein sekundärer Pfad dazu verwendet wird, um die Informationen zu sammeln, muss eine kostspielige und unbequeme Hardware hinzugefügt werden. Schließlich sind die Typen von Daten, die jede Station sammeln kann, häufig durch Performance-Einschränkungen begrenzt. Bei Abwesenheit eines an früherer Stelle standardisierten oder zugelassenen Satzes von Parametern, der beibehalten werden soll, können die Managementinformationen, die von der Ausrüstung gesammelt werden, welche durch unterschiedliche Zulieferer hergestellt wurden, nicht kompatibel sein und im schlechtesten Fall können diese sogar zu in Konflikt stehenden Schlußfolgerungen über die Fehler der Ausrüstung führen.
In der Tat stellt dies momentan solch ein Problem dar, dass mehrere Industrieorganisationen Managementstandards vorschlagen, die spezifizieren, welche Informationen durch jede Station gehalten werden müssen, als auch, auf welche Weise die Informationen ausgetauscht werden sollten.
Ein zweiter Typ eines Monitors wird direkt an das LAN angefügt und detektiert und speichert Datenpaketablauffolgen weit reichend in der gleichen Art wie ein logischer Analysator. Diese Monitore besitzen manchmal die Fähigkeit, die Zahl und den Typ der Rahmen (frames) aufzuzeichnen, die von jeder Station gesendet werden. Jedoch sind sie ebenfalls mit verschiedenen Nachteilen behaftet.
Da erstens diese Monitore nicht automatisch bestimmen, welche Station die Quelle der Fehler ist, benötigen sie einen Operator, der sich in dem Netzwerkprotokoll auskennt, und zwar wenigstens so weit reichend, um zu erkennen, dass bestimmte Rahmentypen in bestimmten Situationen nicht auftreten sollten. Der Operator muss in typischer Weise den Monitor mit einer Datensequenz programmieren, um in anzutriggern und muss dann von Hand die Ablaufverfolgung betrachten, die nach dem Triggern auftritt, um die Quelle eines Problems zu bestimmen. Daher berichten diese Monitore nicht Probleme in einer Realzeit, erfordern allgemein das Programmieren, um Fehler zu detektieren, und liefern auch keine automatische Anzeige über die Quelle eines Problems.
Zweitens können diese Monitore nicht automatisch eine Identifizierung durchführen, welche Rahmen durch die Stationen gesendet wurden, die das Netzwerk über eine Brücke zugreifen. Dies ist deshalb so, weil die Quellenadressen solcher Rahmen nicht diejenigen der Brücke selbst sind, sondern vielmehr diejenige einer Ursprungsstation, die auf der anderen Seite der Brücke gelegen ist. Die Brücke liefert lediglich diese Rahmen zu dem örtlichen Bereichsnetzwerk, ohne die Adressenfelder in dem Rahmen zu modifizieren.
Es existiert somit ein unerfüllter Bedarf nach einer Überwachungsvorrichtung für ein Datenkommunikationsnetzwerk, die zuverlässig und schnell Fehler identifiziert, ohne dabei einen hohen Wert an Fachkenntnis eines Operators erforderlich zu machen. Der Monitor sollte nicht die Verwendung von Stationsressourcen erfordern und sollte das Netzwerk selbst nicht dazu verwenden, um Diagnoseinformationen zu übertragen. Der Monitor sollte den Bedarf vermeiden, dass Stationen Zustimmungsmanagementprotokolle beobachten müssen. Er sollte auch die Netzwerkverwendbarkeit messen, und zwar nicht nur durch die direkt an geschlossenen Stationen, sondern auch durch Stationen, die an das Netzwerk über Brücken angeschlossen sind.
Probleme des angegebenen Typs können durch ein Verfahren gemäß der Erfindung gelöst werden, wie dies im Anspruch 1 bzw. im Anspruch 2 beansprucht wird, und durch einen Monitor nach dem Anspruch 18. Bevorzugte Ausführungsformen der Erfindung ergeben sich aus den Unteransprüchen.
Kurz gesagt diagnostiziert ein Netzwerkmonitor, der in Einklang mit der Erfindung konstruiert ist, ob eine oder mehrere Stationen in einem Sende-Kommunikationsnetzwerk fehlerhaft arbeiten. Dies wird dadurch erreicht, indem passiv Sequenzen der Steuerrahmenübertragungen oder Sendungen detektiert werden. Es werden die detektierten Steuerrahmensequenzen in Realzeit mit einem Modell der erwarteten Änderung der Steuerrahmen verglichen. Der Monitor macht die Schlussfolgerung, dass eine Fehlfunktion aufgetreten ist, wenn die detektierten Steuerrahmensequenzen nicht mit den Rahmensequenzen übereinstimmen, die durch das Modell angegeben werden. Eine beobachtete Fehlfunktion wird dann berichtet.
Der Monitor kann mit einem Netzwerk ziemlich nützlich eingesetzt werden, welches ein Token-Verfahrensprotokoll verwendet. In dieser Konfiguration kann dieser bestimmen, ob eine bestimmte Station falsch oder nicht zufrieden stellend arbeitet, indem die Sequenzen der Token-Verfahrenssteuerrahmen detektiert werden und dann nochvollzogen wird, ob das Token (Sendeerlaubnis) in der Reihenfolge verlaufen ist, wie sie durch das Modell vorgeschrieben wird.
Der Monitor kann ebenso feststellen, dass ein Kabel gebrochen ist, eine Station aus dem Netzwerk entfernt wurde, ein bestimmter Empfänger oder Sender der Station marginal arbeitet oder ausgefallen ist oder ein Zeitschlitzwert fälschlich eingestellt wurde oder dass andere Typen von Fehlfunktionen aufgetreten sind und im geeigneten Fall werden diese lokalisiert, und zwar für eine bestimmte Station.
Da der Monitor Informationen sammelt, welche die Sequenz der Steuerrahmen betreffen, kann dieser auch über andere Informationen in Bezug auf das Netzwerk Bericht erstatten. Beispielsweise kann dieser Statistiken beobachten und aufrechterhalten hinsichtlich des Netzwerkdatenverkehrs und auch hinsichtlich der Konfigurationsinformationen, und zwar in Realzeit. Die Überwachung des Verkehrs wird dadurch erreicht, indem das Quellen- oder Bestimmungsortadressenfeld der detektierten Datenrahmen geprüft wird und indem die verschiedenen Typen der Datenrahmen für jede Quellen- und Bestimmungsortstation gezählt werden.
Da der Motor unabhängig eine Suche durchführt, welche Station die Sendeerlaubnis (Token) besitzt, können Statistiken in einfacher Weise darüber entwickelt werden, wie viel Verkehr zu und von den Brücken verläuft als auch zu und von jeder Station, die hinter einer Brücke gelegen ist. Auf diese Weise lässt sich eine Brücke, die überlastet worden ist, unmittelbar identifizieren.
Da der Monitor passiv ist, braucht das Netzwerk nicht vollständig betriebsfähig zu sein, um über Fehlfunktionen oder Fehler, die Verwendung von Stationsressourcen oder einem früher zugestimmten Managementprotokoll zu berichten.
Im Gegensatz zu herkömmlichen Lösungen, bei denen die Typen der Rahmen gezählt wurden oder eine Triggerung vorgenommen wurde bei Detektion eines einzelnen Ereignisses einer Rahmensequenz, sucht der Monitor fortlaufend den gesamten Netzwerkverkehr ab und liefert geeignete Nachrichten in Realzeit. Der Monitor bietet daher den besonderen Vorteil, dass er unmittelbar durch ei nen Operator verwendbar ist, der nur geringe oder keine persönliche Erfahrung hinsichtlich des Betriebes des Netzwerkprotokolls besitzt, da dessen Ausgabe bzw. Ausgang nicht nur aus Ablaufverfolgungen besteht. Vielmehr berichtet der Monitor über Ereignisse, die nicht mit dem erwarteten Netzwerkverhalten übereinstimmen, und zwar ohne das Erfordernis des Eingreifens eines erfahrenen Netzwerkoperators, um diesen zu programmieren.
Die oben angegebenen und weitere Vorteile der Erfindung können durch Hinweis auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen besser verstanden werden, in welchen:
Fig. 1 ein Blockdiagramm eines Breitband-Datenkommunikationsnetzwerks zeigt, welches Gebrauch von einem passiven Monitor gemäß der Erfindung macht;
Fig. 2 ein detailliertes Blockschaltbild des passiven Monitors ist;
Fig. 3 ein detailliertes Blockdiagramm eines Protokollanalysierabschnitts des passiven Monitors ist;
Fig. 4A bis 4C Steuerrahmenformate zeigen, die durch das IEEE-802.4-Token-Durchlaufbusprotokoll spezifiziert sind; und
Fig. 5A bis 5D Flussdiagramme des Prozesses sind, der durch den passiven Monitor verwendet wird, um das Netzwerk zu charakterisieren.
Um spezieller auf die Zeichnungen einzugehen, so zeigt Fig. 1 einen passiven Monitor 10, der gemäß der Erfindung konstruiert ist. Der passive Monitor 10 detektiert Sequenzen von Steuerrah men, die zwischen einer Anzahl von Stationen 11a, 11b, ... und 11n (kollektiv die Stationen 11) über Übertragungs- oder Sendestreckenmedien 12 laufen. Der passive Monitor 10, die Stationen 11 und die Sendestreckenmedien 12 bilden ein Datenkommunikationsnetzwerk und bei dem speziellen gezeigten Ausführungsbeispiel ein örtliches Bereichsnetzwerk (LAN) 13.
Die an das LAN 13 angeschlossenen Stationen 11 verwenden ein Media Access Control (MAC) Protokoll, um zu bestimmen, welche Station das Recht zum Senden besitzt. Das bei der bevorzugten Ausführungsform verwendete spezifische Protokoll ist durch den IEEE-Standard 802.4, einem Token-Durchlaufbusprotokoll definiert. Einzelheiten des 802.4-Standards sind in Token Passing Bus Access Method in Physical Layer Specifications, ANSIIIEEE Std 802.4-1985 (New York: Institute of Electrical and Electronic Engineers, 1985) verfügbar, welche Literaturstelle hier durch Bezugnahme voll mit einbezogen wird. Jedoch kann die Erfindung auch so angepasst werden, um mit anderen MAC-Protokollen zu arbeiten und zu diesem Zweck mit irgendeinem geschichteten Protokoll, welches Steuerrahmen verwendet.
Gemäß dem 802.4-Standard besteht ein Token aus einem speziellen Steuerrahmen, der das Recht zu senden wiedergibt. Unter gewöhnlichen Betriebsbedingungen wird einer Station 11, die ein Token empfängt, somit das Recht zu senden, erteilt. Lediglich die Station, die das Token besitzt, kann zu irgendeinem gegebenen Zeitpunkt senden. Wenn eine bestimmte Station 11 das Senden beendet hat, übergibt sie das Token zu einer anderen Station in Einklang mit dem 802.4-Protokoll. Das Token bzw. die Sendeerlaubnis verläuft unter den Stationen 11 in einer vorgeschriebenen Sequenz - so dass man sagt, dass die Stationen 11 in einem "Ring" angeordnet sind und das Token sich um den Ring herum bewegt.
Ebenso in Einklang mit dem 802.4-Standard ist ein Kopfende-Remodulator 11k an das LAN 13 angeschlossen, wenn das Sende- oder Übertragungsmedium 12 breitbandig ist. Der Kopfende-Remodulator 11k wirkt als ein Hochfrequenz-Repeater.
Das LAN 13 kann auch eine Brücke 14 enthalten. Die Brücke 14 ist eine Vorrichtung, die es den Stationen ermöglicht, die an das LAN 13 angeschlossen sind, auch mit Vorrichtungen zu kommunizieren, die an andere Netzwerke angeschlossen sind, wie beispielsweise das LAN 13b, welche durch die Stationen 11x, 11y, ... 11z und andere Sendemedien 12b gebildet sind.
Im Betrieb hört der passive Monitor 10, kurz gesagt, auf den gesendeten Steuer- und Datenrahmenverkehr auf dem LAN 13. Der Monitor 10 ist tatsächlich passiv insofern als dieser keine Kommunikationen über das LAN 13 anzeigt, sondern lediglich den Steuer- und Datenrahmenverkehr empfängt und interpretiert. Der passive Monitor 10 detektiert Sequenzen von Steuerrahmen, die zwischen den Stationen 11 ausgetauscht werden. Das heißt, der passive Monitor 10 beobachtet nicht nur einfach den Steuer- und Datenrahmenverkehr zu und von einer spezifischen Station 11, sondern verfolgt auch den Verkehr zu und von jeder Station 11, die an das LAN 13 angeschlossen ist. Der Monitor entwickelt somit einen laufenden Zustand für das gesamte Netzwerk. Beispielsweise hält der passive Monitor 10 unter anderem Schritt damit, welche Station 11 als Letzte einen gültigen Token-Verfahrensrahmen empfangen hat und somit, welche Station 11 momentan ein gültiges Recht zu senden besitzt.
Der passive Monitor 10 enthält auch ein gespeichertes Modell über das erwartete Verhalten des Rahmenverkehrs auf dem LAN 13 und speziell ein Modell des MAC-Schichtprotokolls, welches durch 802.4 spezifiziert ist. Der passive Monitor 10 kann somit Einfluss nehmen, ob das Netzwerk richtig arbeitet. Beispielsweise kann der passive Monitor 10 exakt bestimmen, welche Sta tion das Recht zu senden besitzen sollte, indem er das Modell des erwarteten Rahmenverkehrs durchgeht und indem er das Modell mit demjenigen vergleicht, was er tatsächlich beobachtet.
Es gibt verschiedene Vorteile in Verbindung mit dieser Annäherung. Da die Stationen 11 selbst keinerlei spezielle Daten beibehalten müssen, die den Betrieb des LAN 13 betreffen, wird ein Protokoll für den Austausch von Managementinformationen nicht benötigt. Jede Station 11 braucht lediglich mit dem grundlegenden Netzwerk-Kommunikationsprotokoll, welches für das LAN 13 verwendet wird, konform zu sein. Ferner braucht das Netzwerk, welches überwacht wird, nicht vollständig funktionsfähig zu sein, damit der Monitor 10 erfolgreich arbeitet. Darüber hinaus diagnostiziert der Monitor 10 nicht nur, ob eine Station eine Fehlfunktion hat, sondern kompiliert auch komplette Nachrichtenverkehrstatistiken, ohne dabei die Netzwerkressourcen zu verwenden.
Um zu zeigen, auf welche Weise dies erreicht wird, sei das detaillierte Blockschaltbild des passiven Monitors 10 in Fig. 2 betrachtet. Der passive Monitor 10 enthält ein Nur-Empfang-Modem 15, einen Rahmenprozessor 16, einen Protokollanalysator 18, ein Operatorinterface 19 und eine Anzeige 20.
Das Modem 15 ist ähnlich den Modems, die in den Empfängern der Stationen 11 vorkommen, die an das LAN 13 angeschlossen sind. Indem das Modem 15 in Einklang mit dem 802.4-Standard arbeitet, gibt es eine Reihe von demodulierten Symbolen aus. Die möglichen Symboltypen sind (0) und {1}, wie bei der herkömmlichen binären Datensignalgabe, und ein Kein-Daten-Symbol (n), welches in dem 802.4-Standard verwendet wird, um die Felder abzugrenzen, die für sowohl die Daten- als auch Steuerrahmen definiert sind. Das Modem 15 gibt auch eine Anzeige über die Stärke des Hochfrequenz-Signalempfangspegels auf dem Medium 12 aus.
Der Rahmenprozessor 13 ist ähnlich denjenigen, die in den Empfängern der Stationen 11 vorkommen, die an das LAN 13 angeschlossen sind. Der Rahmenprozessor 16 konvertiert die Folgen der Symbole aus dem Modem 15 in Rahmen (frames), und zwar in Einklang mit dem 802.4-Protokoll. Der Rahmenprozessor 16 führt somit die Funktionen der MAC-Schicht durch und gibt Daten- und Steuerrahmen an den Protokollanalysator 18 aus.
Der Rahmenprozessor 16 detektiert fehlerhafte Symbolsequenzen, Rahmensteuerfelder, Rahmenprüfsummen und Ähnliches ebenfalls in Einklang mit 802.4, um zu bestimmen, ob jeder empfangene Rahmen gültig ist. Die Ausgangsgröße des Rahmenprozessors 16 enthält somit Informationen, welche die gültigen Rahmen betreffen als auch gültige Daten und gültige Steuerrahmen betreffen. Der Rahmenprozessor 16 erkennt auch bestimmte Symbolsequenzen, wie beispielsweise einen Ruhezustand (silence).
Der Protokollanalysator 18 wird in bevorzugter Weise als ein Computer implementiert, der eine geeignete Software enthält, um die Ausgangsgröße des Rahmenprozessors 16 zu interpretieren. Wenn die Datenraten gegeben sind, die über ein LAN 13 möglich sind, und zwar unter Verwendung des 802.4-Protokolls, besteht der Computer in bevorzugter Weise aus einem Hochgeschwindigkeitsprozessor, der aus einem Bit-Slice oder einer Computertechnologie (RISC) mit reduziertem Befehlssatz konstruiert ist. Die Betriebsweise des Protokollanalysators 18 in Bezug auf die Rahmeninformationen, die durch den Rahmenprozessor 16 ausgegeben werden, stellt den Kern der Erfindung dar.
Der Protokollanalysator 18 sammelt verschiedene Informationstypen, inklusive Statistiken, Ereignisse und Netzwerkattribute. Allgemein gesagt, werden Statistiken in Verbindung mir irgendeiner beachtenswerten Erscheinung erstellt, wie beispielsweise einem Störsignal-Burst, einem wiederholten Rahmen, dem Empfang eines Nicht-Gültig-Rahmens, einem Token-Durchgang, einer Sta tion, die den Ring verlässt oder in diesen eintritt, eine Konkurrenz für den Token und Ähnliches. Statistiken werden für jede Station, die momentan in dem Ring vorhanden ist, aufbewahrt. Das Auftreten dieser Erscheinungen wird in bevorzugter Weise durch Inkrementieren eines Zählers aufgezeichnet und diese werden somit als "Zählungen" bezeichnet. Die Zählungen sind auch Quantitäten, welche diese Verkehrslast auf dem LAN 13 betreffen, wie beispielsweise die Zahl der Rahmen, die von jeder Station 11 ihren Ursprung hat oder ausgeht, oder die Zahl der Bytes der Daten, die durch jede gesendet werden.
Andere Typen der Statistiken umfassen "Raten", die lediglich aus dem Mittelwert der Zählungen pro Zeiteinheit bestehen, und enthalten "Meter", die aus Erscheinungen bestehen, die Einheiten besitzen, wie beispielsweise Zeit oder Leistung (power). Somit sind die beobachtete Token-Rotationszeit und der Empfangspegel Meter.
Ein Event ist ein interessierendes Ereignis, wie beispielsweise eine unerwartete Rahmensequenz oder die Beobachtung, dass eine der Stationen 11 in nicht richtiger Weise aus dem Ring ausgeschieden ist.
Ein vollständigeres Verständnis der Statistiken und Events, die von Interesse sind, ergibt sich aus dem Lesen der späteren Erläuterungen zu den Fig. 5A bis 5D.
Der Protokollanalysator 18 hält die Zählungen und Events für alle Stationen 11 auf dem LAN 13 aufrecht, welches Vorrichtungen wie eine Brücke 14 enthält.
Die Netzwerkattribute bilden Informationen, welche die momentane Konfiguration des LAN 13 betreffen, inklusive der Zahl der Stationen 11, die momentan in dem Ring vorhanden sind, die logische Reihenfolge der Stationen in dem Ring, welche Station früher das Token besaß und welche dieses momentan besitzt, die erwartete Token-Durchgangssequenz und Ähnliches.
Die Ausgangsgröße des Protokollanalysators 18 wird durch den Anzeigeprozessor 19 verarbeitet, um eine Wiedergabe an der Anzeige 20 vorzusehen. Der Anzeigeprozessor 19 und die Anzeige 20 können einfach die Zahl der Zählungen wiedergeben oder das Auftreten eines Events protokollieren, können jedoch auch Alarmnachrichten generieren, wenn eine Zählung einen vorbestimmten Schwellenwert bzw. Schwellenwertmenge überschreitet oder nach bestimmten Events, oder können grafisch die Informationen anzeigen. Der Anzeigeprozessor 19 und die Anzeige 20 sind in bevorzugter Weise in Form eines Computers für allgemeine Zwecke verkörpert.
Fig. 3 ist ein detailliertes Blockschaltbild des Protokollanalysators 18, der einen Eingangsspeicher 31, einen Computer 32, einen Programmspeicher 33 und einen Datenspeicher 34 enthält. Der Datenspeicher 34 ist ferner logisch in separate Blöcke von Daten aufgeteilt, gruppiert in einen Eventspeicher 36, einen Statistikspeicher 37 und einen Netzwerkattributspeicher 38.
Der Eingangsspeicher 31 empfängt die Rahmen, ob nun gültig oder ungültig, von dem Rahmenprozessor 16. Der Eingangsspeicher 31 besteht in typischer Weise aus einem First-in-First-out-(FIFO)- Speicher und hat die Aufgabe, die Rahmeneingangsrate zum Computer 32 zu normieren.
Der Computer 32 arbeitet als ein Interferenzprozessor, um die Sequenz der Daten-, Steuer- und Ungültigkeitsrahmen zu analysieren, die von dem Eingangsspeicher 31 empfangen werden. Wie bereits an früherer Stelle erwähnt wurde, analysiert der Computer 32 die Rahmen, indem er die Rahmensequenzen mit einem internen Modell der erwarteten Rahmensequenzen vergleicht, um Protokollverletzungen zu detektieren und damit auch Stations fehlfunktionen oder Ausfälle. Das Protokollmodell besteht nicht lediglich aus dem erwarteten Verhalten von einer Station, sondern aus einem Modell des erwarteten Verhaltens des gesamten Netzwerks. Das Modell enthält somit Informationen, welche den erwarteten Austausch der Rahmensequenz für das gesamte Netzwerk betreffen.
Das interne Modell des Protokolls ist in bevorzugter Weise in der Sequenz der Instruktionen oder Befehle gespeichert, die in dem Programmspeicher 33 abgespeichert sind. Alternativ können der Computer 32 und der Programmspeicher 33 als ein Expertensystem organisiert werden unter Verwendung einer Interferenzmaschine und einer Wissensbank, wobei die Wissensbank einen Satz von if-then-Produktionsregeln enthält, die das Netzwerkprotokoll wiedergeben und wobei die Interferenzmaschine dafür geeignet ist, um die Wissensbank nach angezeigten Schlussfolgerungen durchzusehen, basierend darauf, welcher Verkehr auf dem LAN 13 tatsächlich beobachtet worden ist.
Ungeachtet der Implementierungsdetails des Protokollanalysators 18, besteht das Ergebnis der Betriebsweise des Computers 32 darin, Events, Statistiken und Attributdaten in dem jeweils einen der Eventspeicher 36, Statistikspeicher 37 oder Attributspeicher 38 zu speichern. Der Eventspeicher 36, der Statistikspeicher 37 und der Attributspeicher 38 bestehen in bevorzugter Weise aus Dualportspeichern mit wahlfreiem Zugriff (RAMs), so dass sowohl der Computer 32 als auch das Operatorinterface 19 (Fig. 1) diese gleichzeitig zugreifen können.
Um die Sequenz der Operationen, die durch den Computer 32 durchgeführt werden, besser zu verstehen, ist es wichtig, zuerst die verschiedenen Rahmenformate zu verstehen, die durch den 802.4-Standard definiert werden, wie dies in den Fig. 4A bis 4C gezeigt ist. Alle gültigen Rahmen enthalten eine Anzahl von Subfeldern, wobei jedes Subfeld ein oder mehrere Octets (das heißt Gruppen von 8 Symbohlen) umfasst. Wie in Fig. 4A gezeigt ist, enthalten die Subfelder in der Reihenfolge ein PREAMBLE-Feld, welches dazu verwendet wird, die Empfängermodems zu synchronisieren, ein SD-Feld, welches als ein Starttrennzeichen verwendet wird, ein FC-Feld, welches als Rahmensteuerfeld verwendet wird, DA- und SA-Felder, die als Bestimmungsortadressen- und Quellenadressenfelder jeweils verwendet werden, ein DATA_UNIT-Feld von 0 oder mehreren Octets, welches als ein Datentransfermechanismus verwendet wird, ein FCS-Feld, welches als eine Rahmenprüfsequenz verwendet wird, und ein ED-Feld, welches als ein Endetrennzeichen verwendet wird.
Der Protokollanalysator 18 hat speziell die Aufgabe, das FC- Feld von jedem Rahmen zu analysieren. Die möglichen FC-Felder in Einklang mit dem 802.4-Protokoll sind in den Fig. 4B und 4C gezeigt, wobei die Steuerrahmen-FC-Felder in Fig. 4B gezeigt sind und die Datenrahmen-FC-Felder in Fig. 4C gezeigt sind.
Der 802.4-Standard definiert die Steuerrahmen, welche enthalten einen claim_token (CLM), solicit_successor_1 (SS1), solicit_successor_2 (SS2), who_follows (WHO), resolve_ contention (RSV), token (TOK) und set_successor (SET) Rahmen. Der Zweck von jedem dieser Rahmen wird in dem Standard dargestellt, speziell in dem Abschnitt 5.1 der Grundoperation.
Da der Standard unter Bezugnahme hiermit einbezogen wurde, wird dieser auch hier nicht ausführlich wiederholt. Kurz gesagt, stellt der Tokenrahmen jedoch das Recht zu senden dar. Dieses wird normalerweise von Station zu Station durchgeschleust in einer absteigenden nummerischen Reihenfolge der Stationsadressen. Wenn eine Station ein Token hört, der an sie selbst adressiert ist, nimmt sie an, dass sie nun das Recht zu senden erlangt hat. Wenn eine Station den Sendevorgang beendet, sendet sie einen Tokenrahmen zu der Station gemäß der nächst niedrigeren Adresse in dem Ring. Wenn die sendende Station keinen Verkehr wahrnimmt, nachdem sie versucht hat, den Token zu deren Nachfolger 2-mal weiterzugeben, verwendet sie who_follows, um die Adresse der nächsten Station in dem Ring zu bestimmen. Irgendeine antwortende Station verwendet den set_successor-Rahmen, um der Ursprungsstation zu sagen, welche die neue Nachfolgestation ist.
Die solicit_successor_1-Rahmen werden periodisch durch jede Station ausgesendet, um nach der Beendigung des Sendevorgangs zu bestimmen, ob irgendwelche neuen Stationen den Wunsch haben, zu dem Ring hinzugefügt zu werden, und zwar zwischen der gegenwärtigen oder momentanen Station und deren Nachfolgerstation.
Wenn keine Antwort auf ein who_follows gehört wird, wird ein solicit_successor_2-Rahmen ausgesendet, der jede Station fragt, zu antworten.
Es werden die resolve_contention-Rahmen dazu verwendet, die Situation zu beruhigen, bei der mehr als eine Station versucht, auf ein who_follows, mit einem solicit_successor_1 oder einem solicit_successor_2 zu antworten.
Die Fig. 4C zeigt die FC-Felder für verschiedene Datenrahmen. Hierbei sind von Interesse die request with_no_response-(DT)- (oder normale Daten), request_with_response-(RR)- und Antwort- (IR)-Rahmenformate.
Wie an früherer Stelle beschrieben wurde, detektiert und isoliert der passive Monitor 10 Betriebsfehler bei einer ausfallenden Station, indem er passiv die Steuerrahmensendungen auf dem Bus beobachtet, den Betrieb des Protokolls auf dem Bus mit demjenigen, was erwartet wird, vergleicht, und indem er darauf hinweist, dass ein Fehler aufgetreten ist und auch welche Station den Fehler verursacht. Detaillierte Flussdiagramme, auf welche Weise dies erreicht wird, sind in den Fig. 5A bis 5C gezeigt. Anhand einer Zusammenfassung führt der Protokollanalysator 18 mehrere Dinge durch, basierend auf seiner Beobachtung der Rahmensequenzen. Wenn beispielsweise das letzte von dem Rahmenprozessor 16 detektierte Ereignis war
(A) kein Rahmen (siehe Fig. 5A in Verbindung mit mehr Einzelheiten),
das Übertragungsmediumkabel 12 ist gebrochen oder das Kopfende ist ausgefallen, wenn eine periodische Stille nicht gehört wird; so kann ein Kabel oder ein Kopfendeausfall aufgetreten sein, wenn keine Rahmen empfangen bzw. gehört werden; oder
(B) es handelte sich um einen nicht gültigen Rahmen (siehe Fig. 5B in Verbindung mit Einzelheiten),
der Sender einer Station ist ausgefallen, wenn dieser ungültige Rahmen sendet, wie dies durch das Modem 15 angezeigt wird;
der Sender einer Station ist ausgefallen oder sendet auf einem falschen Leistungswert oder der Kabelsystempfad zu der Station ist ausgefallen oder nicht korrekt gedämpft, wenn der empfangene Signalpegel, der gemessen wird, außerhalb eines vorbestimmten Bereiches liegt; oder
es können Kollisionen aufgetreten sein, wenn ungültige Rahmen detektiert wurden und auch ein Konflikt zur Steuerung des Rechtes zu senden ist möglich;
(C) ein Datenrahmen (siehe Fig. 5B in Verbindung mit Einzelheiten),
der Empfänger einer Station ist ausgefallen, wenn diese nicht in korrekter Weise auf Antwortanfragen antwortet, wie beispielsweise dann, wenn RR-Rahmen unmittelbar einem anderen RR-Rahmen nachfolgen; oder
eine Station ist ausgefallen, wenn einem IR-Rahmen kein RR-Rahmen vorausgeht;
(D) ein Nicht-Token-Steuerrahmen (siehe Fig. 5C in Verbindung mit Einzelheiten),
es kann eine Station ausgefallen sein, wenn sie SET- Rahmen sendet, nicht gefolgt von einem WHO-Rahmen, was einen häufigen Netzwerk-Wiedereintritt anzeigt;
eine Station kann ausgefallen sein, wenn deren Adresse sich in dem DATA_UNIT-Feld eines WHO-Rahmens befindet, der durch den laufenden oder momentanen Token-Halter ausgegeben wird;
eine Station kann ausgefallen sein, wenn sie die WHO- Rahmen mit einem SA-Feld sendet, gleich dem momentanen Token-Halte-Nachfolger in dem Ring,
eine Station ist ausgefallen, wenn sie einen SS1- Rahmen mit einem SA-Feld größer als deren DA-Feld sendet;
eine Station ist ausgefallen, wenn sie einen SS2- Rahmen mit einem SA-Feld kleiner als oder gleich deren DA-Feld sendet; oder
(E) ein Token-Steuerrahmen (siehe Fig. 5D in Verbindung mit Einzelheiten),
eine Station kann ausgefallen sein, wenn sie in richtiger Weise aus der Ringteilnehmerschaft ausscheidet, was dadurch bestimmt wird, indem die erwartete Token-Durchgangssequenz mit der beobachteten Token-Durchgangssequenz verglichen wird;
der Zeitschlitzwert einer Station kann falsch gesetzt sein, wenn die gemessene Stilleperiode nach bzw. zwischen einem SS1- oder SS2-Rahmen und dem nächsten TOK-Rahmen außerhalb des korrekten Bereiches liegt;
der Empfänger einer Station ist ausgefallen, wenn das Token zu dieser von deren Vorbesitzer wiederholt übergeben wird; oder
das Netzwerk ist entweder beschädigt oder es gibt mindestens eine ausgefallene oder fehlerhafte Station, wenn die Zeit, die benötigt wird, um das Token um den Ring herum durchzuschicken, einen geeigneten vordefinierten Wert überschreitet.
Um nun auf die Fig. 5A bis 5D spezieller einzugehen, so kann die Betriebsweise des Protokollanalysators 18, um zu bestimmen, ob eines oder mehrere der oben aufgelisteten Ereignisse (Events) aufgetreten ist bzw. sind, nun verstanden werden.
In Fig. 5A setzt nach einem Startschritt 100 ein Inizialisierungsschritt 102 die geeigneten internen Variablen zurück, wie beispielsweise die Inhalte des Netzwerkattributspeichers 38, der eine Aufzeichnung der momentanen Token-Halter enthält, Aufzeichnungen enthält, die den laufenden Zustand des Ringes beschreiben, wie beispielsweise den erwarteten Nachfolger für jede Station und Ähnliches. Der nächste Schritt 104 wird als ein Eintrittszustand A von anderen Schritten in dem Programm verwendet, wann immer ein neuer Rahmen erwartet wird.
Der nächste Schritt 106 besteht darin, zu bestimmen, ob der Rahmenprozessor 16 momentan Ruhe wahrnimmt bzw. hört. Wenn Ruhe detektiert wird, wird die Steuerung zu dem Schritt 108 übergeben, von dem aus zurückgeschritten wird auf den Schritt 106, wenn nicht eine Ruhe länger als die vorbestimmte Zeitdauer empfangen wurde (das heißt, es ist eine Ruhezeitüberschreitung gegeben). Wenn eine Ruhezeitüberschreitung aufgetreten ist, verläuft die Steuerung zu dem Schritt 110, bei dem bestimmt wird, ob der letzte empfangene Rahmen ein SS2 war. Wenn die Antwort ja lautet, kann angenommen werden, dass das Netzwerk in gültiger Weise in einen Zustand eingetreten ist, in dem lediglich eine Station aktiv ist und es wird dies als ein Ereignis (Event) bei dem Schritt 112 berichtet. Wenn jedoch SS2 bei dem Schritt 110 nicht der letzte empfangene Rahmen war, wird bei dem Schritt 113 ein Tot-Bus-Ereignis (Event) berichtet. Bei beiden Ereignissen wird die Steuerung zu dem Schritt 114 überführt, bei dem auf die nächste Nicht-Ruhe-Anzeige von dem Modem 15 gewartet wird und wobei dann auf A zurückgekehrt wird (Schritt 104).
Wenn bei dem Schritt 106 irgendetwas anderes als Ruhe oder Schweigen gehört wird, wird angenommen, dass eine Rahmensequenz begonnen wurde und die Steuerung wird zu dem Schritt 115 übergeben, bei dem nach einem Starttrennzeichen gesucht wird. Nach dem Empfang eines Starttrennzeichens wird ein Rahmen empfangen und die Steuerung gelangt zu B (Schritt 150) in Fig. 5B.
Wenn jedoch dann Schweigen oder Ruhe erneut gehört wird, muss ein Störsignal-Burst aufgetreten sein. Dies wird bei dem Schritt 117 gezählt und die Steuerung gelangt dann zurück zu A.
Wenn andererseits Ruhe oder das Schweigen bei dem Schritt 116 nicht erneut gehört wird, gelangt die Steuerung zu dem Schritt 118. Der Störsignal-Burst muss fortgesetzt werden und bei dem Schritt 118 wird bestimmt, ob eine vorbestimmte Störsignal- Burst-Zeitüberschreitungsperiode verstrichen ist. Wenn dies nicht der Fall ist, kehrt die Steuerung zu dem Schritt 115 zurück. Wenn die Zeitüberschreitungsperiode verstrichen ist, wird bei dem Schritt 119 ein Kabelbruchereignis berichtet, das heißt eine Anzeige gegeben, dass eine Unterbrechung des Mediums 12 vorliegen kann und es wird bei dem Schritt 120 erneut auf eine Ruhe oder Schweigen gewartet, bevor zu A zurückgekehrt wird.
Die anfänglichen Schritte, die nach der Anzeige des Empfanges eines Rahmens ausgeführt werden, sind in Fig. 5B gezeigt. Von B gelangt die Steuerung zu dem Schritt 151, wo bestimmt wird, ob der Rahmen gültig war. Wenn ein ungültiger Rahmen empfangen worden ist, gelangt die Steuerung zu dem Schritt 155.
Bei dem Schritt 155 wird zuerst bestimmt, ob ein nicht gültiger Rahmen möglicherweise durch einen Konflikt in Verbindung mit der Steuerung des LAN 13 verursacht worden ist, das heißt zwei oder mehrere Stationen weisen Kollisionen auf, indem sie versuchen, zur gleichen Zeit zu senden. Ein Konflikt ist möglich, wenn der letzte empfangene Rahmen ein SS1, SS2, WHO, CLM oder RSV war. Ein Konflikt ist nicht möglich, wenn irgendein anderer Rahmentyp unmittelbar zuvor empfangen wurde. (Die SET-Rahmen werden bei dieser Bestimmung ignoriert.) Wenn dies zutrifft, wird bei dem Schritt 158 eine mögliche Kollision gezählt. Wenn dies nicht zutrifft, wird eine Störsignalzählung bei dem Schritt 157 durchgeführt. Bei dem Schritt 157 können getrennte Störsignalzähler für unterschiedliche Typen von gültigen Rahmen gehalten werden. Die Steuerung kehrt dann von entweder dem Schritt 156 oder 157 zu A zurück.
Wenn der Rahmen bei dem Schritt 151 ein gültiger Rahmen war, gelangt die Steuerung zu dem Schritt 152, bei dem der Empfangspegel geprüft wird. Wenn dieser außerhalb vordefinierter Grenzen liegt, wird ein Event gemäß einem Empfangspegel außerhalb der Grenzen bei dem Schritt 153 berichtet und die Steuerung kehrt zu A zurück.
Bei dem Schritt 154 wird eine Bestimmung durchgeführt, welcher Typ des gültigen Rahmens gehört worden ist. Wenn es ein Datenrahmen war, verläuft die Steuerung zu dem Schritt 158; wenn es ein Nicht-Token-Steuerrahmen war, verläuft die Steuerung zu C (dem Schritt 200 in Fig. 5C); und wenn es ein Token-Rahmen war, verläuft die Steuerung zu D (Schritt 250 in Figur D).
Nach dem Empfang eines gültigen Datenrahmens verläuft die Steuerung zu dem Schritt 158. Der nächste Test besteht darin zu bestimmen, ob der frühere Rahmen ein Token war. Wenn dies der Fall ist, wird der momentane Token-Halter auf die frühere Bestimmungsadresse des Token-Rahmens bei dem Schritt 159 gesetzt. Somit nimmt der Protokollanalysator 18 nicht an, dass ein Token-Durchgang stattgefunden hat bis dieser tatsächlich einen Datenrahmen beobachtet, der durch die Bestimmungsstation ausgegeben wurde, die durch den letzten Token angezeigt worden ist.
Daher braucht im Gegensatz zu anderen möglichen Überwachungsschemata der Analysator 18 nicht zu fordern, dass SA des Datenrahmens derjenige des Token-Halters sein muss. Dies ermöglicht eine richtige Aufzeichnung von Verkehrsstatistiken von den Brücken.
Die Steuerung gelangt dann zu dem Schritt 160, bei dem der MAC- Aktionsabschnitt des FC-Feldes geprüft wird, um den request with response-(RR)-Rahmen oder einen normalen Datenrahmen zu bestimmen, wobei die Steuerung zu dem Schritt 168 verläuft. Wenn es sich jedoch um eine Antwort (IR) oder einen re quest_with_response-(RR)-Rahmen handelt, gelangt die Steuerung jeweils zu dem Schritt 164 oder 161.
Wenn bei dem Schritt 161 ein RR-Rahmen der letztgehörte war, wird bei dem Schritt 162 ein Wiederholungs-RR gezählt. Dies kann anzeigen, dass der Empfänger des RR-Rahmens ausgefallen ist. Wenn dies nicht der Fall ist, verläuft die Steuerung zu dem Schritt 168.
Wenn bei dem Schritt 164 ein IR durch einen RR-Rahmen nicht vorangegangen wird, wird bei dem Schritt 165 ein unerwarteter Rahmen für die Stationen berichtet, die durch die Quellenadressen-(SA)- und Bestimmungsort-Adressen-(DA) -Felder des momentanen Rahmens angezeigt werden, und zwar zusammen mit dem detektierten unerwarteten Rahmentyp.
Von entweder dem Schritt 162 oder 165 kehrt die Steuerung zu A zurück. Bei dem Schritt 168 wird das SA-Feld des momentanen Rahmens mit der laufenden Token-Halteradresse verglichen. Wenn diese gleich sind, werden bei dem Schritt 169 der Rahmen, der seinen Ursprung von einer Station an dem LAN 13 hat, und Stationstypzählungen genommen. Wenn diese jedoch nicht gleich sind, wird bei dem Schritt 170 die Schlussfolgerung gezogen, dass der Rahmen seinen Ursprung von einer Brücke hat, die an das LAN 13 angeschlossen ist und somit stellt SA die aktuelle Adresse einer Station dar, deren Rahmen durch die Brücke 14 geliefert werden.
Somit wird im Gegensatz zu den herkömmlichen Monitoren der Token-Halter in einer solchen Weise aufgezeichnet, dass die mögliche Existenz einer Brücke 14 mit in Betracht gezogen wird. Indem mit dem Token-Halter in der hier beschriebenen Weise Schritt gehalten wird, kann der Protokollanalysator 18 die Schlussfolgerung ziehen, dass alle Rahmen, die nach einem Token-Durchgang zu der Brücke 14 gesendet wurden, von den Sta tionen 11 stammen, die an die Brücke angeschlossen sind, bis der Protokollanalysator 18 einen anderen Token-Durchgang durch die Brücke feststellt oder sieht. Dies ermöglicht es dem Protokollanalysator 18, Brücken-Verkehr-Statistiken und andere Brücken-Managementdaten zu halten oder zu speichern.
In Fig. 5C ist ein Prozess zur Handhabung eines Nicht-Token- Steuerrahmens gezeigt. Wenn von C aus, dem Schritt 200, der Nicht-Token-Steuerrahmen ein CLM, RSV, SET, WHO, SS1 oder SS2 ist, verläuft die Steuerung jeweils zu den Schritten 202, 204, 206, 210, 218 oder 224.
Für einen CLM-Rahmen wird bei dem Schritt 202 der Token-Halter gleichgesetzt mit dem SA-Feld, es wird bei dem Schritt 203 ein Anspruch gezählt und die Steuerung kehrt nach A zurück.
Bei einem RSV-Rahmen wird bei dem Schritt 204 der Token-Halter gleich dem SA-Feld gesetzt, es wird eine Auflösung bei dem Schritt 205 gezählt und die Steuerung kehrt nach A zurück.
Bei einem SET-Rahmen beim Schritt 206 wird zuerst bestimmt, ob ein WHO-Rahmen früher empfangen worden ist. Wenn dies der Fall ist, ist mit der Sendestation alles in Ordnung und die Steuerung verläuft nach A. Wenn dies nicht der Fall ist, so scheint es sich um ein Ereignis einer Ringänderung bzw. von deren Konfiguration zu handeln und es wird bei dem Schritt 207 ein Zählwert aufgezeichnet. Der Zählwert hört immer dann auf, wenn eine Station in den Ring eintritt oder diesen willkürlich verlässt. Wenn auf ein SS1 oder SS2 das frühere TOK gefolgt ist, so tritt die Station ein, während sie im anderen Fall den Ring verlässt.
Der Schritt 210 stellt den ersten Schritt dar, bei dem WHO-Rahmen gehandhabt werden. Die Idee dabei ist, zu bestimmen, ob es der Sender des Token-Halters oder der Empfänger des Nachfolgers ist, der ausgefallen ist. Wenn das SA-Feld des WHO-Rahmens dem Token-Halter entspricht bzw. diesem gleich ist, wird bei dem Schritt 211 entschieden, dass die Station, die durch das DATA_UNIT-(DU)-Feld angezeigt wird, ausgefallen sein muss, da der Token-Halter anfragt, welche Station dieser folgt.
Eine typische Sequenz von Rahmen, die beim Schritt 211 ankommen, ist wie folgt, so als ob die Station, zu der das Token übergeben werden sollte, einen ausgefallenen Empfänger besitzt:
TOK A B (Empfänger von B ist schlecht)
nichts
TOK A B
nichts
WHO A X B (X ist irgendeine Station)
(erster Parameter ist SA, SET C A C zweiter Parameter ist DA, TOK A c dritter ist DU für WHO und SET)
In diesem Szenario versucht die Station A, das Token zur Station B zu leiten und der Empfänger von B ist fehlerhaft oder ist vollständig ausgefallen. Nachdem keine Bestätigung während einer vorbestimmten Zeitablaufperiode gehört wird, versucht es A erneut. Nach dem zweiten Fehlschlag gibt A ein WHO B ab und fragt an, dass irgendeine Station antworten soll. Die Station C antwortet und A übergibt dann das Token an C. Somit ist bei diesem Szenario SA des WHO-Rahmens das Gleiche wie beim momentanen Token-Halter.
Wenn jedoch das SA-Feld in dem WHO-Rahmen der erwarteten Nachfolgerstation des Token-Halters entspricht oder gleich ist, wie dies durch das vorliegende Modell der erwarteten Token-Übergabesequenz angezeigt wird, die in dem Konfigurationsspeicher 38 gehalten wird, wird WHO gegenüber der durch SA angezeigten Station gezählt, die dann einen ausgefallenen Sender haben muss.
Als ein Beispiel, auf welche Weise dies auftreten kann, wenn A das Token besitzt, jedoch dessen Sender schlecht ist, sei die folgende Steuerrahmensequenz betrachtet:
TOK C A (der Sender von A ist schlecht)
Datenrahmen
...
TOK A B **
nichts
TOK A B ** (der Monitor denkt weiterhin, dass nichts C der Token-Halter ist)
WHO A X B
(** Diese TOK-Rahmen werden als ungültig interpretiert, da Tx von A schlecht ist)
Da der Sender der Station A schlecht ist, wird die versuchte Token-Übergabe von A nach B niemals durch B oder den Monitor erkannt. Der Monitor denkt somit, dass C weiterhin noch der Token-Halter ist. Der Monitor weiß jedoch, dass A der Nachfolger von C ist und er wechselt somit den Fehler nach A mit der Schlussfolgerung, dass der Sender von A eine Fehlfunktion aufweisen muss.
Wenn bei dem Schritt 218 das SA des WHO-Rahmens nicht der Nachfolgeradresse des Token-Halters entspricht bzw. mit dieser gleich ist, hat der Monitor den Gleichlauf mit dem momentanen Netzwerkzustand verloren und berichtet einen unerwarteten Rahmen.
Nach dem Empfang eines SS1-Rahmens wird bei dem Schritt 218 bestimmt, ob das SA-Feld gleich ist dem Token-Halter. Wenn dies der Fall ist und wenn SA kleiner ist als DA, ist es bei dem Schritt 221 bekannt, dass eine Schlitzzeitverzögerung beobachtet wird und es wird somit ein Zeitgeber gestartet. Wenn jedoch die Antwort bei dem Schritt 218 nein lautet, wird ein unerwartetes Rahmenereignis berichtet, da die SS1-Rahmen lediglich durch die Stationen gesendet werden sollen, die SA kleiner als DA besitzen, das heißt die Stationen, die nicht am Ende des Ringes liegen.
Der Prozess ist für die SS2-Rahmen vom Schritt 224 an ähnlich. Es wird jedoch bei dem Schritt 225 erwartet, dass das SA-Feld größer ist als das DA-Feld. Wenn SA nicht größer ist oder gleich ist dem Token-Halter, wird der Rahmen überprüft, um festzustellen, ob es ein solicit-any ist, was bei dem Schritt 229 erfolgt. Wenn dies der Fall ist, wird dies bei dem Schritt 230 gezählt. Dieses Ereignis zeigt normalerweise an, dass eine einzige Station an dem LAN 13 den Versuch unternimmt, sich um Kommunikationen zu bewerben (solicit).
Die Steuerung kehrt von jedem der Nicht-Token-Rahmenbefehlssequenzen in Fig. 5C nach A zurück.
Fig. 5D enthält die Sequenz der Schritte, die für einen Token- Rahmen ausgeführt werden. Von D aus, dem Schritt 250, wird bei dem Schritt 252 bestimmt, ob SA gleich ist dem früheren Token- Rahmen SA. Wenn dies der Fall ist, wird bei dem Schritt 253 ein Wiederhol-Token gezählt und die Steuerung kehrt nach A zurück.
Wenn dies nicht der Fall ist, wird bei dem Schritt 254 bestimmt, ob SA gleich ist dem früheren DA-Feld des Tokens. Wenn dies der Fall ist, wird dies erwartet. Wenn dies nicht der Fall ist, hat der Monitor entweder die Spur des Token-Übergabezustandes des Netzwerks verloren oder wird initialisiert. Bei dem Schritt 255 wird bestimmt, ob die SA-Adresse gleich ist dem Nachfolger von dem früheren DA-Feld des Token-Rahmens. Wenn dies falsch ist, ist ein unerwartetes Rahmen-Event vorhanden. Dies ereignet sich beispielsweise, wenn der Monitor einen Token-Durchgang vermisst hat. Wenn jedoch die Antwort bei dem Schritt 255 ja lautet, ist der Monitor in der Tat verlustig gegangen und es erfolgt eine Zählung bei dem Schritt 257, dass dieser wenigstens einen Token-Durchgang versäumt hat. Die Steuerung kehrt nach A bei beiden Events zurück.
Der Schritt 260 wird ausgeführt, wenn der Token-Rahmen in einer erwarteten Sequenz lag. Hier wird das DA-Feld des vorhandenen Tokens gegenüber der erwarteten Token-Durchlaufsequenz in der gespeicherten Ringkonfiguration geprüft, um den erwarteten Nachfolger zu bestimmen. Wenn diese nicht gleich sind, dann hat eine Station entweder den Ring verlassen oder wurde zu diesem hinzugefügt und es wird dann bei dem Schritt 261 ein Ringänderungsevent berichtet. Dies ist auch die geeignete Stelle, um die Ringkonfiguration in dem Attributspeicher 38 auf den neuesten Stand zu bringen.
Als Nächstes wird bei dem Schritt 264 bestimmt, ob der frühere Rahmen ein SS1 oder SS2 war. Wenn dies so ist, wird bei dem Schritt 265 ein Takt des früheren Zeitschlitzintervalls gelesen.
Wenn bei dem Schritt 268 das DA weniger oder kleiner ist als SA, was den üblichen Fall darstellt, wenn das Token von Station zu Station in der absteigenden Reihenfolge der Adresse weitergereicht wird, verläuft die Steuerung zu dem Schritt 270, bei dem der Ringgrößezähler inkrementiert wird. Wenn dies jedoch nicht der Fall ist, hat sich der Ring gedreht, das heißt es ist ein Rücklauf des Tokens von der niedrigsten zur höchsten Adressenstation aufgetreten und es kann bei dem Schritt 269 die Token-Rotationszeit berichtet werden. Die Steuerung verläuft bei beiden Events zu dem Schritt A.
Die vorangegangene Beschreibung ist auf eine spezifische Ausführungsform der Erfindung beschränkt. Es ist jedoch offensichtlich, dass Abwandlungen und Modifikationen bei der Erfin dung vorgenommen werden können, und zwar mit Erreichen von einigen oder von allen Vorteilen der Erfindung. Beispielsweise kann die Erfindung so angepasst werden, dass sie mit anderen Token-Busprotokollen, anderen Token-Übergabeprotokollen und selbst mit anderen Protokollen, die Steuerrahmen austauschen, arbeitet. Es ist daher Gegenstand der anhängenden Ansprüche, alle solchen Abwandlungen und Modifikationen mit zu erfassen, so dass diese in den Rahmen der Erfindung fallen.

Claims

1. Verfahren zur passiven Überwachung eines im Betrieb befindlichen Datenkommunikationsnetzwerks (13), wobei das Netzwerk (13) eine Vielzahl von Stationen (11) enthält und die Stationen (11) durch Austauschen von Daten und von Steuerinformationen in Einklang mit einem Protokoll kommunizieren, wobei das Überwachungsverfahren die folgenden Schritte umfasst:

- Passives Detektieren (16, 18) von Sequenzen von Steuerinformationen, die aktuell über das Netzwerk übertragen werden und damit Aufrechterhalten eines momentanen Zustandes für das Netzwerk (13); und Bestimmen, ob eine bestimmte Station fehlerhaft arbeitet indem detektiert wird, ob unerwartete Ereignisse aufgetreten sind, wobei das Verfahren dadurch gekennzeichnet ist, daß es die zusätzlichen folgenden Schritte umfasst:

- Speichern (33) von Informationen hinsichtlich der erwarteten Steuer-Frame-Sequenzen, die zwischen zwei Stationen (11) in dem Netzwerk (13) ausgetauscht werden;

- Bestimmen (32), ob unerwartete Steuer-Frame-Sequenzen aufgetreten sind, in dem die detektierten Steuer-Frame-Sequenzen mit den gespeicherten erwarteten Steuer-Frame-Sequenzen verglichen werden; und

- Bestimmen, ob eine bestimmte Station (11) fehlerhaft arbeitet, in dem die unerwarteten Steuer-Frame-Sequenzen überprüft werden.

2. Verfahren zum passiven Überwachen eines im Betrieb befindlichen Datenkommunikationsnetzwerks (13), wobei das Netzwerk (13) eine Vielzahl von Stationen (11) enthält, die Station (11) durch Austauschen von Daten und von Steuerinformationen in Einklang mit einem Protokoll kommunizieren, wobei die Steuerinformationen Steuerframes enthalten, die Quellen (SA) und Bestimmungsort-Adressfelder (DA) enthalten, wobei wenigstens ein Typ eines Steuerframes einen Sendeberichtigungsverfahren-Steuerframe (TOK) enthält, der dazu verwendet wird, um zu steuern, welche Station (11) das Recht hat, zu einem bestimmten Zeitpunkt zu senden, wobei das Verfahren die folgenden Schritte umfasst:

- Passives Detektieren von Sequenzen der Steuerframes, die aktuell über das Netzwerk übertragen werden; und

- Bestimmen, ob eine bestimmte Station (11) fehlerhaft arbeitet, in dem detektiert wird, ob unerwartete Ereignisse aufgetreten sind,

wobei das Verfahren dadurch gekennzeichnet ist, daß es zustätzlich die folgenden Schritte umfasst:

- Speichern (33) von Informationen, die erwartete Änderungen der Steuer-Frames zwischen irgendwelchen zwei Stationen in dem Netzwerk (13) wiedergeben;

- Vergleichen (32) der detektierten Steuer-Frame-Sequenzen mit den gespeicherten erwarteten Austäuschen der Steuer- Frames, um zu bestimmen, ob unerwartete Steuer-Frame-Se quenzen übertragen worden sind und um dadurch zu bestimmen, ob eine bestimmte Station (11) fehlerhaft arbeitet; und

- Aufrechterhalten oder beibehalten (158, 159) einer Sendeerlaubnis-Halter-Aufzeichnung, die die Identität eines momentanen Sendeerlaubnis-Halters anzeigt, wobei die Sendeerlaubnis-Halter-Aufzeichnung, die lediglich nach dem Vergleichschritt auf den neuesten Stand gebracht wurde, bestimmt, daß eine unerwartete Sendeberechtigungsverfahren- Steuer-Frame-Sequenz nicht übertragen worden ist.

18. Monitor (10) für eine passive Beobachtung des Betriebes eines Datenkommunikationsnetzwerks (13), wobei das Netzwerk (13) eine Vielzahl von Stationen (11) enthält, welche Stationen (11) durch Austauschen von Daten und von Steuer-Frames in Einklang mit einem Protokoll kommunizieren, wobei der Monitor folgendes aufweist:

- eine Empfangs-Modemeinrichtung (15) zum Empfangen von Symbolen, welche Signalpegel widergeben, die auf dem Netzwerk (13) gesendet werden;

- eine Frame-Prozessoreinrichtung (16) zum Interpretieren von Folgen von Symbolen, um zu bestimmen, ob eine Folge der Symbole einen Daten-Frame, einen Steuer-Frame oder einen ungültigen Frame in Einklang mit dem Protokoll wiedergibt und um die aktuell empfangenen Frames auszugeben; und

- eine Einrichtung zum Bestimmen, ob eine bestimmte Station (11) fehlerhaft arbeitet,

wobei der Monitor zusätzlich gekennzeichnet ist durch:

einen Protokoll-Analysierer (18), der folgendes enthält:

- eine Speichereinrichtung (33) zum Speichern von Informationen, welche erwartete Sequenzen der Steuer-Frames zwischen irgendwelchen zwei Stationen (11) in dem Netzwerk (13) wiedergeben;

- eine Einrichtung, um zu bestimmen (32), ob eine unerwartete Sequenz der Steuer-Frames empfangen worden ist, in dem die aktuell empfangenen Frames mit den gespeicherten erwarteten Sequenzen der Steuer-Frames verglichen werden; und

- eine Einrichtung zum Ausgeben (19, 20) einer Anzeige von unerwarteten Steuer-Frame-Sequenzen als Ereignisse.