Phasing Ethernet into the Token-Ring Network


If you've decided that you are going to have to embrace the Ethernet network in your Token-Ring shop, the next step is to decide on a plan for making the change. The most disruptive method would be to simply go ahead full force and swap out all the hardware at one time and hope for the best. Depending on your circumstances, that might be the only choice you have. The issue that will help you make this decision is whether you can segment your network into functional components where you can identify which end stations need to communicate with which stations . Why? Because of the fundamental differences between Ethernet and Token-Ring, it can be very difficult in many cases to make the two work together.

There are translational bridges and other internetworking devices you can use to connect Token-Ring LANs to an Ethernet LAN or a backbone joining the two. Using a backbone to provide a high-speed transport to both kinds of networks is not terribly complicated. Asynchronous Transfer Mode (ATM), for example, can be used to carry both kinds of traffic. But without some kind of translation capability to account for the difference in the frame formats, a network of this sort can be limited to allowing Token-Ring stations to talk only to Token-Ring stations, and Ethernet nodes to talk only to Ethernet nodes.

Differences That Make Translation Difficult

There are several reasons why it is not an easy task to make a perfect translation device that can allow Token-Ring and Ethernet nodes to communicate with each other:

  • Canonical versus non-canonical bit ordering

  • Embedded MAC addresses

  • Frame size

  • Notification of delivery (Token-Ring status bits)

  • Token-Ring routing (RIF) information

These issues are discussed in more detail over the course of the next three sections.

Bits and Frames

The most basic difference between these two networking technologies that becomes apparent lies at the beginning of the network transport process: They interpret the ordering of bits for addressing purposes in the opposite direction. That is, although they both use a six-byte MAC address to uniquely identify a network adapter on a LAN, Ethernet considers the first bit in the serial stream to be the low-order bit (the canonical method), whereas Token-Ring considers the first bit to be the high-order bit (the non-canonical method).

This problem can be easily addressed with a hardware device, such as a bridge or router, that reorders the addressing bits depending on what kind of network is attached to the port on which the frame is to be sent. However, there are cases, such as in the Address Resolution Protocol (ARP), where MAC addresses ride in portions of a frame in addition to the addressing fields. Designing a hardware device that can determine all the cases in which this is possible is a daunting task. And, when such an attempt is made, latency factors enter the picture because the device is forced to read much more of the frame than just the header fields that contain the source and destination fields.

Frame size is another important factor. Ethernet networks use a frame size that can be up to approximately 1,500 bytes, whereas Token-Ring uses a frame size that can be a lot higher, possibly up to 17.8KB on a 16Mbps Token-Ring LAN. If the higher-level protocol being transported on the LAN does not allow for fragmenting packets (as TCP/IP does), it is necessary to force the entire network to use the lowest common denominator of Ethernet's 1,500-byte frame.

Notification of Delivery

Token-Ring uses three bits in its frame to notify the sender of what happened to the frame after it was sent out onto the ring. The Address Recognized bit is set when a station recognizes that it is the intended destination of the frame. The Frame Copied bit is set if the destination station can copy the frame from the wire into an internal buffer. The Error bit is used to indicate that some kind of error was encountered in the frame somewhere along its travels . Using the information these status bits signal, the sending station can determine whether it needs to retransmit the frame.

Ethernet doesn't worry about such things. It provides a "best effort" delivery system and depends on the higher-level protocol whose traffic it is transporting to decide whether the frame was able to successfully navigate the network to its destination.

When a translational device is being designed, how are these bits to be handled when a Token-Ring frame is sent out onto an Ethernet network where there are no built-in mechanisms for storing this kind of information? There are differences in how these bits are handled from vendor to vendor, and you must be aware of how their devices handle this situation. For example, some simply set the Frame Copied bit when the frame is received at the device, but not the Address Recognized bit, whereas others set both bits before sending the frame back onto the ring. When the frame makes its way back to the sending station, how is it to interpret these? Because the translational device is not the final destination of the frame, the higher-level protocol must be able to cope with this.

Routing Information

Token-Ring uses source-routing bridges (SRB), whereas Ethernet uses transparent bridges. In the source-routing algorithm, an "explorer" frame is sent out through the network to discover a path to the destination computer. When more than one path exists in the network, the frame is duplicated and is able to travel more than one path. As the explorer frame travels from bridge to bridge to its destination, it compiles a list of addressing information that details the route it has taken. This information is stored in the Routing Information Field (RIF). When it reaches its destination, it can use this routing information to travel back to the sending station, which can then decide from the multiple frames that come back to it which route it wants to use to communicate with the destination station.

There is simply no concept like this in an Ethernet network. Transparent bridges don't perform this "routing" function like SRB devices do. They simply keep a table of MAC addresses as they learn which segment a device is on and try to send out frames only on the port on which the destination MAC address is known to exist.

A translational device can sometimes be made to work by caching the information in the RIF before it translates the packet from Token-Ring format to Ethernet format. When a frame with a unicast address returns, the translation bridge can check its cache and reconstruct the Token-Ring frame from the data stored there before outputting it on the Token-Ring network.

However you look at it, trying to create a gateway between these two fundamentally different kinds of networks is not an easy task. If you need to gradually phase Ethernet equipment into an existing Token-Ring network, you might have to deal with the incompatibilities and incur the expense of translational devices that might or might not solve all the problems. If you can localize your users and the servers that they use into units that can be swapped out all at once, the process becomes much easier to implement.



Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2003
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net