|
|
|
Token-Ring is the second most widely used local area network (LAN) technology after Ethernet. Stations on a Token-Ring LAN are organized in a ring topology with data being transmitted sequentially from one ring station to the next. The ring is initialized by circulating a token. A station must capture the token to gain the right to transmit information onto the ring. A transmitting station replaces the token with a frame which carries the information to be transferred. The frame circulates the ring and may be copied by one or more destination stations. When the frame returns to the transmitting station, it is removed from the ring and a new token is transmitted.
Token-Ring was initially defined by IBM at its research facility in Zurich Switzerland in the early 1980s. IBM pursued standardization of Token-Ring under the 802.5 Working Group of the Institute of Electrical and Electronic Engineers (IEEE).
IBM introduced its first Token-Ring product, an adapter for the original IBM Personal Computer, in October 1985. The initial Token-Ring products operated at 4 Mbit/sec. IBM collaborated with Texas Instruments to develop a chipset that would allow non-IBM companies to develop their own Token-Ring compatible devices.
In 1989, IBM improved the speed of Token-Ring by a factor of four when it introduced the first 16 Mbit/sec Token-Ring products. The 802.5 standard was extended to support 16 Mbit/sec operation.
In 1994, the leading Token-Ring suppliers formed the Alliance for Strategic Token-Ring Advancement and Leadership (ASTRAL). ASTRAL's mission was to promote Token-Ring technology in the face of increasing popularity of Ethernet technology. The initial members of ASTRAL were 3Com, ACE/North Hills, Bay Networks (SynOptics and Wellfleet), Bytex, Cabletron, Centillion, Chipcom, Hewlett-Packard, IBM, Intel, Madge, Olicom, Proteon, Racore, SMC, Texas Instruments, Xircom, XPoint and UB Networks.
In 1997, the draft 802.5r standard became available which defined Dedicated Token-Ring (DTR) operation. Dedicated, or full duplex, Token-Ring bypasses the normal token passing protocol to allow two stations to communicate over a point to point link. It effectively doubles the transfer rate by allowing each station to concurrently transmit and receive separate data streams. For example, a 16 Mbit/sec dedicated Token-Ring station can transmit one 16 Mbit/sec stream at the same time it receives a separate 16 Mbit/sec stream. This provides an overall data transfer rate of 32 Mbit/sec. The DTR protocol extends to other Token-Ring data rates as well.
In 1997, the High Speed Token-Ring Alliance (HSTRA) was formed to pursue "an IEEE 802.5 standard for dedicated high-speed Token Ring that scales from 100 Mbit/sec to at least 1 gigabit". The primary HSTRA members were 3Com, Bay Networks, IBM, Madge Networks, Olicom, the UNH Interoperability Lab, and Xylan.
In 1998, the draft 802.5t standard became available which defines 100 Mbit/sec operation for Token-Ring. The 100 Mbit/sec standard is restricted to "dedicated" operation. No "shared media" 100 Mbit/sec standard is planned. The first 100 Mbit/sec Token-Ring products were introduced by Olicom and IBM in 1998.
The current IEEE 802.5 standards may be ordered from the following web address: http://standards.ieee.org/catalog/IEEE802.5.html. The following standards are available as of March 1999:
The IEEE 802.5 Committee has initiated two working groups to develop higher speed Token-Ring standards. The 802.5t Working Group is responsible for 100 Mbit/sec Dedicated Token-Ring. The 802.5t standard is available in draft form to committee members, but has not yet been published as an official standard that can be ordered from IEEE (as of March 1999). The 802.5v Working Group has been chartered to develop a Gigabit Token-Ring standard.
Refer to the IEEE 802.5 Web Site at http://www.8025.org for the latest information on Token-Ring standards.
The following Token-Ring related documents may be ordered from IBM at http://www.ibmlink.ibm.com. Search IBM's PubCatalog for the document numbers listed below:
The following book is an excellent source of information on the Token-Ring standard: Understanding Token Ring Protocols and Standards by James Carlo, Robert Love, Michael Siegel, and Kenneth Wilson. October 1998. 450p. ISBN 089006458X.
The basic transmission unit on Token-Ring is a frame. The frame format is used for transmitting both LLC and MAC frames. It may or may not include an information field. It may or may not include a routing information field. Frames are composed of the following fields:
| Starting Delimiter (1-byte) | Access Control (1-byte) | Frame Control (1-byte) | Dest. MAC Address (6-bytes) | Source MAC Address (6-bytes) | Routing Information (0-30 bytes) |
Information (0-n bytes) |
Frame Check Sequence (4-bytes) | Ending Delimiter (1-byte) | Frame Status (1-byte) |
The token is the means by which the right to transmit a frame is passed from station to station. Stations wishing to transmit capture the token and convert it into a frame. As the frame circles the ring and returns to its origin, the originating station removes it from the ring and transmits a new token for another station to capture and carry on the process.
| Starting Delimiter (1-byte) | Access Control (1-byte) | Ending Delimiter (1-byte) |
A Token-Ring station may abort a frame it is transmitting at any time by transmitting an abort sequence. It cause the stations receiving the frame to recognize that it is not a valid frame.
| Starting Delimiter (1-byte) | Ending Delimiter (1-byte) |
A frame, token, or abort sequence always starts with a starting delimiter. It is one byte in length and consists of a unique sequence of symbols that includes "code violations" in the Manchester encoded data known as "J" and "K" symbols.
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| J | K | 0 | J | K | 0 | 0 | 0 |
J = Non Data "J" Symbol
K = Non Data "K" Symbol
0 = Data "0" Symbol
The Access Control field is found in frames and tokens and is one byte in length. It includes several parameters as described below.
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| P | P | P | T | M | R | R | R |
PPP = Priority Bits - In tokens, these bits indicate the priority
of the token, and therefore which stations are allowed to use the token.
In frames, these bits indicate the access priority level that was used to capture
the token. Eight priority levels are defined with b'000' being the lowest
and b'111' being the highest.
T = Token Bit - Set to b'0' in tokens and b'1' in frames.
M = Monitor Bit - Used to prevent a token with priority greater
than b'000' or any frame from continuously circulating the ring.
Frames and tokens are initially transmitted with this bit set to b'0'.
As a token with priority greater than b'000' or any frame is repeated by
the active monitor, this bit is set to b'1'. All other stations repeat
this bit unmodified. If the active monitor detects a frame with this
bit set, it purges the ring and releases a new token.
RRR = Reservation Bits - Stations with high priority access will
modify these bits when they repeat frames or tokens to request that a token
be issued at the specified priority level. b'000' is the lowest priority
level and b'111' is the highest.
The Frame Control field is one byte in length and indicates the type of frame.
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| F | F | Z | Z | Z | Z | Z | Z |
FF = Frame Type Bits - Used to indicate the type of frame. b'00'
indicates a "MAC Frame". b'01' indicates an "LLC Frame". The other values
are reserved for future use.
ZZZZZZ = Control Bits - Used for MAC Frames to indicate whether the
frame should be "normal" or "express" buffered. If these bits are all
zeros, the frame should be normal buffered. If non-zero, the frame should
be express buffered.
The Destination Address field is six bytes in length and identifies the station or stations that are to copy the frame. The two most significant bits have special meaning as described below.
| Bit0 | Bit1 | Bit2 - Bit47 |
| I/G | U/L |
I/G = Individual/Group - This bit indicates whether the address is
ad individual address (b'0') or group address (b'1).
U/L = Universal/Local - This bit indicates whether the address is
a universally administered (b'0') or locally administered (b'1').
The Source Address field is six bytes in length and identifies the station that originated the frame. The two most significant bits have special meaning as described below.
| Bit0 | Bit1 | Bit2 - Bit47 |
| RII | U/L |
RII = Routing Information Indicator - Since the source address field
will always carry and individual address, there is no need for this bit to
indicate individual vs. group as in the Destination Address field. Instead,
it is used to indicate whether the Routing Information (RI) field is present in
the frame. If b'0', no RI field is present. If b'1', an RI field is
included in the frame.
U/L = Universal/Local - This bit serves the same function as in the
Destination Address field. It indicates whether the address is
a universally administered (b'0') or locally administered (b'1').
The Routing Information (RI) field is used as part of the Token-Ring source routing protocol for routing frames between rings in multiple-ring networks. If a frame is not going to leave the source ring, then the RI field is omitted. If a frame is destined for a station on another ring, then the RI field is used by bridge devices to route the frame across one or more additional rings until it reaches its final destination. The RI field is present only if the routing information indicator (RII) bit in the Source Address field is set to b'1'.
The Token-Ring standard permits the length of the RI field to be any even value from 0 to 30 bytes. However existing implementations typically support an RI field of only up to 18 bytes in length. When present, the RI field consists of one 2-byte Routing Control field, followed by 0, 1, or more 2-byte Route Designator fields as illustrated below:
| Routing Control (2-bytes) | Route Designator (2-bytes) | Route Designator (2-bytes) | ... | Route Designator (2-bytes) |
The Routing Control field has the following bit definitions:
| Byte0 | |||||||
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| B | B | B | L | L | L | L | L |
| Byte1 | |||||||
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| D | F | F | F | r | r | r | r |
BBB = Broadcast Indicators - These 3 bits indicate if and how
bridges are to broadcast a frame across multiple ring segments.
A value of b'0XX' is a "Non-Broadcast" frame with route designator
fields that contain a specific route for the frame to travel through
the network. b'10X' is an "All-routes-broadcast" frame that will be
transmitted along every route in the network. This may result in
multiple copies of the frame arriving at the destination station.
b'11X' is a "Single-route-broadcast" that indicates only certain
designated bridges should forward the frame from one segment to another.
This results in exactly one copy of the frame appearing on every segment
in the network.
LLLLL = Length Bits - These 5 bits indicate the length in bytes
of the RI field. They permit ring stations to parse the rest of the
frame correctly. For all-routes and single route broadcast frames
the value in the length field is modified by bridges as they insert
route descriptor fields into the frame.
Non-broadcast frames destined for another ring segment
are transmitted with a complete RI field and this field remains the same
as the frame traverses the network.
D = Direction Bits - This bit is used by bridges to interpret
the order of the route descriptor fields. If this bit is b'0', a
bridge will interpret the routing field from left to right. If it
is a b'1', the routing field is interpreted from right to left.
This bit allows the routing descriptor entries to appear in the same
order for frames traveling in either direction along the route.
FFF = Largest Frame Bits - This field specifies the largest
information field that can be transmitted between two stations
communicating over a specific route. Broadcast frames are transmitted
with this field at the maximum value (b'111'). Bridges will reduce
the value of these bits as necessary to indicate the largest frame size
supported over that route. The largest value returned in responses
to the broadcast indicates the largest possible frame the route can
handle. The defined values for this field are: b'000' = 516 bytes,
b'001' = 1500 bytes (Ethernet max), b'010' = 2052 bytes, b'011' = 4472
bytes (FDDI max), b'100' = 8144 bytes, b'101' = 11407 bytes, b'110' =
17800 bytes (Token-Ring max), b'111' = used in all-routes broadcast frames.
rrrr = Reserved Bits. These bits shall be transmitted as zeros.
The Route Designator field includes a 12-bit "ring number" field and a 4-bit "bridge number" field as shown below. When an all-routes or single routes broadcast frame is transmitted, each bridge that forwards the frame to another ring adds its bridge number and that ring's number to the frame's routing information field. Therefore, when the frame reaches is destination it contains a record of the route taken. The route designators created during the broadcast process are then included when transmitting subsequent non-broadcast frames to specify the route the frame should take.
| Byte0 | Byte1 | |||||||||||||||
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 | Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 | |
| RN (12bits) | BN (4bits) | |||||||||||||||
RN = Ring Number - Each ring in a multiple ring networking is
assigned a unique 12-bit ring number.
BN = Bridge Number - Each bridge between two rings is assigned a
unique 4-bit bridge number. Since the end of a route is a ring and not
a bridge, the bridge number in the last route designator is reserved
and transmitted as all zeros.
This field contains the data transferred from the source station to the destination station or stations. The size of this field may be anywhere from 0 to 4472 for 4 Mbit/sec Token-Ring, and 0 to 17,800 bytes for 16 Mbit/sec Token-Ring. This field may contain "MAC" frame data or "LLC" frame data as indicated by the frame type bits in the Frame Control field.
| Information Field (0 to n bytes) |
This field contains a 4-byte cyclical redundancy check (CRC) value used for error checking. When a source station assembles a frame, it performs a CRC calculation on all the bits in the frame from the Frame Control field through the Information Field. The source station stores the value in this field and transmits it as part of the frame. When the frame is received by the destination station, it performs an identical check. If the calculated value does not match the value in this field, the destination station assumes an error has occurred during transmission and discards the frame.
| Byte0 | Byte1 | Byte2 | Byte3 |
| FCS | |||
FCS = Frame Check Sequence
The Ending Delimiter is one byte in length and consists of a unique sequence of symbols that includes "code violations" in the Manchester encoded data known as "J" and "K" symbols. Receiving stations shall consider the ED valid if the first six symbols (J K 1 J K 1) are received correctly.
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| J | K | 1 | J | K | 1 | I | E |
J = Non Data "J" Symbol
K = Non Data "K" Symbol
1 = Data "1" Symbol
I = Intermediate Frame Bit - This bit is transmitted as a b'1' in
intermediate (or first) frames of a multiple frame transmission using
a single token. The "I" bit in the last (or only) frame of the transmission
shall be set to b'0'. The ability to transmit multiple frames per token is not
widely implemented in existing products.
E = Error Detected Bit - This bit shall be transmitted as b'0' by
a station when it originates a token, frame, or abort sequence. Stations
that repeat a token or frame set this bit to b'1' when detecting an error such
as a "code violation", non-integral number of bytes, or CRC error.
In a frame, the "E" bit protects all bytes from the Access Control field
through the Frame Check Sequence.
The Frame Status field has the following format:
| Bit0 | Bit1 | Bit2 | Bit3 | Bit4 | Bit5 | Bit6 | Bit7 |
| A | C | r | r | A | C | r | r |
A & C = Address Recognized (A) and Frame Copied (C) Bits - These bits
are transmitted as zero by the originating station. If a ring station
recognizes the frame's Destination Address and copies the frame, it sets
the A & C bits to b'11'. If a ring station recognizes the frame's Destination
Address but is unable to copy the frame, it sets the A bit to b'1' but
leaves the C bit at b'0'
When the frame returns to the originating station the A & C bits provide
and indication of whether the frame was recognized and/or copied.
Two copies of the A & C bits are included in this byte because the Frame
Status field is not covered by the Frame Check Sequence. The bits should
be considered valid only when both copies of the A & C bits match.
Use of these
bits should be restricted as some bridge and switch implementations do
not consistently set these bits when a frame is forwarded to another
ring.
r = Reserved Bits - These bits shall be transmitted as zeros.
An idle period, known as the "interframe gap" (IFG), is placed between frames to provide a brief recovery time for stations on the ring. For 4 Mbit/sec transmission the interframe gap must be a minimum of 1 byte (2 bytes are recommended). For 16 Mbit/sec transmission it must be a minimum of 5 bytes. The data transmitted during the interframe gap may consist of any sequence of "0" and "1" bits. The size and content of the interframe gap may be adjusted slightly as it flows through the station on the ring that is operating as the "active monitor".
This section describes the various types of addresses that may be specified in the Destination Address (DA) field.
When the first bit of the DA field is b'0', the address is an individual address. It identifies a particular station in the network, and must be distinct from all other individual addresses on the same LAN.
x'FF FF FF FF FF FF' and x'C0 00 FF FF FF FF' are "all-stations broadcast addresses". They are addressed to all stations on a given ring or set of interconnected rings. The x'C0 00 FF FF FF FF' address is intended for use in MAC frames only. Broadcast Addresses are a specific type of Group Address.
The Individual Address x'00 00 00 00 00 00' is known as a "Null Address". No station shall be assigned the Null Address and frames addressed to the Null Address are not expected to be copied.
Functional Addresses are a type of locally administered Group Addresses that are assigned for use by well known functions or protocols. The most significant 17 bits of Functional Addresses are fixed as illustrated below. The least significant 31 bits provide 31 bit significant addresses. Each station maintains a Functional Address "mask" that is used to determine which Functional Addresses will be copied. For example, a station with a Functional Address mask set to x'C0 00 00 00 00 12' will copy frames with Functional Addresses of x'C0 00 00 00 00 10' and x'C0 00 00 00 00 02'. Or, a frame may be addressed to multiple functions by setting more than one bit in the 31 bit field.
| Byte0 | Byte1 | Byte2 | Byte3 | Byte4 | Byte5 |
| Bit 01234567 | Bit 01234567 | Bit 01234567 | Bit 01234567 | Bit 01234567 | Bit 01234567 |
| 11000000 | 00000000 | 0xxxxxxx | xxxxxxxx | xxxxxxxx | xxxxxxxx |
The following is a list of some of the Functional Addresses assigned by IBM:
| Active Monitor | x'C00000000001' |
| Ring Parameter Server | x'C00000000002' |
| Ring Error Monitor | x'C00000000008' |
| Configuration Report Server | x'C00000000010' |
| NETBIOS | x'C00000000080' |
| Bridge | x'C00000000100' |
| LAN Manager | x'C00000002000' |
All the fields described above are transmitted serially onto the Token-Ring media with the left most, or most significant, bit being transmitted first. Note this is different from Ethernet which transmits the right most, or least significant, bit of each byte first when transmitting the destination and source address fields. The Ethernet method of transmitting addresses is called "canonical" or "lsb" format. The Token-Ring method is called "non-canonical" or "msb" format. Both methods transmit the most significant byte of an address first. They differ only in whether the most or least significant bit of each byte is transmitted first.
The IEEE 802.1 standard specifies that addresses should be represented in canonical format. The following figure illustrates how a canonical destination or source address of hex "12 34 56 78 9A BC" is converted into non-canonical form:
| canonical | Hex: | 12 | 34 | 56 | 78 | 9A | BC |
| Binary: | 0001 0010 | 0011 0100 | 0101 0110 | 0111 1000 | 1001 1010 | 1011 1100 | |
| non-canonical | Binary: | 0100 1000 | 0010 1100 | 0110 1010 | 0001 1110 | 0101 1001 | 0011 1101 |
| Hex: | 48 | 2C | 6A | 1E | 59 | 3D |
Classic Token Ring refers to Token Ring as it was originally defined in the early 1980s. It uses "shared bandwidth" to connect multiple stations with a single Token Ring. It may also be referred to as "shared Token Ring" or "half-duplex Token Ring". It exists in contrast with "dedicated Token Ring" which was defined in the late 1990s.
In a Token-Ring Network a ring consists of the ring stations and the transmission medium, or cabling, used to interconnect them. Token-Ring uses a star-wired ring topology. Stations include a Token Ring circuit board, or adapter, that connects to a concentrator via a lobe cable. Concentrators may be serially interconnected through patch or trunk cables using the concentrator ring in and ring out ports. Token-Ring concentrators are often called Multistation Access Units, or MSAUs.
Each station receives data through a connection from its nearest upstream neighbor, and transmits data through a connection to its nearest downstream neighbor. Data transmitted by a station travels sequentially, bit by bit, through each station. Each station repeats the data, while checking it for errors. The addressed destination station(s) copy the information as it passes. When the data returns to the originating station, it is stripped, or removed from the ring.
A station gains the right to transmit data, or frames, onto the medium when it detects a token passing on the medium. The token consists of a unique signaling sequence that circulates on the medium following each frame transfer. Any station, upon detecting a valid token, may capture the token by modifying it to start of frame sequence and appending appropriate control and status fields, address fields, routing information field, information field, check sum, and the ending frame sequence. After completion of the frame transfer, the station transmits a new token, allowing other stations the opportunity to gain access to the ring.
Token Ring concentrators include an "insertion/bypass" mechanism that allows stations to enter or leave the network. When in bypass mode, the lobe cable is wrapped back to the attaching station, allowing the station to perform a self-test of its Token Ring circuitry and lobe cable by operating as a one-node network. When the concentrator receives a DC signal, called phantom drive, from the station via the lobe cable, it switches from bypass mode to inserted mode, allowing the inserted station to receive an input data stream from its upstream neighbor, and transmit an output data stream to its downstream neighbor.
Classic Token Ring supports data transmission rates of 4 Mbit/sec and 16 Mbit/sec (100 Mbit/sec "High Speed Token Ring" is supported only by the "Dedicated Token Ring" (DTR) protocol). Current Token-Ring adapters are typically capable of operating at either rate and include ring speed listen circuitry that allows them detect and adapt to the current ring speed when inserting into the network. It is possible for a single ring to consist of as many as 260 stations. However, the total station count may be limited to a smaller number depending on factors such as media type, data rate, use of repeaters and converters, concentrator type, etc. Multiple rings may be interconnected through the use of bridges.
The Claim Token process is started when a station enters the Transmit Claim Token state and begins transmitting Claim Token MAC frames. Stations not in the Claim Token state enter the Repeat Claim Token state when they receive a Claim Token MAC frame. If a station in the Transmit Claim Token state receives a Claim Token MAC frame with a source address that has a higher numerical value than its own station address, then it reverts to Repeat Claim Token state. This ensures that if multiple stations enter the Transmit Claim Token state, then stations will be eliminated until a single "winner" remains. That last station remaining in the Transmit Claim Token state wins the Claim Token process when it receives its own Claim Token MAC frame.
The station winning the Claim Token process becomes the active monitor and purges the ring by transmitting Ring Purge MAC frames. The other stations, upon receiving the Ring Purge MAC frame, transition from Repeat Claim Token state to the normal repeat state. If a station identifies that the Claim Token process has failed to complete within the time specified by the "claim token" timer, it starts the Beacon process by entering the Transmit Beacon state and transmitting Beacon MAC frames.
The Beacon MAC frame identifies the reason for the beaconing (Beacon Type) and the address of its last known upstream neighbor. When the beaconing station's nearest upstream neighbor has received eight of these Beacon MAC frames, it removes itself from the ring and tests itself to verify it is not the source of the fault.
If a station in the Transmit Beacon state receives its own beacon frame, then the Beacon process is resolved and the station enters the Claim Token process. If a station in the Transmit Beacon state receives a beacon frame from another station with an equal or lower Beacon Type, then the station enters the Repeat Beacon state. If a station remains in the Transmit Beacon state until its "beacon transmit" timer expires, it removes itself from the ring and performs a self test to verify it is not the source of the fault.
If the ring does not recover after both the nearest upstream neighbor and the beaconing station have tested themselves, the error cannot be automatically repaired and manual intervention is required. A "Ring Error Monitor" tool may be used to identify the address of the beaconing station to isolate the location of the wire fault.
The neighbor notification process depends on the capability provided by the "A" and "C" bits of the Frame Status field. The "A" and "C" bits are always transmitted as zeros. If a station recognizes the frame's destination address as a frame it should copy, it sets the "A" bit to one. If the station copies the frame, it sets the "C" bit to one.
When a frame is broadcast to all stations, the first station downstream from the broadcaster will be the only station that receives the frame with the "A" and "C" bits as zeros. All other stations will see the bits as ones since the first station sets them.
This feature is used by the neighbor notification process. The neighbor notification process begins when the active monitor sends an Active Monitor Present MAC frames to the broadcast address. If a station receives the frame with the "A" and "C" bits as zeros, then the frame's source address identifies this station's nearest upstream neighbor. If the station is not the active monitor, then it broadcasts a Standby Monitor Present MAC frame to notify its downstream neighbor of its address. The process continues in a circular, daisy-chained fashion to let every station know the identity of its upstream neighbor.
Stations which implement ETR are compatible and interoperable with stations that do not. ETR was not defined at the time the 4 Mbit/sec Token Ring standard was released, so it is supported only for 16 Mbit/sec operation.
The priority of a token or frame is indicated in the first 3 bits (the priority bits) of the Access Control field. Any reservation for a different priority is indicated in the last 3 bits (the reservation bits) of the same field. A station uses the reservation bits to request that a token be originated on the ring at the requested priority level.
If another station has already reserved an equal or higher priority, the station cannot make a reservation in the frame or token. If the reservation bits have not been set, or if they have been set to a lower priority than that required by the station, then a station may set the reservation bits to the required priority. When a station removes one of its frames from the ring and finds a non-zero value in the reservation bits, it must originate a non-zero priority token.
To prevent a station from continually transmitting priority frames, fairness is provided within each priority level. A station that originates a token of increased priority must eventually replace it with a token of the original priority.
Hard errors are permanent faults, usually in equipment or cabling, that cause the ring to stop operating within the normal protocols. The token ring protocol uses the Beacon process in an attempt to recover from hard errors and restore normal token operation. If recovery is not possible, the beacon MAC frame identifies the fault domain for analysis by network management functions.
When source routing bridges are used, the source station is expected to know the route over which to send each frame it transmits. If a source station does not know the route, or if the source station determines that a previously known route is no longer active, the station broadcasts a route discovery frame. A route discovery frame, also known as a TEST or XID frame, contains the MAC address of the destination station the source station is attempting to reach. The route discovery frame is propagated by the bridges throughout the entire network. As a route discovery frame travels across the interconnected rings, each bridge that receives the frame adds routing information to the routing information field of the frame. When the route discovery frame reaches its final destination, the destination station sends a response back to the source station. The response contains the routing information field that describes the route the original route discovery frame used to reach the destination station. The original source station then uses the routing information field that is contained in the response to create the routing information field in data frames it sends to the destination station.
An advantage of using source routing over transparent bridging is that multiple bridges may be installed to create parallel, active paths between individual rings. Multiple active paths allow for higher throughput and load balancing through the various bridges. A disadvantage of the source routing technique is that source routing bridges cannot be used to interconnect Token Ring with other LANs like Ethernet.
The release of the IEEE 802.5r standard in 1998 defined a second mode of operation for Token Ring, called Dedicated Token Ring (DTR) that bypasses the classic token passing protocol. The classic Token Ring protocol is "half-duplex". This implies that a station may either transmit data, or receive data, but never both at the same time. DTR is a "full duplex" protocol that allows two stations to simultaneously exchange data over a point to point link that provides independent transmit and receive paths. Since each station can simultaneously transmit and receive data, the aggregate throughput of the link is effectively doubled. For example, A 16 Mbit/sec station operating in DTR mode provides a maximum bandwidth of 32 Mbit/sec.
DTR operation is restricted to point to point links connecting exactly two stations. Since there is no contention for a shared medium, the token becomes unnecessary. Frames may be transmitted at will, limited only by the required separation of the minimum interframe gap. To support DTR both stations on the link must be capable of, and be configured for full-duplex operation. Token-Ring products capable of supporting DTR first became available about 1997.
Concentrators that are capable of DTR operation are typically called switches. DTR connections may exist between two switches, or between a switch and a workstation adapter. A Token Ring switch may use transparent bridging or source route bridging techniques to route frames between its various ports.
Token Ring uses a star-wired ring topology that allows an electrically contiguous ring to be implemented with wiring that extends in lobes from the wiring hub to the workstation adapters. The wiring hub is called a concentrator, or Multistation Access Unit (MSAU or MAU).
Token Ring uses two pairs of wires to connect each workstation to the concentrator. One pair of wires is used for transmitting data, and the other for receiving data. STP cabling contains two wire pairs for Token Ring (data) and may include additional pairs for carrying telephone (voice) transmission. UTP cabling typically includes four wire pairs of which only two are used for Token Ring.
STP Token Ring installations typically connect to the workstation adapter through a 9-pin D-Shell connector, and connect to the concentrator or wall outlet (faceplate) through an IBM Data Connector. UTP Token Ring installations typically uses an 8-pin RJ-45 connector on both the workstation adapter and concentrator/wall outlet ends. Newer Token Ring adapters include both a 9-pin D-Shell and RJ-45 connector to permit attachment to either STP or UTP cabling.
Older Token Ring adapters may have only a 9-pin D-Shell connector for attachment to STP cabling. Attaching older adapters to UTP requires a "media filter" device to translate from the 150-ohm impedance of the 9-pin D-shell connector to the 100-ohm impedance of the UTP cabling. The media filter contains an impedance-transformer (balun) that compensates for the impedance difference. Operating without a media filter in applications where it is required can cause serious problems that will limit lobe distances and cause unwanted signal reflections.
| ||