IEEE 802.4 Token Bus

Although the CSMA/CD scheme is widely used in office environment, there is strong reservation about its use in Industrial environment. This is due to the probabilistic nature of the medium-access control mechanism used in CSMA/CD. An unfortunate node might have to wait for an arbitrarily long duration to send a frame. In the worst case, a node might not get a chance at all. This is not acceptable in real-time systems, where important frames should not be held up beyond a certain time limit.

In such situations one possible alternative is to use the Token ring. Here, if there are n nodes and it takes T seconds to send a frame, then no frame in any node ever has to wait more than nT seconds to get a chance. However, the physical implementation is not favored because a break in the ring cable would bring down the entire network.

Hence, the token bus standard was developed, having the robustness of the IEEE 802.3 broadcast cable and the advantage of a ring configuration.

Token bus is a technique in which the stations on the bus or tree form a logical ring; that is, the stations are assigned positions in an ordered sequence, with the last member of the sequence followed by the first. Each station knows the identity of the stations preceding and following it.

A control packet known as the token regulates the right of access. When a station receives the token, it is granted control of the medium for a specified time. The station may transmit one or more packets and may poll stations and receive responses. When the station is done, or time has expired, it passes the token on to the next station in logical sequence. This station now has permission to transmit. Hence steady-state operation consists of alternating data transfer and token transfer phases.

Note that non-token-using stations are allowed on the bus. These stations can only respond to polls or requests for acknowledgment. It should also be pointed out that the physical ordering of the stations on the bus is irrelevant and independent of the logical ordering.

This scheme requires considerable maintenance. The following functions, at a minimum, must be performed by one or more stations on the bus:

Ring initialization: When the network is started up, or after the logical ring has broken down, it must be reinitialized. Some cooperative, decentralized algorithm is needed to sort out who goes first, who goes second, and so on.

Addition to ring: Periodically, non participating stations must be granted the opportunity to insert themselves in the ring.

Deletion from ring: A station can voluntarily remove itself from the ring by splicing together its predecessor and successor.

Fault management: A number of errors can occur. These include duplicate address (two stations think it's their turn) and broken ring (no station thinks that it is its turn).

Here we briefly describe the approach taken for these functions in the IEEE 802 standard.

To accomplish addition to ring, each node in the logical ring has the responsibility of periodically granting an opportunity for new nodes to enter the ring.

While holding the token, the node issues a solicit-successor packet, inviting nodes with an address between itself and the next node in logical sequence to demand entrance. The transmitting node then waits for one response window or slot time (equal to twice the end-to-end propagation delay of the medium). If there is no response; the node passes the token to its successor as usual. If there is one response, the token holder sets its successor node to be the requesting node and transmits the token to it; the requestor sets its linkages accordingly and proceeds.

If more than one node demands to enter the ring, their frames will collide and the token holder will detect a garbled response. The conflict is resolved by an address-based contention scheme. The token holder transmits a resolve-contention packet and waits four response windows. Each demander can respond in one of these windows based on the first two bits of its address.

If the token holder receives a valid response, then it can proceed. Otherwise, it tries again, and only those nodes that responded the first time are allowed to respond this time, based on the second pair of bits in their address. This process continues until a valid response is received, no response is received, or a maximum retry count is reached. In the latter two cases, the token holder gives up and passes the token.

Deletion from ring is a much simpler process. If a node wishes to drop out, it waits until it receives the token, then sends a set-successor packet to its predecessor, instructing it to splice to its successor.

Fault management by the token holder covers a number of contingencies. First, while holding the token, a node may hear a packet indicating that another node has the token. If so, it immediately drops the token by reverting to listener mode. In this way, the number of token holders drops immediately to 1 or 0. A second problem may arise when, upon completion of its turn, the token holder issues a token packet to its successor. The successor should immediately issue a data or token packet. Therefore, after sending a token, the token issuer will listen for one slot time to make sure that its successor is active. This precipitates a sequence of events:

1. If the successor node is active, the token issuer will hear a valid packet and revert to listener mode.

2. If the issuer does not hear a valid packet, it reissues the token to the same successor one more time.

3. After two failures, the issuer assumes that its successor has failed and issues a who-follows packet, asking for the identity of the node that follows the failed node. The issuer should get back a set-successor packet from the second node down the line. If so, the issuer adjusts its linkage and issues a token (back to step 1).

4. If the issuing node gets no response to its who-follows packet, it tries again.

5. If the who-follows tactic fails, the node issues a solicit-successor packet with the full address range (i.e., every node is invited to respond). If this process works, a two-node ring is established and life goes on.

6. If two attempts of step 5 fail, the node assumes that a catastrophe has occurred; perhaps the node’s receiver has failed. In any case, the node ceases activity and listens to the bus.

Logical ring initialization occurs when one or more stations detect a lack of bus activity of duration longer than a timeout value => The token has been lost. This can be due to a number of causes, such as the network has just been powered up, or a token-holding station fails. Once its timeout expires, a node will issue a claim-token packet. Contending claimants are resolved in a manner similar to the response-window process.

As an option, a token bus system can include classes of service that provide a mechanism of prioritizing access to the bus. Four classes of service are defined, in descending order of priority: 6, 4, 2, 0. Any station may have data in one or more of these classes to send. The object is to allocate network capacity to the higher-priority frames and only send lower-priority frames when there is sufficient capacity.

This scheme, within limits, gives preference to packets of higher priority. More specifically, it guarantees that class 6 data may have a certain portion of the capacity.

At very low loads, the token circulation time is very short, and all of the data offered in all four classes are transmitted. As the load increases, the average token circulation time increases, and at threshold points, as the load keeps increasing, low-priority classes are dropped in order. That is, Class 0 is dropped at the first threshold, then at second threshold class 2 is dropped and subsequently class 4 is dropped and we are left with only class 6.

It should be obvious that the principal disadvantage of token bus is its complexity. The logic at each station far exceeds that required for CSMA/CD. A second disadvantage is the overhead involved. Under lightly loaded conditions, a station may have to wait through many fruitless token passes for a turn.

However, this technique has certain advantages. First, it is possible to regulate the traffic in a number of ways. Multiple priority levels can be used, and different stations can be allowed to hold the token for different amounts of time. This type of discrimination is difficult to achieve with CSMA/CD. Second, unlike with CSMA/CD, there is no minimum packet-length requirement with token bus. Third, the necessity for listening while talking imposes physical and electrical constraints on CSMA/CD system; these do not apply to token systems where no station need listen and talk at the same time. Finally, under heavy loads, where it counts, token bus exhibits significantly superior performance to CSMA/CD.

Another advertised advantage of token bus is that it is "deterministic"; that is, there is a known upper bound to the amount of time any station must wait before transmitting. This upper bound is known because each station in the logical ring can only hold the token for a specified time.

In contrast, with CSMA/CD, the delay time can only be expressed statistically. Furthermore, since every attempt to transmit under CSMA/CD can in principle produce a collision, there is a possibility that a station could be shut out indefinitely. For process-control and other real-time applications, this "non-deterministic" behavior is undesirable.