Token Passing

The token circulates in cycles so that real-time connections can access the network periodically. Because RETHER does not assume a globally synchronized clock, the token cycle time is maintained as a counter called the residual cycle time in the token itself. At the beginning of each cycle, the residual cycle time is set equal to a full token cycle time². When the token visits a node, the node subtracts its token-holding time from this counter. Once the residual cycle time reaches zero³, the token is passed back to the first real-time node and a new cycle begins. Figure shows an example token visit schedule within a token cycle.

  

Figure: Node 1, 3, and 6 are real-time nodes, each of which is assumed to have a token holding time of 6 msec every time the token visits them in the real-time mode. As every network node has non-real-time data to send, ALL network nodes are non-real-time nodes. In this example, the token visits real-time nodes in the first 18 msec of the 33-msec token cycle, and then visits non-real-time nodes in the rest of the cycle in a round robin fashion. Note that the token continues the visiting schedule for non-real-time nodes in the next cycle (Node 6) from where it left off in the previous cycle (Node 5) .

The token-holding time at each node is based on the amount of data the node is allowed to send. For real-time nodes, the bandwidth reservation determines the amount of data that needs to be sent out during every cycle. For non-real-time nodes, the amount of data that can be sent out is limited by the the total unreserved bandwidth and the size of messages in their output queues. RETHER has incorporated a mechanism to ensure that all the nodes use the unreserved bandwidth fairly. When the token visits a node, if it does not have data to send, it merely hands the token to its successor after subtracting the time to process the token.