Time Token Rotation Protocol
# Time Token Rotation Protocol

Das Time Token Rotation Protocol (TTRP) ist ein Token-Passing-Verfahren aus der Netzwerktechnik. Es kommt bei FDDI-Systemen zum Einsatz.

Im Gegensatz zu CSMA/CD, wie es bei Ethernet im Einsatz ist, wird beim Token-Passing-Verfahren die Sendeerlaubnis explizit erteilt. Nur die Stationen, die das Sendetoken erhalten, dürfen senden. Um nun bei einem Tokenverlust nicht das ganze System zum Stillstand zu bringen, müssen geeignete Protokolle implementiert werden, um den Verlust zu erkennen und beheben zu können.

Im TTRP wird zwischen den Stationen die mittlere Umlaufzeit des Tokens ermittelt, diese Zeit wird anschließend verdoppelt und als maximaler Grenzwert für die Umlaufzeit des Sendetokens festgelegt. Wird diese Zeit überschritten, liegt eine Störung des Rings vor, und es werden entsprechende Maßnahmen eingeleitet.

## Ablauf im Detail

Das TTRP, auch Target Token Rotation Protokoll genannt, soll eine mittlere Tokenumlaufzeit zwischen 4 ms und 165 ms garantieren. Aus der im Ring ermittelten Target Token Rotation Time (TTRT) wird durch Verdopplung die Tokenumlaufzeit gebildet. Bestandteil des Protokolls sind neben den synchronen und asynchronen Serviceklassen auch die Tokenarten Restricted und Nonrestricted.

Beim Sendemodus im FDDI wird der Early-Token Release verwendet, dies bedeutet, dass eine sendende Station unmittelbar nach dem Senden des letzten Datenpaketes das Token weitergibt.

### Target Token Rotation Time (TTRT)

Durch den sogenannten Claim-Prozess wird während des Ringaufbaus die Target Token Rotation Time (TTRT) bestimmt. Auslösendes Element dieses Prozesses ist die Erstinbetriebnahme des Ringes oder das Einfügen von neuen Stationen in den Ring. Die einzelnen MACs der angeschlossenen Stationen handeln die TTRT untereinander aus. Nach dem Initialisierungsprozess verfügt jede einzelne Station in ihrer MAC über einen sogenannten operativen TTRT, der in die jeweilige Token Rotation Time (TRT) kopiert wird. Darunter kann man sich einfach einen Zähler vorstellen der regelmäßig dekrementiert wird.

### Token Rotation Time (TRT)

Die Token Rotation Time (TRT) dient der Messung der aktuellen Token-Umlaufzeit und der Ermittlung der Differenz zur geplanten Umlaufzeit (TTRT). Hierbei wird der Wert von TRT der aus TTRT kopiert wurde gleichmäßig nach unten gezählt. Beim Eintreffen eines Tokens wird der aktuelle Wert von TRT in den Zähler Token Holding Time (THT) kopiert und der TRT erneut mit dem Wert von TTRT gesetzt.

Trifft das Token rechtzeitig vor Ablauf des TRT ein, so handelt es sich um das oben erwähnten Early-Token, trifft das Token jedoch nach einmaligem Ablauf des TRT ein, so spricht man von einem Late-Token und ein entsprechendes Late-Flag wird gesetzt. Während das Early-Token für synchrone und asynchrone Datenübertragungen verwendet werden kann, kann das Late-Token nur für synchrone Datenübertragungen verwendet werden. Erreicht die TRT mehr als den doppelten Wert der TTRT, so liegt ein Fehler vor.

### Token Holding Time (THT)

Die Token Holding Time (THT) ist ein Zähler der linear dekrementiert wird und bei Ablauf die Freigabe des Tokens erzwingt. Der Token Holding Timer übernimmt vom TRT die Restzeit und bestimmt wie lange eine Station noch asynchron senden darf.

### Nonrestricted Token

Wird das optionale Nonrestricted Token eingesetzt, so gibt es 7 Prioritätsstufen (0–6). Sollte keine Priorität gesetzt werden, so enthält die T_Pri Variable den Wert Null, der für die niedrigste Priorität steht. Entsprechend gilt, hat T_Pri den Wert 6 gilt die höchste Priorität und automatisch steht damit die maximale Sendezeit für die Übertragung der Daten zur Verfügung.

### Restricted Token

Durch die Steuerung einer höheren Protokollschicht lässt sich mit dem Restricted Token die gesamte Bandbreite in einer asynchronen Übertragung nutzen. Beim Restricted Token werden die normalen Steuerungsmechanismen des FDDI ausgeschaltet. Die anfordernde Station nimmt sich ein Nonrestricted Token vom Ring und sendet an eine oder mehrere Stationen die Datenpakete. Hierbei müssen die Datenpakete den für den Empfänger notwendigen Initialisierungsprozess für den Restricted Mode beinhalten. Nach dem Senden der Datenpakete wird ein Restricted Token gelöst, das die empfangenden Stationen ihrerseits in den Restricted Mode gehen lässt. Alle an diesem Extended Dialogue beteiligten Stationen tauschen nun Daten aus und verwenden ausschließlich das Restricted Token. Zumeist beendet die initialisierende Station den Extended Dialogue und setzt wieder das Nonrestricted Token in Umlauf. Während des Restricted Mode ist kein weiterer asynchroner Datenverkehr mehr möglich, ein synchroner Datenverkehr ist hiervon nicht betroffen, da der synchrone Datenverkehr keine Klassifizierung von Tokens kennt. Der Restricted Mode Prozess wird dabei vom Station Management (SMT) des FDDI überwacht und kann durch das Senden eines MAC Frames den Restricted Mode beenden.

