CCNA Exam Cram[tm] 2 (Exams 640-821, 640-811, 640-801)

We have already covered a lot in this chapter, but we really can't move on without going over one last network technology. That technology is Token Ring, a la IBM. You will not see Token Ring questions on the CCNA test per se, but you will need to know about wide area token passing networks, and they are easier to understand if you know about their LAN counterparts.

The Token Ring network architecture has become closely identified with IBM and for good reason. Way back in 1972, IBM announced a Token Ring control method for LANs which was remarkably similar to one developed by a Mr. Willemjin. The IBM announcement sparked a host of license and patent disputes which resulted in Mr. Willemjin becoming a very rich man. This was an apt beginning for IBM's long and painful journey into local area networking.

At the time, IBM owned the global mainframe computing market with few able to compete . Others realized there was no way to take on IBM in the mainframe market, but the new interest in distributed computing held promise. Distributed computing utilized small computers tied together in a network and offered user groups a level of control not possible in mainframe computing. Although IBM now had the Token Ring Architecture free and clear sitting on a back shelf, it viewed the whole trend toward distributed computing as detrimental to continued expansion of the mainframe and as a result nothing happened for more than 10 years. Finally, as IBM watched companies like Digital, Network General, and Wang grow, they decided to act. Of course IBM was not about to legitimize the technologies these upstart companies were using, so something different was needed, and something that was really different had been sitting on a back shelf for over 10 years .

Token Ring was released as a whole new architecture, including special cables, hardware, and even different terms to describe its operation. The concept was sold to large IT departments and while the DP guys didn't especially like the idea, it did give them a way to offer additional services to the user communities and reclaim some of the budget and control they had lost to distributed processing.

Token ring, as the name implies, used a ring structure where each node was physically attached to its neighbors (see Figure 3.8). Data passes from one node to the next in a counterclockwise direction as it traverses the ring. Typically, IBM type one cable was used, which was not much smaller than the old 10BAEE-5 cable. The cable contained heavy gauge twisted pairs of wires wrapped in one or more shields of high density braid and foil. The cable was terminated in a complex connector measuring about 2 inches square, which would allow cables to be joined together or attached to devices such as Multi-Station Access Units ( MSAU ) , which provided a central attachment point for the ring.

The operation of the ring began when the first station was attached or started. That station would send a query over to the ring to see if any other stations were active. If not, the station would assume the role of active monitor and release a token (see Figure 3.7).

Unlike a bus where each node attaches to one shared cable, Token Ring uses a dedicated cable between neighboring nodes. Data must flow from the upstream neighbor, through a dedicated cable to the next downstream node. That node repeats the frame and launches it on the cable attaching it to its next downstream node.

A token is like a data frame but only has a starting delimiter, access control field, and ending delimiter (see Figure 3.8). It is used to notify a node that it may now send data. If the node has data to send, it will change the ID bit in the token to indicate it is now a data frame, attach the data, and transmit the data frame to the next downstream neighbor (see Figures 3.7, 3.8, and 3.9). If there is no data to transmit, the token will be repeated and sent to the next downstream neighbor as is.

If the frame is not addressed to the next downstream neighbor, that node retransmits it to the next downstream node. This process continues until the data frame arrives at the node it is addressed to. That node reads the data frame, changes the frame status field to indicate the frame has been received, and then retransmits the updated frame on to the sending node. At the sending node, the frame is compared to the frame that was sent originally, and if they are identical the node releases a token frame and the whole process starts over. This is the process followed by the standard 4 megabit Token Ring network. A variation of this process has the receiving station release a token after it has read, updated, and sent the original data frame. This variation is called "early token release" and it is used in 16 megabit Token Ring networks. No matter what variation is in use, there can only be one token on the ring at any one time. I think you can see why IBM liked this approach: no collisions, few if any retransmits, and control of cable quality.

So, what happens when a cable is severed? That should stop ring operation, shouldn't it? Well, yes, but even in this situation Token Ring offers some benefits over Ethernet. Each node monitors traffic from its nearest active upstream neighbor ( NAUN ) . There is always a Token frame or Data frame on the ring so there is always traffic. When traffic stops coming from a node's NAUN, that node goes into beacon mode, which will be heard and repeated by all of the downstream nodes. The presence of a beacon on a ring indicates the ring has stopped functioning and a serious problem exists. In addition, the address of the beaconing node indicates the problem is somewhere between it and its NAUN. So not only are serious problems reported , but their location is also identified. Neat eh?

Traffic that moves from one ring to another is handled somewhat differently than Ethernet. To begin with, each ring is a network in its own right, so routing and bridging get a bit mixed. This is one architecture that definitely stretches the OSI model. Notice the routing information field, which is a part of the data frame in Figure 3.9. When data is bridged in a Token Ring environment, a process called source route bridging is used. The initiating node sends several special frames to the receiving node, which echoes the frames back. The route of the frame that returns first is added to the routing information frame of the data frame and the frame is sent to the bridge.

Although Token Ring is a Layer 2 architecture, its frame has a large field for routing information. In this case, the field is used to store instructions for source route bridging.

The bridge does not have to check any tables or determine any routes because the routing instructions are included with the data frame in the routing information field; hence, source route bridging. Data frames can also be encapsulated in routable protocols and follow a more traditional way of moving between networks. This procedure would have to be adopted if the route passed across non-Token Ring networks.

This is as far as we are going to go in Token Ring. Introducing Token Ring earlier in the chapter would have really confused things; we mention it here because it will help build a foundation for things to come. On the test, assume you are dealing with Ethernet unless told otherwise . Speaking of tests, why don't you try the following questions and see how you do?