|
|
|
Token Ring
|
The Token Ring was originally proposed in 1969 as the Newhall Ring, after one of its developers. Other types of rings apart from token rings have been proposed for use in networks. The Slotted Ring, originally proposed by Pierce in 1972 and sometimes referred to as the Pierce loop, is so-called because a number of fixed-length slots circulate on the ring. The Register Insertion Ring, a more sophisticated version of the slotted ring, has also been proposed. Most of the development work on the slotted ring technique was done at the University of Cambridge, and the 'Cambridge ring' forms the basis for an ISO standard for slotted ring networks.
The most popular ring access technique is the IBM Token Ring, and this was the first ring-based topology selected for standardization by the IEEE 802 Local Network Standards Committee as IEEE 802.5 (since published by ISO/IEC and the BSI as the international standard 8802-5) [ISO92] . The first edition of the standard (1985) allowed two data rates, 1 and 4 Mbits/sec (Mbps), with the higher value clearly the preferred rate. In later editions of the standard (published after 1988) the 1 Mbps data rate has been withdrawn and the choice is between 4 and 16 Mbps.
The IEEE 802.5 specification is almost identical to, and completely compatible with, IBM's Token Ring network. In fact, the IEEE 802.5 specification was modelled after IBM Token Ring, and continues to shadow IBM's Token Ring development. The term Token Ring is generally used to refer to both IBM's Token Ring network and IEEE 802.5 networks.
Historically, IBM has preferred to create its own proprietary product standards, however, IBM broke with tradition by involvement in shaping the IEEE 802.5 standard, which specifies the token ring medium access-control method and physical layer. This makes the Token Ring standard potentially open for use by other equipment manufacturers. However, implementation has been heavily dominated by IBM who have had at least 90% of the market share. This situation is beginning to show signs of change as LAN specialist companies (most notably Madge Networks) introduce their own token ring products.
Further information about token rings and ring topologies can be found in [HAU86] [STR87] [TAN89] [STA90]. Local area networks and token rings are detailed in [HAL92] [DEV92] [KEI89] [NIL92] [STA94] . The reasons for using a ring topology are discussed in [ROS87] [DIX87] [WIL87]. A simulation of a token ring using concurrent programming languages is [DAV92]. The standards for token ring networks, including IEEE 802.5, are discussed in [PIT87] [HOU91] [MAD88].
Token Ring/IEEE 802.5 Comparison
Token Ring and IEEE 802.5 networks are basically quite compatible, although the specifications differ in relatively minor ways. IBM's Token Ring network specifies a star-wired ring, with all end stations attached to a device called a medium attachment unit (MAU), whereas IEEE 802.5 does not specify a topology (although virtually all IEEE 802.5 implementations also are based on a star-wired ring). Other differences exist, including media type (IEEE 802.5 does not specify a media type, while IBM Token Ring networks use twisted-pair wire) and routing information field size. The following table summarizes IBM Token Ring network and IEEE 802.5 specifications.
| IBM Token Ring Network | IEEE 802.5 | |
|---|---|---|
| Data rates | 4, 16 Mbps | 4, 16 Mbps |
| Stations per segment | 260 (shielded twisted pair/STP), 72 (unsheilded twisted pair/UTP) | 250 |
| Topology | Star-wired ring | Not specified |
| Media | Twisted pair | Not specified |
| Signalling | Baseband | Baseband |
| Access method | Token passing | Token passing |
| Encoding | Differential Manchester | Differential Manchester |
IBM Token Ring network stations are directly connected to Medium Attachment Units (MAUs), which can be wired together to form one large ring (as shown in Figure 3). Patch cables connect MAUs to adjacent MAUs. Lobe cables connect MAUs to stations. MAUs include bypass relays for removing stations from the ring.
The IBM Token Ring network's star-wired ring topology also contributes to overall network reliability. Since all information in a Token Ring network is seen by active MAUs, these devices can be programmed to check for problems and selectively remove stations from the ring if necessary.
Figure 3: IBM Token Ring Network Physical Connections
Basic Principles and Operation
A token ring LAN encompasses a set of stations, connected in a point-to-point fashion by a transmission medium, to form a closed loop or ring. All information is transferred serially - bit by bit - from one active station to the next. This is in contrast to either CSMA/CD or token bus systems that broadcast all data, although only those addressed will acknowledge. In a physical ring each station usually regenerates and repeats each bit and
serves as the means for connecting one or more devices to the ring. The station that currently has access to the medium transfers information to the ring, where it circulates from one station to the next. Stations addressed by the transmission then copy the information as it passes. Finally, when the information has traversed the ring, the sending station removes that information
from the medium.
Token Passing
When a token passes a station on the medium, that station gains the right to access and transmit its information. Following each information transmission, a token is generated. Conceptually, the token is a symbol of authority that is passed between stations using a token access method to indicate which station is currently in control of the medium. Physically, the token is a control signal consisting of a unique signalling sequence circulating on the medium. That signalling sequence can be thought of as a specialized kind of frame or packet. After transmitting the information frame, the station initiates a new token thus providing other stations with the opportunity to gain access to the ring.
So that a single station cannot hog the medium, a token holding timer controls the maximum length of time a station can use or occupy the medium before passing the token.
| Animation showing token access-control mechanism | |
| To restart/pause the animation, click on it with the mouse For Java applet information, hold down Shift and click |
Each station on the ring utilises a MAC (medium access control) unit, the operation of which will now be further described. A three byte string of control bits, the token, is used to control access to the network. When a service request to transmit data is received the data is formatted and encapsulated by the MAC unit, which then awaits the appearance of the control token. On its arrival at the station, the token is seized and made into a start-of-frame sequence. This start-of-frame, together with the rest-of-frame already prepared, is transmitted and a CRC (cyclic redundancy check) named the frame check sequence (FCS) is calculated and concatenated to the frame, before the end-of-frame sequence is sent. Like the token, the frame is repeated, or forwarded, by all stations on the ring - the MAC unit of each station examines the start-of-frame sequence to distinguish whether the frame is intended for itself alone, or as part of a group of recipients.
If the frame is an I-frame (used for ring management purposes) and its address is recognised by the station as part of the start-of-frame sequence, then it is copied and retained in the frame buffer for later processing by a higher sublayer. Receipt of the I-frame is acknowledged by the station setting the response bits at the end of the frame. The transmitting station's MAC unit ceases 'repeat mode' after sending the frame, and the frame is subsequently repeated in the same way by each station until it reaches the originating station, where it is removed from the ring.
Several classes of service are available with multiple levels of priority. The priority can be assigned independently and dynamically. As in the other LAN standards, error detection and recovery mechanisms are provided to minimize the problems associated with transmission errors or configuration changes on the medium (such as insertion or removal of stations from the ring). Because a broken ring can bring the LAN down, a method must be provided for bypassing a station that has been removed, whether it is deliberately or accidentally deleted through malfunction.
Early Token Release
On rings with large numbers of stations, the need to wait for the frame header to return to the originating station is wasteful on bandwidth. To get round this problem an option called Early Token Release (ETR) was added in later editions of the standard.
This feature is used to improve the data transmission efficiency of the token ring so that the bit rate is effectively increased to 16 Mbps, and is the significant difference between the 4 and 16 Mbps versions. As its name implies, it allows the token to be released as soon as a station has finished transmitting whether or not a full circuit of the ring has been completed. The ETR option works as follows. On a 4 Mbps ring the response bits at the tail end of the frame are read by the station - if the token hold timer has not timed out (10ms default) another frame can be transmitted. Otherwise the station releases the token (a new token is actually created), thus allowing any other station awaiting transmission access to the ring. The 16 Mbps version of the ring with ETR simply releases the token immediately after transmitting the last bit of a frame.
As the 802.5 standard [ISO92] notes, one problem with early token release is that the priority scheme no longer works for short frames. This is because the transmitting station does not get a view of the reservation bits prior to releasing the token. In such cases, the priority of the most recently received frame is used. This can have the effect of delaying access to high priority frames when there are a number of short frames transmitted. Also, the standard states that "stations implementing ETR option are compatible and interoperable with stations that do not". If a 16 Mbps card is used on a 4 Mbps network, it reverts to 4 Mbps operation. However, from the authors personal experience, the reverse situation where a 4 Mbps card is used on a 16 Mbps network will cause the slower station to generate a 'hard error' network failure ('beaconing').
Prioritisation
Token Ring networks use a sophisticated priority system that permits certain user-designated, high-priority stations to use the network more frequently. Token Ring frames have two fields that control priority: the priority field and the reservation field. Only stations with a priority equal to or higher than the priority value contained in a token can seize that token. Once the token is seized and changed to an information frame, only stations with a priority value higher than that of the transmitting station can reserve the token for the next pass around the network. When the next token is generated, it includes the higher priority of the reserving station. Stations that raise a token's priority level reinstate the previous priority after their transmission is complete.
| Animation showing Prioritisation on a Token Ring network | |
| To restart/pause the animation, click on it with the mouse For Java applet information, hold down Shift and click |
Before normal operation can begin, the token ring must be set up. In addition, if a station wants to join a ring that is already operating then it must be initialized first, to ensure that it does not interfere with the established ring. Also, during normal operation each station on the ring actively monitors its correct operation and invokes corrective action if needed. These are regarded as essential ring management functions.
There are four components that comprise the ring management capability in a token ring. These are the Ring Parameter Server (RPS), Configuration Report Server (CRS), Ring Error Monitor (REM) and Station Management (SMT). The first three of these functions generally occur once only in a LAN, but not necessarily as part of a LAN management station, whilst Station Management is present in every station. Communication between ring management functions is via special MAC event frames.
One station is selected to be the active monitor. This station, which can potentially be any station on the network, acts as a centralized source of timing information for other ring stations and performs a variety of ring management functions. One of these functions is the removal of continuously circulating frames from the ring. When a sending device fails, its frame may continue to circle the ring. This can prevent other stations from transmitting their own frames and deadlocks the network. The active monitor detects such frames, removes them from the ring, and generates a new token.
An algorithm called beaconing detects and tries to repair certain network faults. Whenever a station detects a serious problem with the network (such as a cable break), it sends a beacon frame. The beacon frame defines a failure domain, which includes the station reporting the failure, its nearest active upstream neighbour (NAUN) and everything in between. The nodes within the failure domain then perform diagnostics in an attempt to reconfigure the network around the failed areas (autoreconfiguration).
| Animation showing Beaconing on a Token Ring network | |
| To restart/pause the animation, click on it with the mouse For Java applet information, hold down Shift and click |
The IEEE 802.5 standard defines two frame types: tokens and information frames (I-frames). Both frame formats are summarised in Figure 4.
Figure 4: IEEE 802.5/Token Ring Frame Formats
Tokens are 3 octets (bytes) in length and consist of a starting delimiter, an access control byte, and an ending delimiter, as shown in the following table. The values in parentheses are the field lengths (in bytes/octets.)
| Starting Delimiter (1) | Access Control (1) | Ending Delimiter (1) |
| (Click on any of the field name links for full field descriptions.) |
The start delimiter serves to alert each station to the arrival of a token (or data/command frame). This field includes signals that distinguish the byte from the rest of the frame by violating the encoding scheme used elsewhere in the frame.
The access control byte contains the priority and reservation fields, as well as a token bit (used to differentiate a token from a data/command frame) and a monitor bit (used by the active monitor to determine whether a frame is circling the ring endlessly).
Finally, the end delimiter signals the end of the token or data/command frame. It also contains bits to indicate a damaged frame and a frame that is the last in a logical sequence.
I-frames (also called 'data/command frames', or simply 'frames') vary in size, depending on the size of the data (information) field. These frames have a dual purpose; 'data' I-frames carry information for upper-layer protocols whilst 'command' (or 'control') I-frames contain control information and have no data for upper-layer protocols. The frame format in shown in the following table. The values in parentheses are the field lengths (in bytes/octets.)
| Starting Delimiter (1) | Access Control (1) | Frame Control (1) | Destination Address (2/6) | Source Address (2/6) | Routing Information (0-30) | Data (0 or more) | Frame Check Sequence(4)
| Ending Delimiter (1) | Frame Status (1) |
| (Click on any of the field name links for full field descriptions.) |
In I-frames, a frame control byte follows the access control byte. The frame control byte indicates whether the frame contains data or control information. In control frames, this byte specifies the type of control information.
Following the frame control byte are the two address fields, which identify the destination and source stations. Addresses can be 2 bytes in length, or 6 bytes in length as in IEEE 802.3. However, all stations in a particular LAN should have the same address length.
The data field follows the address fields. The length of this field is limited by the ring token holding time, which defines the maximum time a station may hold the token.
Following the data field is the frame check sequence (FCS) field. This field is filled by the source station with a calculated value (a cyclic redundancy check/CRC) dependent on the frame contents. The destination station recalculates the value to determine whether the frame may have been damaged in transit. If so, the frame is discarded.
As with the token, the end delimiter completes the I-frame.
Abort Sequence
The abort sequence is used for the purpose of terminating the transmission of a frame prematurely. The abort sequence may occur anywhere in the bit stream (a receiving station shall be able to detect an abort sequence even if it does not occur on an octet boundary.) The abort sequence fields are shown below.
| Starting Delimiter (1) | Ending Delimiter (1) |
The case for and against the Token Ring access method, and ring network topologies in general, will now be presented. This section attempts to briefly explain why a ring network may, or may not, be selected as the access method of choice for a real LAN.
Advantages
The main advantages of Token Ring networks can be summarised as follows:
However, Token Ring networks also suffer from a number of drawbacks, including:
In weighing up the pros and cons of Token Ring and other similar networks, it may be useful to gaze into the crystal ball and predict what may be required of a future LAN system. The speed of workstations will continue to increase and the type of information transmitted will change. Multimedia applications, requiring transmission of integrated voice, images and data will require very high speed LANs to achieve acceptable response times. Halsall [HAL92] states "In cases where the load is significant . . . the token access method is superior." Also "CSMA/CD is inappropriate for higher bit rate LANs." Therefore it is likely that for multimedia applications at least, a move away from CSMA/CD towards access methods based on a control token with priority (such as Token Ring, FDDI/CDDI or 100VG-AnyLAN Demand Priority) will be required to maintain acceptable response times for all users on the network.
| LANs Home | Introduction | FDDI / CDDI | Ethernet | Future LANs | References |
Adrian Catchpole - A.G.Catchpole@comp.brad.ac.uk