Rechnernetze
Home Nach oben

Frame-Based Management Protocols

Den dritten und letzten funktionalen Bestandteil innerhalb des Station-Managements bilden die sogenannten Frame-Based Management Protocols. Sie stellen die frame-basierten Dienste zur Verfügung, die den Austausch von Managementinformation zwischen den einzelnen Stationen realisieren.

SMTFRAMEFORMAT.WMF (6686 Byte)

Die Frame-Based Management Protocols werden in erster Linie von den in den höheren Schichten angesiedelten Managementfunktionen benutzt, um Information (z.B. Konfiguration einer Station, Austausch von Zustandsinformation) aus den unteren Protokollschichten zu beziehen und damit eine Kontrollfunktion über das Netzwerk auszuüben.

Für den Austausch von Information (SMT-Nachrichten) wird das SMT Frame-Format verwendet, daß im wesentlichen aus dem MAC Header und der SMT PDU, die in das Info Feld eines Übertragungsrahmen eingebettet ist, besteht (siehe oben).

Im folgenden sollen nun einige Management Protokolle des FDDI-Standards vorgestellt werden.

Neighbor Notification Protocol

Das im FDDI-Protokoll verwendete Frame Based Management Protocol basiert grundsätzlich auf einem Anfrage-Antwort-Modell, bei dem eine einzelne Station oder mehrere Stationen auf eine Anfrage, die nur vom Management Agent Process durchgeführt werden kann, reagieren und eine Antwort zurücksenden. Durchbrochen wird dieser Ablauf lediglich vom dem sogenannten Neighbor Notification Protocol, welches zu bestimmten Zeitpunkten Neighbor Information Frames an eine oder mehrere Zielstationen absendet. Es ermöglicht einer MAC Einheit die Adressen seiner unmittelbaren Nachbarn im Ring zu erlernen und ergänzt die RMT Funktion zur Erkennung von Adreßduplikatsfehlern. Darüber hinaus wird mit Hilfe dieses Protokoll, das in periodischen Abständen aktiviert wird, die Arbeitsweise der Sende- und Empfangspfade im Ring überprüft; auch wenn sonst kein Datenverkehr auf dem Netz erfolgt.

Die Realisierung des NNP erfolgt mit Hilfe von zwei kooperierenden Prozessen; dem Neighbor Notification Transmitter (NNT) und dem Neighbor Notification Receiver (NNR). Der NNT ist verantwortlich für das regelmäßige Aussenden von Neighbor Information Frames (NIF) an die stromabwärts (downstream) gelegene Station, von der sie auch die beantworteten Rahmen entgegennimmt. Der NNT ist somit ein aktiver Prozeß, der in regelmäßigen Abständen (meist alle 30 s) selbstständig einen Rahmen aussendet. Der NNR ist hingegen eine passive Komponente, die nur auf Anfragen der stromaufwärts (upstream) gelegenen Station antwortet. Die Funktionsweise des Neighbor Notification Protocols beruht auf dem Aussenden eines Neighbor Information Frames (SA = fddiMACSMTAddress, DA = Broadcast) und der Auswertung des wieder empfangenen Rahmens. Dazu sendet eine Station, die nach dem Anschalten oder nach einer Rekonfiguration in den Ring integriert werden möchte einen NIF Request an alle Stationen im Ring. Hierfür setzt sie das Upstream Neighbor Address Feld (UNA) und das Downstream Neighbor Address Feld (DNA) des NIF Requests, der im Info Feld einer Frame-PDU übertragen wird, auf 'unkown'. Die erste Station, die den Rahmen erhält kopiert den Rahmen vom Ring, belegt das A und das C Bit des Frame Status Felds und sendet einen NIF Response an die Station, deren Adresse sie aus dem DA Feld entnommen hat, zurück. Darüber hinaus belegt sie die Felder UNA (aus dem DA Feld) und DNA (sofern sie diese kennt) des Antwortrahmens. Alle Stationen, die in der Zwischenzeit ebenfalls den NIF Request erhalten haben, erkennen an dem A und C Bit, daß sie nicht mit einem Response reagieren müssen. Nachdem der Initiator des NIF Requests die NIF Response erhalten hat, kennt er seinen Nachbarn und speichert dessen Adresse. Da das Aussenden von NIF Rahmen in der Regel von allen Stationen in regelmäßigen Abständen durchgeführt wird, sind bereits kurze Zeit nach dem Ausschalten oder Anschalten eines Gerätes alle anderen Stationen über den neuen Zustand informiert.

Status Report Protocol

Das Status Report Protocol wird von den FDDI-Stationen genutzt, um in periodischen Abständen Status Report Frames (SRF) über den Zustand des Rings auszutauschen. Das Status Report Protocol unterscheidet drei verschiedene Gruppen von Bedingungen (Condition_Asserted, Condition Deasserted und Event_Occured), bei denen das Aussenden von Status Report Frames erfolgt. Condition_Asserted Bedingungen (z.B. Duplicate Address Condition, Frame Error Condition, usw.) veranlassen das Status Report Protocol, während der gesamten Dauer dieses Zustandes SRF zu übertragen. Der zeitliche Abstand zwischen zwei Übertragungen muß jedoch mindestens 1 sec. betragen, um das Netzwerk vor einer Überflutung mit SRFs zu schützen. Die beiden anderen Bedingungen werden hingegen lediglich durch das fünfmalige Aussenden eines SRFs angezeigt; der zeitliche Abstand zwischen der ersten und der zweiten Meldung beträgt 2 sec. Danach wird jeweils der Abstand verdoppelt und nach der 5ten Übertragung (32 sec Abstand) eingestellt und der Timer zurückgesetzt.

Parameter Management Protocol (PMP)

Mit Hilfe des Parameter Management Protocols wird einem Netzwerk Manager die Möglichkeit gegeben, bestimmte SMT Variablen zu lesen oder zu verändern. Die hierfür vorgesehenen Übertragungsrahmen (PMF get und PMF set) arbeiten auf der Management Information Base (MIB) und erlauben den Netzwerk Manager mit Hilfe eines Management Protokolls (SNMP, CMIP) Manipulationen an der MIB einer oder mehrerer Stationen vorzunehmen und damit das Verhalten dieser Stationen zu verändern.

Der PMF get Übertragungsrahmen wird von einer Station zum Lesen von Attributen bzw. einer Attributgruppe in einer oder mehreren Stationen verwendet. Als Antwort liefern die angesprochenen Stationen eine PMF get Response zurück, in der die angeforderten Werte enthalten sind. Der PMF set Übertragungsrahmen erlaubt das verändern von Attributwerten, indem er die Bezeichnung und den Wert der zu verändernden Variable überträgt. Da eine Veränderung von Attributwerten eine sehr mächtige Funktion ist, sind zur Absicherung des Protokolls vor einer nicht zulässigen Benutzung sowohl eine Konsistenzkontrolle wie auch eine Zugriffkontrolle eingefügt.

Synchronous Bandwidth Allocation (SBA)

In der vorhergehenden Betrachtung des FDDI-Protokolls wurde festgestellt, daß FDDI sowohl die Verwendung von synchroner als auch von asynchroner Bandbreite unterstützt. Die Verwendung der asynchronen Bandbreite wird durch das Timed Token Rotation Protocol gesteuert, daß in Abhängigkeit von der zur Verfügung stehenden Token Hold Time Übertragungskapazität an die einzelnen Stationen vergibt. Insgesamt ist die für alle Stationen zur Verfügung stehende Übertragungskapazität jedoch durch die bei der Ringinitialisierung ausgehandelte Target Rotation Time bestimmt. Möchte nun eine Station synchrone Bandbreite (etwa für die Übertragung von zeitkritischen Audio- oder Videodaten) in Anspruch nehmen, so muß sie dementsprechend synchrone Bandbreite bei einem zentralen Prozeß (dem sogenannten Synchronous Bandwidth Allocation Process) beantragen, um möglicherweise die bei der Initialisierung ausgehandelte maximale Ringumlaufzeit nicht zu überschreiten – was ein Fehlverhalten des Protokolls zur Folge hätte.

Die benötigte Menge an synchroner Bandbreite wird u.a. durch die fest vorgegebene Menge an Daten (Overhead des FDDI-Protokolls) bestimmt, die für die Erzeugung und Übertragung von synchronen Daten benötigt wird. Zusätzlich muß der Overhead des Vermittlungs- und Transportprokolls (z.B. TCP/IP) berücksichtigt werden, der ebenfalls einen Einfluß auf die benötigte Bandbreite hat. Darüber hinaus ist von der Station die Menge der synchron zu übertragenen Daten zu bestimmen, die als Nutzlast in die Berechnung eingeht. Schließlich ist noch der zeitliche Bedarf festzulegen, der für die Beantragung der synchronen Bandbreite erforderlich ist (z.B. 500 Bytes alle 4 ms oder 1.000 Bytes alle 8 ms).

Mit Hilfe dieser Information kann dann der Prozeß zur Vergabe der synchronen Bandbreite entscheiden, welchen Einfluß die Vergabe der beantragten Daten auf die Ringumlaufzeit hat, und ob sie bewilligt werden kann. Gegenwärtig existierende FDDI-Netze verfügen jedoch in der Regel über keinen Synchronous Bandwidth Allocation Process, so daß nur der asynchrone Datentransfer vom Protokoll unterstützt wird.