Rechnernetze
Home Nach oben

Das Ring Management

Innerhalb des Station-Managements ist das Ring Management für die Kontrolle und die Verwaltung der MAC Einheiten und deren Einbindung in den Ring verantwortlich. Die dazu erforderliche Information erhält das Ring Management sowohl von den MAC Einheiten als auch vom Configuration Management. Wie beim bereits zuvor beschriebenen Connection Managements (ECM, PCM, CFM) wird die Zusammenarbeit mit dem Ring-Management durch einen Automaten realisiert, der bestimmte Zustände annehmen kann und innerhalb dieser Zustände bestimmte Funktionen bzw. Aktionen ausführt. Diese Funktionen umfassen insbesondere

Die Identifikation von festgefahrenen Beacon Prozessen,

das Anstoßen der Trace Funktion,

das Überwachen der MAC-Verfügbarkeit,

das Erkennen von Adress–Duplikaten,

das Auflösen von Adress–Duplikat–Problemen,

die Überwachung des restricted Token Zustands.

Den Ausgangspunkt für die Operationen des Ring Managements bildet der Zustand RM0 (ISOLATED). In diesem Zustand werden von der MAC Einheit keine Aktionen ausgeführt. Die Station befindet sich in einer Ruhephase. Erst durch das Eintreffen eines RM_Join oder RM_Loop Signals vom CFM wird dem RMT mitgeteilt, daß der Aufbau des internen Datenpfads abgeschlossen und eine Übertragung von Daten an das Netzwerk möglich ist. Zu diesem Zweck wird vom RMT ein Wechsel in den Zustand RM1 (NON_OP) vollzogen und ein Reset des MAC Chips durchgeführt, um die Übertragung von Claim und Beacon Frames anzustoßen. Gewinnt die Station den Claim Prozeß, so kann sie unmittelbar einen Wechsel in ihren Zielzustand RM2 (RING_OP) vornehmen und mit der Übertragung von Daten beginnen. Der weitere Ablauf der Datenübertragung wird dann durch das Timed Token Rotation Protokoll gesteuert.

Allerdings kann es während der Abarbeitung des Zustands NON_OP zu Situationen kommen, von denen aus kein Wechsel in den Zustand RING_OP möglich ist. Dieser Fall wird durch das Ablaufen des Timers T_NON_OP angezeigt, dessen Wert (= 0.775 s) so gewählt ist, daß nach Ablauf dieser Zeit von einer fehlerhaften Funktion des Rings ausgegangen werden kann. Wird die Zeitspanne überschritten, so führt die RMT Maschine einen Zustandswechsel in den Zustand RM3 (DETECT) durch und versucht das mögliche Fehlverhalten des Netzwerks zu ermitteln, indem es die oben genannten Aufgaben ausführt.

Eine mögliche Ursache für das Ablaufen des Timers kann in einem festgefahrenen Beacon Prozeß bestehen. Er wird erkannt, wenn eine Station das Beacon Frame aussendet und es nach Ablauf der Zeit T_NON_OP noch nicht zurückerhalten hat. Der Grund für dieses Fehlverhalten kann nur in der Beschädigung des internen Empfangspfads (oberhalb der PHY Schicht), in einer Fehlfunktion der MAC-Einheit selbst oder in einem sogenannten Duplicate Address Problem (hervorgerufen durch die lokale Adreßadministration) liegen, da alle anderen Ursachen bereits durch das CMT erkannt worden wären (eine Beschädigung des Übertragungsmediums wäre bereits durch das CMT aufgedeckt worden; eine Fehlfunktion des Übertragungspfads verhindert nicht den Empfang von Beacon Token). Die Aufgabe des RM3 (DETECT) Zustands besteht also darin, die genaue Ursache des Fehlverhaltens zu ermitteln. Dazu verwendet RMT den D_Max Timer (maximale Ringumlaufzeit, 1,773 ms), der die Zeit bestimmt, die ein Frame auf dem Ring verbleiben kann bevor es die Station wieder erreichen muß, von der es ausgesendet worden ist. Tritt nun der Fall ein, daß eine Station ein Claim oder ein Beacon Frame mit ihrer Sendeadresse erhält, nachdem die Zeit D_Max zweimal abgelaufen ist, so hat sie damit einen sicheren Anhaltspunkt für das Vorliegen eines Adreßproblem. (Die Zeitspanne 2 * D_Max ist erforderlich, um auch im Ring Wrapping Zustand das Adreßproblem sicher erkennen zu können.) Darüber hinaus kann sie hierfür eine Bestätigung erhalten, wenn sie ein Claim Frame mit ihrer Sendeadresse, jedoch mit einem anderen T_Req Wert für die gewünschte Ringumlaufzeit empfängt. Die RMT Zustandsmaschine wechselt dann in den Zustand RM4 (NON_OP_DUP), in dem sie versucht, das Adreßproblem zu lösen.

Die erste Aufgabe die von der RMT Maschine durchgeführt wird, besteht darin, die Station mit der fehlerhaften Adresse aus dem Ringinitialisierungsprozeß herauszuführen und damit den im Ring verbleibenden Stationen die Möglichkeit für den Aufbau einer Datenverbindung zu geben. Zusätzlich versucht die RMT Zustandsmaschine korrektive Mechanismen anzustarten, die zur Lösung des Adreßproblems beitragen. Diese Maßnahmen bestehen in erster Linie im Entfernen aller PDUs, die eine fehlerhafte Quelladresse enthalten, und in der Suche nach einer individuellen Adresse für die fehlerhaft arbeitende Station. Eine Änderung der Adresse kann natürlich nur dann automatisch vorgenommen werden, wenn bereits bei der Initialisierung der Station mehrere Adressen bereitgestellt worden sind (dies ist häufig bei der Verwendung von 16 Bit Adressen der Fall). Neben dem Versuch, eine Adreßänderung durchzuführen, bietet das FDDI-Protokoll die Möglichkeit, ein Beacon Frame des Jam-Typs im Netzwerk zu übertragen, welches sicherstellt, daß die MAC Einheit, die eine ungültige Adresse besitzt, korrektive Maßnahmen ergreift, und eine andere MAC Einheit, die über eine universelle Adresse verfügt, den Claim Prozeß gewinnt. Darüber hinaus kann die fehlerhafte MAC Einheit ganz aus dem Ring entfernt werden; was auch die einfachste und effektivste Möglichkeit zur Lösung eines Adreßproblem ist und auch von den meisten Implementierungen verwendet wird, wenn kein – für die Funktion des Netzes – wichtiges Gerät (z.B. Server, Router, etc.) von dieser Maßnahme betroffen ist. In diesen Fällen wird eine Lösung nach den zuerst beschriebenen Methoden durchgeführt. Während der Zeitspanne, in der das Adreßproblem nicht gelöst ist, wird den fehlerhaft arbeitenden Stationen das Senden von Daten untersagt.

Allerdings besteht auch während der Arbeitsphase der RMT Maschine – also im laufenden Betrieb des Netzwerkes – keine völlige Sicherheit, daß ein Adreßproblem bereits während der Initialisierungsphase des Rings erkannt und gelöst worden ist. Aus diesem Grund kann es auch während der normalen Arbeitsphase des Rings zu Adreßproblemen kommen, die das SMT veranlassen, ein spezielles Frame (FC = 0x4F und DA = SA) auszusenden und einen Kontrollmechanismus auszulösen. Empfängt die Station das Frame und ist das A-Bit gesetzt, so erkennt die Station das Vorliegen eines Adreßproblems und führt die oben beschriebenen Aktionen aus.

Sollte jedoch eine Beschädigung des Empfangspfads für die nicht korrekte Arbeitsweise des Protokolls verantwortlich sein, wird ein Pfadtest (Zustand RM7: TRACE) durchgeführt, bei dem die MAC Einheit in den Loopback Mode geschaltet wird und einen Selbsttest ihrer Verbindungswege durchführt, der bei positiver Beendigung einen Neustart der CMT beinhaltet. Verläuft der Selbsttest negativ, wird ein Ring Wrapping vollzogen und die fehlerhafte Station isoliert.

Neben diesen korrektiven Maßnahmen ist das Ring Management auch für die Überwachung des restricted Token Dialogs verantwortlich, indem einer einzelnen Station das Recht für die ausschließliche Nutzung der asynchronen Bandbreite erteilt wird. Der Zustand des restricted Modes wird erreicht, wenn nach dem Empfang eines nonrestricted Tokens eine Station ein restricted Token auf das Netzwerk überträgt und anschließend ein initiales Frame aussendet. Danach steht dieser Station die volle Bandbreite des asynchronen Verkehrs zur Verfügung. Befindet sich der Ring in diesem restricted Mode, erfolgt durch das RMT eine Überwachung der Übertragungsdauer. Überschreitet der restricted Mode die Dauer von T_Rmode (Rmode ist eine einstellbare Größe), stoppt das RMT die weitere Übertragung und veranlaßt das Aussenden eines nonrestricted Tokens. Damit ist die normale Funktionsweise des Rings wiederhergestellt.