This service is free, however donations are welcome
Data Network Resource
       Earn on the Web

Home of a wide range of data and communications products!

Token Ring



Contents



1. Introduction



The IBM Token Ring protocol architecture was the basis for the IEEE 802.5 token ring protocol. It is a star-wired ring topology, having token passing as its network access method using a baseband transmission technique operating at 4 or 16 Mb/s. It is known as a Deterministic method of access since a station can only transmit data when a token is available to it, once the station releases the token the next station grabs it, no collisions can occur, and each station has a chance to grab the token whether they have data to transmit or not.

The encoding used to transmit the data bits is Differential Manchester Encoding.

The signal frequency is anything up to 4MHz for 4Mbps Token Ring, or 16MHz for 16Mbps depending on the transmission bit patterns.

UTP or STP cables (containing at least 2 pairs of wires), or two fibres, connect each station to a central MAU (or CAU), one receive (ring-in) and one transmit (ring-out). The data received by a station is retransmitted onto the next station, the data flow from Ring Out (RO) to Ring In (RI) is uni-directional.

Most MAU's provide RI and RO ports for connection of other MAU's. These ports have self-shorting relays which loop back to maintain the internal ring if the ports are not connected to anything. The cables used to connect RI ports to RO ports are called trunk cables and can be UTP, STP or fibre. The MAU's support Primary and Secondary trunk channels in case of physical network failures.

MAU cabling

When planning cable networks, it is important to make sure that the secondary channel length is within the tolerance distance, as well as the primary channel length.

When inserting onto the ring, the station uses a DC phantom current to signal the relay (which resides within the MAU port) to open or close. Absence of the phantom current causes the relay to close and so tokens and frames can bypass the lobe across the short.

2. Frame Formats



Token Ring header

Once a station has physically attached itself to the MAU it sends out a 24-bit (3-byte) frame called a token, this has the following format:
  • SD: Starting Delimiter is a 1-byte field marking the beginning of the token.
  • AC: Access Control is a 1-byte field and identifies the transmission as a data frame or a token.
  • ED: Ending Delimiter is a 1-byte field marking the end of the token.
The Data is transmitted using Data Frames. In addition to the SD, AC and ED fields the data frame has the following fields:
  • FC: Frame Control indicates whether the frame is a data frame or a MAC control frame (25 MAC control frames are used in Token Ring).
  • DA & SA: The Destination Address and the Source Address are 2 bytes (never used) long or 6 bytes long, as long as it is consistent throughout the network. While the Source Address is an individual address; the Destination Address can be an individual, group or broadcast address.
  • RIF: Routing Information Field can be anywhere between 2 and 18 bytes long. This is only used in a Source Route Bridging environment where the frame is destined for a station in a ring other than the source ring.
  • INFO: The Info field can contain either a protocol unit passed from LLC (with the DSAP, SSAP and Control fields) or a MAC control frame.
  • FCS: Frame Check Sequence is a 32-bit cyclic redundancy check.
  • FS: The Frame Status field contains J and K bits which indicate if an address has been recognised and whether or not it was successfully received by the destination station. When a station receives a frame it sets the J bit. If it copies the frame, then the station sets the K bit.
  • Ending Delimiter: This contains an E bit that is set once an error is detected. In addition there is a bit that can be set to indicate that the frame is the last in a sequence.

3. Addressing



The address format is as follows:

Octet 1 2 3 4 5 6
Bits 11000000 00000000 0XXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

The first two bits are the I/G and U/L bits and are set to 1 in this instance and therefore indicate that the address is a multicast/broadcast (Group) address and it is Locally administered. The first bit in the third octet is the Functional Address Indicator Bit and when it is set to 0, it indicates that the remaining bits form the functional address (used by the various Token Ring functions as detailed below).

There are a number of types of addresses:

3.1 Individual Addresses


These are MAC addresses which are made up of two sections, an IEEE assigned vendor code (often called the Organisational Unique Identifier or OUI) followed by the 3-byte sequence assigned by the vendor which is unique for each interface (and therefore for each station, providing it has only one interface). IBM have addresses of the format 10005Axxxxxx whilst Bay Networks have the format 000081xxxxxx.

A list of OUIs can be found at OUI Index.

The addresses set by the manufacturers can be left and used for network administration, this is called Universal Administration. However, it is perfectly reasonable to allow Local Administration where addresses are assigned locally by the Network Administrator, this works well provided that the addresses are unique.

The hardware address, or MAC address is transmitted and stored in Ethernet network devices in Canonical format i.e. Least significant Bit (LSB) first. You may hear the expression Little-Endian to describe the LSB format in which Ethernet is stored and transmitted. Token Ring and FDDI, on the other hand, store the MAC address in the NICs with the Most Significant Bit (MSB) first, or Big-Endian. This is known as Non-Canonical format. Be aware that this only applies to the NIC and not how the MAC address is transmitted on the wire, just as in Ethernet the MAC address is in Canonical format on the wire! Note also that non-canonical format applies on a byte by byte basis i.e. the bytes are transmitted in the same order it is just the bits in each of those bytes that are reversed! The storage of the MAC addresses in Token Ring and FDDI devices however, may sometimes still be in Canonical format so this can sometimes cause confusion. The reference to, the distribution of MAC addresses and the OUI desinations are always carried out in Canonical format.

Consider the following example where an address in canonical format is converted to its non-canonical format:

Canonical address 08 00 3f e1 4d a8
Binary 00001000 00000000 00111111 11100001 01001101 10101000
Reverse bits in each byte 00010000 00000000 11111100 10000111 10110010 00010101
Non-Canonical version 10 00 fc 87 b2 15

Reversing the bits in each byte is the same as reversing each nibble and then reversing the bits in each nibble so you can use a conversion table such as the one below to speed up the conversion.

Convert From (Hex) Convert From (Binary) Convert To (Binary) Convert To (Hex)
0 0000 0000 0
1 0001 1000 8
2 0010 0100 4
3 0011 1100 C
4 0100 0010 2
5 0101 1010 A
6 0110 0110 6
7 0111 1110 E
8 1000 0001 1
9 1001 1001 9
A 1010 0101 5
B 1011 1101 D
C 1100 0011 3
D 1101 1011 B
E 1110 0111 7
F 1111 1111 F

When performing translational bridging between Ethernet and Token Ring, only non-routable protocols will work e.g. LAT, MOP and NetBIOS. The reason for this is that changing the bit order is fine for the MAC addresses in the frame header, however for protocols such as ARP, the MAC addresses are also carried within the data portion of the frame and are therefore out of reach from layer 2 bridges.

3.2 Group Addresses


Group addresses (Multicast addresses) are used to send the same data to a designated group of stations. This group is set up at the configuration stage of the network.

3.3 Broadcast Address


The Broadcast address is used to transmit the same data to all stations that are active within a network.

3.4 Functional Addresses


Stations use functional addresses when they need to communicate with stations which have been designated to carry out a specific operation. An example would be stations sending soft error report frames to Ring Error Monitor stations that have the ring error monitor functional address. There are 31 possible functional addresses of which one is used for multicasting, 0xc000.0004.0000, which can still be used by other functions within Token Ring so it is not exclusive. In canonical format this address is 0x0300.0020.0000.

3.5 I/G and U/L


With Ethernet, the first octet uses the lowest significant bit as the I/G bit (Individual/Group address) only and does not have such a thing as the U/L bit (Universally/Locally administered). A destination Ethernet address starting with the octet '05' is a group or multicast address since the first bit (LSB) to be transmitted is on the right hand side of the octet and is a binary '1'. Conversely, '04' as the first octet indicates that the destination address is an individual address. Of course, in Ethernet, all source address will have a binary '0' since they are always individual.

In Token Ring, the second bit in the first octet is used to indicate whether the address is Universally (0) or Locally (1) administered. The U/L bit is used in both destination and source addresses. The I/G bit in the Token Ring source address is renamed the Routing Information Indicator (RII) to indicate that source routing information is contained within the data field. FDDI also has the same address structure as Token Ring.

4. 4 Mb/s Frame Transmission



Before a station can transmit data it must first transmit a token frame. Whilst a station holds a token on the ring, no other station can transmit anything at the same time. This guarantees that every active station is able to transmit data at regular intervals.

A station which has data to transmit starts by capturing the current passing token in order to gain access to the network. It can hold the token for the defined token holding time (normlly 10 milliseconds). The station then converts the token into a data frame by changing the AC field (to indicate that this is a data frame as opposed to a token) and its own address, the destination address and the data itself. The data frame is received and repeated by each active downstream station. The receiving station recognises its address, copies the data, sets the Frame Status field (to indicate successful receipt of frame) and retransmits the frame. The originating station has the responsibility of removing the data frame so it strips the frame of its data and retransmits the frame as the token ready for the next station to grab it.

Each bit on arrival at a station, is copied into a 1-bit wide buffer and then is copied out onto the ring again. Whilst it is in the buffer, the bit is analysed and it may be modified before being written out again. This step regenerates the bit and produces a delay of 1-bit.

Differential Manchester Encoding is used with high (+ve) and low (-ve) voltages between 3.0 and 4.5 volts. Differential Manchester usually uses high-low and low-high transitions for bits, however in addition, 802.5 also uses high-high and low-low in particular control bytes.

5. 16 Mb/s Frame Transmission



16 Mb/s rings can work in one of two ways, described below:

5.1 Early Token Release (ETR)


Although only one token is still allowed, with ETR the orginating station releases the token immediately after it has transmitted its data frame. What this does is allow another station to grab the token before the first station has received its data frame back from the receiving station with confirmation that the frame has been copied by the receiving station. If you think about it, the larger the ring, the longer it takes for the data frame to traverse it and so more than one data frame can exist at one one time.

Stations operating at 16Mb/s will drop to 4Mb/s if mixed in with a 4Mb/s ring.

5.2 Priority/Reservation Process


Eight priority levels 0 (low) to 7 (high) exist which allow access priorities to be given to specific frames queued for transmission. Priority Control Protocol sets the token priority level when circulating the data frame, and then resets it to zero once the frame has gone around, thereby preventing a high priority station from dominating the ring.

6. Station Functions



6.1 Active Monitor (AM)


On a new ring the AM is the first station to become active. Sometimes a new AM is determined by the Monitor Contention process, the station with the highest station address becomes the AM. All other stations become Standby Monitors (SM) and these watch the AM for the following errors:
  • The AM fails to detect any frames within 10 milliseconds.
  • A station fails to detect an AM on the ring, i.e. no MAC frame saying AM present, is detected within 15 seconds.
  • A station fails to see any tokens or frames within 2.6 seconds.
The AM carries out the following tasks:
  • Master Clock - stations synchronise their transmit clocks with the clock signal from their upstream neighbour.
  • Proper Ring Delay (or Minimum Ring Latency) - a 'token-sized' (24 bit long) delay is introduced to the ring to guarantee a long enough ring.
  • Ring Purge - This happens when the station becomes the new AM or a ring error is found. A ring purge MAC frame is transmitted, the timers are reset and a new token is released.
  • Lost frames - If a token has not been seen for 10 milliseconds, then a ring purge is carried out and a new token is sent. This can happen if a source station suddenly leaves the ring before removing its own frame.
  • Orphaned frames - If a transmitting station goes inactive before receiving back its frame, the frame could circulate endlessly so preventing the release of a token and thereby stopping anyone else from transmitting. The Monitor bit is therefore set as each frame passes through the AM and each frame is checked to see if the Monitor bit is set, if so, then the frame is removed.
  • Ring Poll (neighbour notification) - The AM initiates this every 7 seconds and makes sure that it completes.

6.2 The Ring Poll process


Data flows anticlockwise around the ring, and each station needs to know the address of its Nearest Active Upstream Neighbour (NAUN) as this is used to identify the Fault Domain when an error occurs. The following occurs during the process:
  1. The AM broadcasts an Active Monitor Present (AMP) frame.
  2. The first station copies the AMP, changes the Address Recognised and Frame Copied bits, saves the SA as its NAUN and transmits the frame on. This repeated all around the ring.
  3. This first station then sets a 20 milliseconds neighbour notification response timer, after which it grabs a token and transmits a Standby Monitor Present (SMP) frame as a MAC broadcast.
  4. The next active downstream neighbour receives the SMP frame, saves the SA as its NAUN, changes the address and frame copied bits to indicate that the frame was read and carries out step 3.
  5. This process continues downstream until the AM copies the last SMP frame.

6.3 Ring Parameter Server (RPS)


The RPS assigns ring parameters to stations on their insertion into the ring. These parameters are; Ring Number, RPS version level, Soft core timer value. The RPS also verifies that the stations have consistent ring values and sends the station registration information to IBMs LAN Manager.

6.4 Configuration Report Server (CRS)


The CRS collects statistics about the ring and configuration changes such as NAUN and AM changes. These are sent to LAN Manager.

6.5 Ring Error Monitor (REM)


This collects soft error reports from stations plus hard error MAC frames for LAN Manager.

6.6 Connecting to the Ring


A station must carry out the following when inserting into the ring:
  1. Lobe Test - MAC frames with DA as zero are transmitted, if successful, a duplicate address test MAC frame is sent to try the receive path and finally a phantom current is sent to open the relay at the hub port so including the station within the ring.
  2. Monitor Check - Wait to receive an AMP, SMP or ring purge MAC frame, thereby indicating the presence of an AM; otherwise the stations starts the AM contention process (token claiming)
  3. Duplicate Address Check - Two duplicate address MAC frames addressed to itself, are sent. If the station receives two frames back with the address recognised and frame copied bits changed, then the station knows that there is already an active station with the same address, so it de-inserts from the ring.
  4. Ring Poll Participation - The station learns its NAUN address and passes its address to its nearest active downstream neighbour. This called Neighbour Notification.
  5. Request Parameters - The station asks for parameters from an RPS, if there is one, otherwise it uses default parameters. At this point the network manager can force the adapter to de-insert if the new Adapter threatens the integrity of the ring.
The traditional Type 1 IBM Data Connector is often called the Media Interface Connector (MIC). The following diagram details how the MIC to RJ45 pinouts are laid out:

Media Interface Connector

Traditionally, the Token Ring NIC (Network Interface Card) would have a shielded DB9 connector. In order to convert over to 4-pair UTP a media filter is required. An example of a media filter is Avaya's 370C1 which matches the 150 ohm impedance of the NIC data in and data out circuits with the 100 ohm impedance of the UTP. In addition, the media filter attenuates frequencies above 30MHz. Nowadays, many Token Ring NICs present the UTP connection directly.

The traditional passive MAU would allow a maximum lobe length of 37.8m on Category 3 UTP and a maximum number of stations as 72. On Category 5 cable this increases to 100m and 104 stations. Nowadays, active hubs contain the ring and allow many more stations (still at the maximum 100m lobe length), but this depends on the equipment manufacturer. There are 'equivalent electrical lobe length' values for items such as the media filter, patch cord and equipment cables, and these values must be subtracted from the maximum lobe length when designing the cabling system.

7. Network Management MAC Frames



  • Beacon - This frame is used by the Adapter in the Beacon Process.
  • Lode Media Test - This frame is used by the Adapter in Phase 0 of the Insertion Process to test the continuity of the wire is a loop back path. This occurs prior to physical insertion in the ring. It also occurs in the Auto Remove Procedures in the Beacon Process, which use the Insertion Phase 0 process. This frame is ignored by the Adapter when it is received.
  • Claim Token - This frame is used by the Adapter in the Monitor Contention Process.
  • Re-IMPL Force - This frame is sent to the Adapter by the IMPL server to cause the Adapter to inform the attached product that a re-IMPL is required. If the IMPL function is not enabled, a response MAC frame with a response code of Function Disabled is transmitted.
  • Remove Ring Station - This frame is sent by the Network Manager to request the Adapter to de-insert itself from the ring. This frame is valid any time after Phase 0 of the Insertion Process. If the Adapter is inserted, the Adapter de-inserts from the Ring and indicates Remove Received in the Ring Status reported to the attached system. If this frame is received in the Insertion Process, the Adapter removes itself from the ring and terminates the OPEN command with an error condition, indicating that a Remove MAC frame was received.
  • Report Station State - This frame is sent by the Adapter in response to the Request Station State MAC Frame (sent to the Adapter by the Network Manager).
  • Report Monitor Error - The frame is used to report a problem with the Active Monitor or the possibility of a duplicate address of stations contending for Active Monitor. This frame is sent to the functional address of the Ring Error Monitor (REM).
  • Report SUA Change - This frame is used in the Ring Poll process to report a change in the address of the station that is the adjacent upstream station from the Adapter generating the Report SUA Change MAC frame. This frame is sent to the functional address of the Network Manager.
  • Report New Monitor - This frame is sent by the Active Monitor Adapter, after winning contention, to report to the Network Manager that the Adapter is now the new Active Monitor.
  • Report Station Attachment - This frame is sent by the Adapter in response to the Request Station Attachment MAC frame. The Request Station Attachment MAC frame is sent by. the Network Manager.
  • Report Ring Poll Failure - This frame is sent by the Active Monitor to the Ring Error Monitor to report a failure in the Ring Poll Process. This frame contains the address of the last station that responded in the Ring Poll Process before the Active Monitor detected the failure.
  • Report Error - This frame is used to report soft error events to the Ring Error Monitor.
  • Report Station Address - This frame is sent by the Adapter in response to the Requester Station Address MAC frame. The Request Station Address MAC frame is sent by the Network Manager.
  • Request Station State - This frame is sent by the Network Manager to request the Adapter to respond with a Report Station State MAC frame.
  • Request Initialisation - This frame is transmitted in Phase 4 of the insertion Process to request operational parameters from the Ring Parameter Server.
  • Request Station Attachment - This Frame is sent by the Network Manager to request the Adapter to respond with a Report Station Attachment MAC frame.
  • Request Station Address - This frame is sent by the Network Manager to request the Adapter to respond with a Report Station Address MAC frame.
  • Report Transmit Forward - This frame is sent by the Adapter to the Network Manager functional address when a frame is forwarded and stripped by the Transmit Forward Process.
  • Resolve - This frame is used by Logical Link Control to find a routing path to an Adapter in the network. The Adapter responds to the frame with a Response MAC frame. The bridges participate by modifying the Resolve MAC frame when the frame is transferred from one ring to another by a bridge. When the transfer occurs, the bridge updates the routines information field in the frame.
  • Response - This frame is used to send positive responses to frames that require acknowledgement, or to report errors in syntax in a MAC frame sent to the Adapter, The response MAC frame is ignored by the Adapter when received.
  • Active Monitor Present - This frame is transmitted by the Active Monitor when in the Ring Poll Process to request a Standby Monitor Present MAC frame from the nearest downstream neighbour from the Active Monitor.
  • Standby Monitor Present - This frame is used in the Ring Poll Process to respond to an Active Monitor Present or Standby Monitor Present MAC frame.
  • Ring Purge - The frame is used by the Active Monitor in the Ring Purge Process.
  • Change Parameters - Change Parameters MAC frame is sent by the Network Manager to change certain parameters in the Adapter. This frame will be accepted in response to a Request Initialisation MAC frame transmitted by an Adapter in the Insertion Process. When received, this frame can set the following parameters:
    • Local Ring Number
    • Physical Drop Number
    • Error Report Timer Value
    • Authorised Transmit
    • Function Classes
    • Authorised Access Priority
    • Authorised Environment
  • Initialise Ring Station - Initialise Ring Station MAC frames are sent by the Ring Parameter Server to set parameters in the Adapter when the Adapter is in the Insertion Process and transmits a Request Initialisation MAC frame. When received, this frame can set the following parameters within the Adapter:
    • Local Ring Number
    • Physical Drop Number
    • Error Report Timer Value
    • Authorised Environment
  • Transmit Forward - This frame is used in the Transmit Forward Process
  • Duplicate Address Test - This frame is sent by the Adapter in Phase 2 of the Insertion Process. It verifies that the specific address to be used by the Adapter is unique to the ring which the Adapter is inserted.

8. Errors



8.1 Hard Errors


Hard Errors are normally media or adapter faults that require the reconfiguration of the ring to effect full recovery. A downstream adapter from the fault recognizes the error state and transmits a Beacon MAC frame. This frame is addressed to all adapters on the same ring and includes the NAUN of the originating station together with the type of error detected.

The upstream neighbour will remove himself after he has received a predetermined number of Beaconing frames (eight successive frames in the IBM architecture) where he is the NAUN of the transmitting station. The upstream neighbor will then proceed to re-insert himself after testing itself and its lobe and includes a Duplicate Address Test MAC frame. Upon successful completion of the tests, the NAUN will insertion itself. Should the ring fail to recover after the NAUN test, the Beaconing ring station will remove itself and test itself, its lobe, and perform a Duplicate Address test.

If both the NAUN and Beaconing ring station tests fail to successfully repair the ring, the ring will not respond to automatic recovery procedures and will have to be repaired manually.

8.2 Soft Errors


Soft errors are intermittent faults that temporarily disrupt transmission and can be resolved by normal error recovery procedures within the adapter. These errors included CRC errors, time-outs, etc. and may result in the network manager bypassing a faulty adapter if network performance is compromised.

These errors are logged by the error counters within the adapter and upon expiration of the soft error report timer, a MAC frame is forwarded to the Ring Error Monitor. Two groups or domains of errors are logged, isolating errors and non-isolating errors Isolating errors are identifiable to a specific adapter or the media interconnecting two adapters. Non-isolating errors are not identifiable with any specific adapter on the network and are normally logged on multiple adapters.

Upon expiration of the forwarding timer, the count of each error type is forwarded by the Report Soft Error MAC frame and the counters are reset. This MAC frame also includes the NAUN for the transmitting station.

There are 10 'Soft Errors' reported by stations on a network. These are all errors that were not severe enough to really effect the network. When a station detects one of these 10 errors, it updates an internal counter. Every two seconds it reports the status of these counters to the network, then clears them back to zero (of course, it doesn't report that status if no error occurred in the last two seconds, that would be pointless). These reports are for information purposes only and are not acted upon by the Token Ring standard (But of course, are sent up to network management applications).

These 10 errors are broken down into 5 isolating errors, and non-isolating errors. An isolating error means that the locus of the problem can be determined, while a non-isolating error may have happened anywhere on the ring.

These are listed in order of importance to the network administrator.

Line Errors


A line error is the equivalent of an Ethernet CRC error. Each Token Ring frame contains a CRC (actually called an FCS - Frame Check Sequence) like Ethernet. If there is a CRC error in the Token Ring frame, the line error counter is updated. A line error also occurs when there is a coding violation in the data part of the frame (each bit on a Token Ring can have four values: 0, 1, J, K; only 0 and 1 are used for sending data, the presence of a J or K is an error).

A line error is an 'isolating error'. As the frame travels around the ring, each station checks for a line error. To prevent them all from reporting the same CRC error, for example, the first station will set a special bit to indicate that the error was already detected. Therefore, we know that the fault that caused the line error lies immediately upstream between the station, and that station's upstream neighbour.

What causes line errors? The same things that causes CRC errors on Ethernet: Electronic Noise (EMI) and cable problems. Token Ring is a little bit more gracious about line errors than Ethernet because it can check its lobe cable before entering the network.

If you lay your 16Mbps UTP cable across your florescent lights, you are almost certain to get line errors (attach your cables to the ceiling). In general, you will get more line errors with 16Mbps Token Ring using UTP (even following all the specs to the letter). They also often occur on Token Ring due to intermittent devices like fans and elevators. I have seen bizarre behaviour, such as the first port in every hub module from a vendor cause line errors (due to interference from the backplane). The nice thing is that you can track them down using almost any network management product for Token Ring (because they are isolating).

Note that while the station downstream reports the line error, it is equally valid for a Management Application to associate the line error with either that station upstream from the fault or the station downstream from the fault.

Burst Error


A Burst Error is "five half-bit times without a transition".

In short, it means that either there was a very brief disconnection in the cable, or a very brief surge or electronic noise. In other words, its just a very severe line error that wasn't long enough in duration to cause the ring to beacon. You will get them every time a sation enters or leaves the network (which causes a brief disconnection when the lobe attaches/disconnects). You will get them when you pull cable to close to the ballasts in florescent lights.

A burst error is an isolating error, just like the line error (see above).

Receiver Congestion


A station reports receiver congestion when the card sees a frame on the network addressed to it, but doesn't have any buffer space left in which to put it. In other words, the adapter is receiving frames from the network faster than the machine can pull them out of the adapter's buffers. This is a common problem with file servers, bridges and routers. In order to resolve the problem, you should use a network analyser Dike a ProTools Foundation Manager, Network General Sniffer, Novell Lanlyzer, etc.). Filter for the traffic going to and from the device to determine whether it is really needed (or find a way to re-route it past the overworked device).

Note that this is a 'non-isolating' error, even though it indicates the exact device that is overworked. This is because the assumption is that the problem lies not with the device but the other stations that are sending frames too fast to it. I suspect that this is just an excuse so that there are an even 5/5 distribution of isolating/non isolating errors instead of an unsightly 6/4 distribution. Indeed, IBM's LAN management products do treat the Receiver Congestion like an isolating error.

Internal Error, Abort Delimiter Transmitted and A/C Error


These three are the other 'isolating' errors. All three indicate that a card is about to fail, or has already failed. In any case, the card isolated by the error should be replaced. In any case, these errors occur very seldom on a Token Ring (as opposed to the ones mentioned above, which happen quite often).

An Internal Error indicates that the card (who reported the error) encountered an Internal Error, but was able to recover and remain on the network. Note that one common cause of this is heat prostration - putting the card in an overloaded system, causing the whole system to heat up past reasonable limits.

An Abort is the same as an Internal Error, except the fault occurred while transmitting a frame, and the card was forced to abort the transmission by sending a special sequence (noted below) called an "Abort Delimiter". Accordingly to various documentation, an internal error will also be reported and the card will usually remove itself from the ring permanently (making the point moot).

An A/C error indicates not a fault with the card reporting it, but with the card upstream. The CRC (aka FCS) appears not at the 'very' end of the frame (as in Ethernet) but near the end. After the CRC, there are two more bytes. One is used to indicate whether the intended recipient of the frame actually recognised the fact, and whether (having recognised it), successfully grabbed the frame from the network (aka copied the frame). These bits are important in several processes in the ring, the most important of which is the Ring Poll (described below). An error is reported when the downstream neighbour detects that the upstream neighbour should have set one of the other, but hasn't. This indicated that the station upstream is in difficulty and will probably soon cause the ring to crash.

Lost Frame Error and Token Error


These two are mentioned together because they both occur almost always for the same reason. They are both non-isolating errors (you don't know where on the ring the frame was lost, or you don't know who caused an error in the token).

A Lost Frame results when a station transmits a frame around the ring and doesn't get it back. Remember every station simply repeats the signal. It is the transmitter's job to 'strip' the frame off the network and pass on the token.

A Token Error occurs when the token gets corrupted, or if the Active Monitor doesn't see a new frame transmitted in a certain amount of time. Note that only the Active Monitor reports Token Errors (if you see that in the past that other stations have reported Token Errors, that means they were the Active Monitor when they reported them).

Both of these errors occur when stations enter/leave the ring. When this happens, the ring is broken temporarily (it is broken a little bit to sync up with the signal, which is one reason Token Ring uses a self-clocking signalling method). This break regularly stomps on the token, or the frame being transmitted. When you see that some stations report more lost frames than others, it is simply that they are transmitting more frames than others (ie. they are still getting their 'fair share' of lost frames).

Frequency Error


This error (also known as jitter) occurs when the signal that the adapter receives from the upstream neighbour differs from its own internal clock by too much. This is a symptom of going beyond the limits (72 stations) of UTP cabling. It also occurs more often with 16Mbps operation than with 4Mbps.

Frame Copied Error


This is reported by a station when it appears that some other station might have the same address. There are bits at the very end of a frame that indicate when a station has 'recognised' its address in the frame and has 'copied' it from the frame network. This is used by transmitting stations to verify that the frame has reached its destination and by receiving stations to verify that it is only one receiving that frame.

It is virtually impossible to create a ring with a duplicate address (that condition is checked before a station comes onto the ring). This error most commonly is caused by transparent bridges on Token Ring. When a transparent bridge is first turned on, it must learn which stations are on which side of the bridge. If the first frame it sees is from 'a' to T and it doesn't know that T is on the ring, then it will assume that T is on some other ring, bridge the frame and set the Address Recognised bits. This, of course, will cause 'f to report a Frame Copied Error. This doesn't really result in any problems with the network, it just looks like it does.

9. Source Route Bridging (SRB)



9.1 Operation


SRB is designed for use in Token Ring networks where multiple rings are connected via bridges. Source Route Bridging relies on the end stations to determine the path that a frame should take, it is therefore not transparent but can use more simply designed bridges. The source station knows the route to the destination.

In the Routing Information Field (RIF) 4 bits are designated for the bridge number so the highest bridge number allowed is 15. IBMs version of Token Ring limits the total number of bridges (irrespective of bridge number) to 7 whereas 802.5 can allow 13 bridges in a network.

Route Discovery is the technique used to find the best path between stations and works by the transmission of broadcast discovery frames between the source and destination stations. There are two types of route discovery frames; Single Route Broadcast (SRB) (in SRT this is called the Spanning Tree Explorer (STE)) which takes just one route between end station (used in a NetBIOS environment), and the All Routes Broadcast (ARB) (in SRT this is called the All Routes Explorer (ARE)) which takes all possible routes between stations (used in an SNA environment). A Spanning Tree Explorer is an explorer packet sent to a defined group of end stations that have been configured as part of the Spanning Tree. Only bridges in the Spanning Tree forwarding state will add themselves to the path. An All-Routes Explorer packet is sent to every end station on every path. The third type of source route frame called a Specifically Routed Frame (SRF) which takes just one route to the destination because the end station knows the route to the destination (in SRT this is called the non-broadcast frame). The type of frames used is determined by the application and the bridges. Some bridges, for instance may not pass SRBs. SRT is discussed later on in this document.

All frames destined for remote rings including explorer frames have their multicast bit (this is the Individual/Group bit) of the Source MAC address set to 1. This bit is the MSB of the first byte of the address. If you think about it, to call this bit the I/G bit does not make sense for a source address. This is because the source address is always unique. Calling it the I/G bit really only applies to destination addresses. Therefore, when this bit is used for source addresses it is often called the U bit or the Routing Information Indicator (RII). Once the frame reaches the destination this bit has to be set back to 0 to save confusion when it becomes the destination address as far as the other end is concerned.

9.2 Routing Information Field


The diagram below shows the Token Ring frame which has the RIF expanded. The RIF is optional and is only required when a frame is leaving a ring. If the RIF is not present in a Token Ring frame then the first bit of the Source Address (the multicast bit or the individual/group address bit) is set to 0 and the data follows the source address. If a RIF is present then the first bit of the Source Address (U bit) is set to 1 (i.e. the address starts with a hex value between 8 and F) and the data follows the RIF.

RIF field

  • Routing Type - identifies the type of source route frame received. SRF is 000, ARB (ARE) is 100 (used by SNA) and SRB (STE) is 110 (Used by NetBIOS).
  • Length - indicates the length of the RIF which can be between 2 and 30 bytes, each ring/bridge pair is 16 bits (2 bytes). Up to 14 ring/bridge pairs are allowed in the RIF, however the Token Ring chips generally only allow 8.
  • Direction Bit - for ARB and SRB frames it is set to 0 whereas for SRF frames it is set to 1 meaning that the route designators are to be read in reverse.
  • Largest Frame - bridges or end stations use this to indicate the largest frame that they are allowed to handle. The lowest common size is required so this value is always decemented, never incremented. The following table lists the codes used for each MTU size.
    Bits MTU (bytes)
    000 516
    001 1500
    010 2052
    011 4472
    100 8144
    101 11407
    110 17800
    111 64000 (Used for All-route broadcasts)
  • LAN ID - specifies the ring number that has to be unique for the ring.
  • Bridge Number - this only needs to be unique for when multiple bridges connect to the same ring. The last bridge designator in the RIF is always 0.
When a source is trying to contact a particular destination the following steps are taken:
  1. An ARP (broadcast) is sent for the destination's MAC address. The ARP reply contains the destination's MAC address but not the location or the route to the destination.
  2. An initial test frame is sent out (a local ring explorer). This saves unnecessary network traffic. If this test frame is returned without having reached the destination then the next step is to send special frames that determine the path to the destination. These frames have the multicast bit or U bit set indicating a RIF.
  3. Each bridge that receives the frame adds it's routing information to the RIF and forwards the frame out of its ports.
  4. There are different ways in which a route can be found. One way is for a station to send an SRB across the network, the Spanning Tree algorithm allows only one of these frames to reach the destination station. It is worth noting that in Source Route Bridging, Spanning Tree is used to block redundant paths for SRBs, all other non-broadcast frames can still use these paths.
  5. When the destination station receives an SRB it then sends an ARB in reply to each SRB across all possible paths back to the originating station. The destination station flips the Direction Bit (D) to turn the path around from destination to source. On the way back the ARB frame appends the bridge ID, the LAN number and the maximum allowable frame size for each LAN to the Routing Information Field (RIF). This is done with the 2 byte Route Designator (RD) within the RIF. This RD is used by the bridge to make sure that the same bridge is not crossed twice. IBM demands that there is a maximum hop limit of 8 rings (7 bridges) i.e. between 2 and 8 RDs. 802.5 allows for 14 rings (13 bridges).
  6. The source station receives a number of these ARBs and it can look within the RIF to see the exact path that the frame took. The source station picks the best path based on the first packet to return, the number of hops between source and destination and the packet size. The source gets to choose the route, hence the name Source Route Bridging.
  7. The path is copied into every Non-Broadcast (NB) frame destined for the remote station for that particular session.
  8. The source station sets the Routing Information Indicator (RII), which is the Most Significant Bit (first bit) in the Source address field, to 1. Then each bridge knows to look at the RIF to route the frame to another bridge. If the bit is set, the bridge checks the RIF for its own ID and LAN number. If it finds itself there then it forwards the frame to the next bridge. If it does not find itself there then it ignores the frame. This means that you can have redundant links in the network.
If other stations and bridges are added to the network, then the best route may change. This happens dynamically.

Another method to find a route is for the source station to send an ARB and then it uses the first ARB that it receives back, this is effectively looking at all rings and all routes. Or it may receive an SRF, in which case it uses that one specific route only. Another method is for the source station to send an SRB and use the first SRB back, or the first SRF, this is the Spanning Route method described above.

9.3 RIF Cache Calculation


Bear in mind that a frame is never sent to a bridge, only through it, so the last bridge is always 0! Also, the RIF is always the same regardless of which direction the frame is travelling. Changing the direction bit just tells the station which way to read the RIF.

Another point to remember is that bridge numbers do not have to be unique because each bridge sits between unique ring numbers.

For an example exercise take the following setup:

RIF Example

The client can reach the server through two ways:
  1. via ring 10, bridge 1, ring 20, bridge 5 and ring 40.
  2. via ring 10, bridge 10, ring 30, bridge 15 and ring 40.
The way back from the server can happen via two paths:
  1. via ring 40, bridge 5, ring 20, bridge 1 and ring 10.
  2. via ring 40, bridge 15, ring 30, bridge 10 and ring 10.
Each of these 4 paths has a different RIF and we will calculate the RIF for each in turn.

Looking at the first path from the client to the server we need to take each part of the RIF in turn (refer to the RIF diagram above):
  • The field Type is 3 bits long and in our case we are looking at SRFs so this field will contain the binary 000 which is 0 in hex.
  • The field Length is 5 bits long and indicates the length of the RIF in bytes. The first 2 bytes of a RIF contain the control information, each Ring/Bridge pair requires 2 bytes of the RIF. In the case of the first path the Ring/Bridge pairs (in decimal) are 10/11, 20/21 and 40/0 giving a length for the RIF of 8 bytes which is 0 1000 in binary and 8 in hex. You will note that the last bridge is set to 0, this is the imaginary bridge on the same ring as the destination server, in all cases this is 0.
  • The Direction Bit is set to binary 0 because the path in the RIF is meant to be read from left to right which is the direction in which the frame is travelling. Be aware that this bit forms part of the hex value which includes the next field the MTU.
  • The next 3 bits indicate the MTU. We are working in a Token Ring environment so the largest frame is not going to exceed 4472 bytes. We can see from the table above that the binary code for this size is 011 and the hex for this is 3 if we include the previous direction bit.
  • The next 4 bits are unused and are always 0000 or 0 in hex.
  • Now comes the first of the ring/bridge pairs 10/1. Looking at 12-bit field for the ring, the value 10 in decimal is 0000 0000 1010 in binary which is 00A in hex. For the 4-bit bridge field, 1 in decimal is 0001 in binary and 1 in hex.
  • Looking at the next ring/bridge pair 20/5, we see that for ring 20 the 12 binary bits are 0000 0001 0100 which is 014 in hex. The bridge number 5 is 0101 in binary and 5 in hex.
  • For the final ring/bridge pair 40/0, ring 40 has binary bits 0000 0010 1000 which is 028 in hex. The bridge number is 0000 in binary and therefore 0 in hex.
  • Putting this together gives a RIF of 0x0830.00A1.0145.0280.
Let us take the next path from the client to the server:
  • The Type field is 3 bits long and we are still looking at SRFs so this field will contain the binary 000 which is 0 in hex.
  • Next comes the 5-bit Length field. In the case of this second path the Ring/Bridge pairs (in decimal) are 10/10, 30/15 and 40/0 giving a length for the RIF of 8 bytes which is 0 1000 in binary and 8 in hex. You will note as before that the last bridge is set to 0, this is the imaginary bridge on the same ring as the destination server, in all cases this is 0.
  • The Direction Bit is set to binary 0 because the path in the RIF is meant to be read from left to right which is the direction in which the frame is travelling. As always, this bit forms part of the hex value which includes the next field the MTU.
  • The next 3 bits indicate the MTU. We are working in a Token Ring environment so the largest frame is not going to exceed 4472 bytes. We can see from the table above that the binary code for this size is 011 and the hex for this is 3 if we include the previous direction bit.
  • The next 4 bits are unused and are always 0000 or 0 in hex.
  • Now comes the first of the ring/bridge pairs 10/10. Looking at 12-bit field for the ring, the value 10 in decimal is 0000 0000 1010 in binary which is 00A in hex. For the 4-bit bridge field, 10 in decimal is 1010 in binary and A in hex.
  • Looking at the next ring/bridge pair 30/15, we see that for ring 30 the 12 binary bits are 0000 0001 1110 which is 01E in hex. The bridge number 15 is 1111 in binary and F in hex.
  • For the final ring/bridge pair 40/0, ring 40 has binary bits 0000 0010 1000 which is 028 in hex. The bridge number is 0000 in binary and therefore 0 in hex.
  • Putting this together gives a RIF of 0x0830.00AA.01EF.0280.
Taking the first path back from the server to the client:
  • The Type field is 3 bits long and we are still looking at SRFs so this field will contain the binary 000 which is 0 in hex.
  • Next comes the 5-bit Length field. In the case of this path the Ring/Bridge pairs (in decimal) are 10/1, 20/5 and 40/0 giving a length for the RIF of 8 bytes which is 0 1000 in binary and 8 in hex.
  • The Direction Bit is set to binary 1 because the path in the RIF is now meant to be read from right to left which is the direction in which the frame is travelling. As always, this bit forms part of the hex value which includes the next field the MTU.
  • The next 3 bits indicate the MTU. We are working in a Token Ring environment so the largest frame is not going to exceed 4472 bytes. We can see from the table above that the binary code for this size is 011 and now the hex for this is B if we include the previous direction bit.
  • The next 4 bits are unused and are always 0000 or 0 in hex.
  • Now comes the first of the ring/bridge pairs 10/1. Looking at 12-bit field for the ring, the value 10 in decimal is 0000 0000 1010 in binary which is 00A in hex. For the 4-bit bridge field, 1 in decimal is 0001 in binary and 1 in hex.
  • Looking at the next ring/bridge pair 20/5, we see that for ring 20 the 12 binary bits are 0000 0001 0100 which is 014 in hex. The bridge number 5 is 0101 in binary and 5 in hex.
  • For the final ring/bridge pair 40/0, ring 40 has binary bits 0000 0010 1000 which is 028 in hex. The bridge number is 0000 in binary and therefore 0 in hex.
  • Putting this together gives a RIF of 0x08B0.00A1.0145.0280.
Taking the second path back from the server to the client:
  • The Type field is 3 bits long and we are still looking at SRFs so this field will contain the binary 000 which is 0 in hex.
  • Next comes the 5-bit Length field. In the case of this path the Ring/Bridge pairs (in decimal) are 10/10, 30/15 and 40/0 giving a length for the RIF of 8 bytes which is 0 1000 in binary and 8 in hex.
  • The Direction Bit is set to binary 1 because the path in the RIF is now meant to be read from right to left which is the direction in which the frame is travelling. As always, this bit forms part of the hex value which includes the next field the MTU.
  • The next 3 bits indicate the MTU. We are working in a Token Ring environment so the largest frame is not going to exceed 4472 bytes. We can see from the table above that the binary code for this size is 011 and now the hex for this is B if we include the previous direction bit.
  • The next 4 bits are unused and are always 0000 or 0 in hex.
  • Now comes the first of the ring/bridge pairs 10/10. Looking at 12-bit field for the ring, the value 10 in decimal is 0000 0000 1010 in binary which is 00A in hex. For the 4-bit bridge field, 10 in decimal is 1010 in binary and A in hex.
  • Looking at the next ring/bridge pair 30/15, we see that for ring 30 the 12 binary bits are 0000 0001 1110 which is 01E in hex. The bridge number 15 is 1111 in binary and F in hex.
  • For the final ring/bridge pair 40/0, ring 40 has binary bits 0000 0010 1000 which is 028 in hex. The bridge number is 0000 in binary and therefore 0 in hex.
  • Putting this together gives a RIF of 0x08B0.00AA.01EF.0280.
On examination of these RIFs we can glean some pointers to help us read RIFs quickly from a network analyser:
  • The length of the RIF will not exceed 15 bytes (or 13 ring/bridge pairs), the first 4 hexadecimal numbers represent the type, length and direction of the RIF. SRFs start with hex 0, AREs with hex 8 and SRBs with hex A.
  • When numbering bridges make sure that they are given numbers no higher than 15 to make reading the RIF easier.
  • The first two bytes (first four hex numbers) after the RIF details represents the first ring/bridge pair, the next two bytes represents the next ring/bridge pair and so on.
  • The final hex number will always be 0 representing the last bridge on the ring of the destination device.

9.4 Other RIF Examples


Taking the first route described above where SRFs (000) are going via the route Ring 10, Bridge 1, Ring 20, Bridge 5, Ring 40 and Bridge 0. There are therefore three ring/bridge pairs giving a RIF length of 8 bytes (2 + 6), the direction bit is 0 (left to right) and the largest MTU is 4472 bytes. We can represent it thus:

SRFs

Other scenarios can be illustrated as slight variations of above and include the following:
  • With only two rings the RIF would be 0630.00A1.0140 where the 6 represents 6 bytes for the length.
  • With four rings the RIF would be 0A30.00A1.0145.0284.0220 where the ring/bridge pairs are 10/1, 20/5, 40/4 and 34/0 and the A represents 10 bytes for the length.
  • With eight rings the beginning of the RIF would be 1230.00A1.0145.0284..... where the 12 represents 18 bytes for the RIF length.
  • With the direction bit set the RIF would be 08B0.00A1.0145.0280.
  • If the largest MTU is 1500 then the RIF would be 0810.00A1.0145.0280 where the code for 1500 is 001.
  • If you are in a NetBIOS environment and SRBs are being used then the RIF would be C830.00A1.0145.0280 where the C represents the code 110.
  • If you are in an SNA environment and ARBs are being used then the RIF would be 8830.00A1.0145.0280 where the 8 represents the code 100.
  • If the first ring number is say 1128 instead of 10, then the RIF would be 0830.2681.0145.0280 where the binary for 1128 is 0010 0110 1000 giving the hexadecimal of 268.

10. Remote Source-Route Bridging (RSRB)



Before DLSw, Cisco developed RSRB to transport LLC2 traffic over the IP internetwork. RSRB carries the RIF all the way through the network, supports Automatic Spanning Tree, bridging of many protocols and allows FST between different media.

SRB is limited to Token Ring environments, however, Remote Source Route Bridging (RSRB) allows SRB across non-Token Ring LANs. This can be done by either encapsulating (tunnelling) Token Ring traffic over TCP/IP, by using Fast-Sequenced Transport (FST), or by using MAC layer encapsulation (FDDI, Ethernet or serial lines).

With SRB we used a trick called the virtual ring to allow more than two rings to be bridged together. RSRB extends the virtual ring across non-Token Ring networks such as WANs. The routers participating in the ring must be configured with the same unique virtual ring number. These routers can then encapsulate and de-encapsulate the SRB data flowing between actual rings. The RIF is carried through the network from end to end and is not terminated as in DLSw.

The idea of routers being Remote Peers to each other is used. These remote peers must use the same type of encapsulation to provide the path. Typically this encapsulation is TCP/IP.

The following diagram illustrates an example of the use of RSRB:

RSRB

Consider the following network:

RSRB network

The IP Cloud becomes a Virtual Ring (500) with the routers containing bridges 3 and 4 being configured as RSRB peers. The RSRB encapsulation through the non-bridged network could be TCP, FST or Fast Switched TCP (FTCP). The RIF is maintained throughout the path (unlike DLSw) and so the peers must have the same Virtual Ring number configured. The RIF from Host A to Host B is 100 1 200 2 300 3 500 4 600 0 (the 0 being the last bridge).

RSRB still has the 7 bridge limitation although you can now stretch the Source routed network across a long way.

Enabling local acknowledgement means that the LLC2 sessions are locally terminated at the router rather than 'passed through' the network. The sending host expects to see a response from the receiving host within a period of time called the T1 time. After about 8-10 retries, the session is dropped, hence the importance of locally acknowledging the connection so that if the IP network is a bit slow, data can still be transferred and the sessions can be kept up.

The RSRB session remains closed until the first packet kicks it off.

Generally, TCP is used for encapsulation as it provides reliable transport, however it uses up more bandwidth than direct encapsulation (ideal for point-to-point links) or FST. FST includes the use of sequence numbers and drops packets that arrive out of order, however it does not correct them.

11. Source Route Transparent (SRT) Bridging



If you are in a mixed environment, where both SRB and Transparent bridges co-exist, there may be problems. A Transparent bridge will pass SRB frames, completely ignoring the RIF and thereby running the risk of creating bridging loops, whilst a SRB will drop frames without a RIF and the SRB will not be included within a Spanning Tree. The Source Route Transparent (SRT) Bridge, will source route frames with Routing Information and transparently send frames without the routing information. It is like having both a Source Route Bridge and a Transparent Bridge within the same box. There is no communication between hosts on a source-bridged network and hosts on a transparent bridged network.

SRT bridging is an extension to 802.1d and involves four methods called Route Discovery Protocols to determine the best path between source and destination stations. The All-Route Explorer (ARE) frame travels all the routes between stations and is equivalent to the ARB. The Specifically Routed Frame (SRF) performs the function of the SRB but without the routing information, it is a response to the ARE. The Spanning Tree Explorer (STE) is a single route explorer frame, only one copy of it is allowed on each LAN on the way to it's destination.

Method A - The sender sends AREs to the destination. These frames are forwarded by the SR part of the SRT bridge and pick up routing and frame size information on the way. The destination receives one frame, containing the path it took between stations, for each possible route. The destination then sends a copy of each received frame back to the source for route selection.

Method B - This is the same as above with the addition of a spanning tree frame (having no route information). This is forwarded by the transparent portion of the SRT bridge and uses the spanning tree path to reach the destination. The ARE frame and the transparent frame are then sent back to the source. The transparent spanning tree frame exchange confirms that the target exists on the extended LAN.

Method C - This protocol behaves like the current source routing discovery process. It sends a single frame to the target and target responds with an ARE, which picks up the route information on the way back. The source station receives one ARE for every possible route.

The difference with Source Routing is that the source initially sends a transparent spanning tree packet that travels the spanning tree path (transparent portion of SRT) to the destination, instead of a single route broadcast packet as defined by Source Routing.

Method D - This operates in the same way as Method C but with the addition of a transparent spanning frame in the return with the all-route explorer

The benefits of SRT are only realised in a network where all the bridges use SRT and the end stations have the correct software for the network cards. It does away with the need to have two sets of bridges, one for transparent bridging and one for Source Route bridging.

12. Source-Route Translational Bridging (SR/TLB)



This type of bridge performs a translation between two different bridging domains, a Source Route Bridge and a Transparent Bridge. This type of bridge goes one step further than a standard Translational Bridge. In order for an Ethernet station to communicate with a Token Ring station in a SRB environment, as well as changes such as MTU size and bit reordering, there also has to be added a RIF in order that SRB can take place. The bit reordering is required because MAC addresses are in noncanonical format (MSB first) in Token Ring and canonical format (LSB first) in Ethernet. The MTU size for Token Ring frames has to be reduced to 1518 before the frames can be let loose on the Ethernet network.

To see an example of how a device's address will look differently on Ethernet as opposed to on Token Ring take the Ethernet MAC address 0x0000.0c13.c54e. The following table illustrates the conversion between the two:

Ethernet Hex 00 00 0c 13 c5 4e
Binary 0000 0000 0000 0000 0000 1100 0001 0011 1100 0101 0100 1110
Token Ring Binary 0000 0000 0000 0000 0011 0000 1100 1000 1010 0011 0111 0010
Hex 00 00 30 c8 a3 72

The table is organised such that the top two rows indicate the hexadecimal and then binary for the Ethernet version of the MAC address. The bits and bytes are read in Canonical order i.e. from left to right. Token Ring devices read bytes from left to right but read the bits in each byte from right to left i.e. in Non-canonical order. So going back to the table above and the bottom two rows in yellow, the third row has the bits reversed for each byte for the Token Ring device. The fourth row details the hexadecimal equivalent which is 0x0000.30c8.a372.

In order for this translation to occur, a software bridge is created that looks like another port in the bridge group to the transparent bridging domain and like a source-route bridge to the source-route bridging domain. This software source-route bridge represents the whole of the translational bridging domain. The following diagram illustrates an example:

Source-Route Bridge

The Virtual ring is the ring group 20 sreated by SRB, the Pseudo ring 30 represents the transparent bridging domain as far as SRB is concerned, the Bridge number is Pseudo Bridge 3 that leads to the transparent domain (Pseudo ring 30) from the SRB domain and the Bridge group is the Transparent Bridge group 5 as far as the Transparent Bridging domain is concerned.

Data Link Switching (DLSw) is a way of encapsulating non-routable NetBIOS and SNA traffic within IP. This is considered a much improved alternative to SRB. For information on DLSw and DLSw+ go to the document DLSw.

13. Token Ring VLANs



Because of the deterministic way in which Token Ring works, the busy stations such as file servers and backbone equipment get more use of the token i.e. a hierarchical structure to the network develops. The use of priorities helps to manually control some traffic flows. As Token Ring networks increase in size, extra rings are added via the use of source route bridges, however these bridges cannot keep up with the increase in traffic intensity.

13.1 802.5r


In traditional Token Ring, adapters have to be attached to a concentrator and cannot attach to each other. The adapters operate in half-duplex mode i.e. the frames travel in one direction only, in Token Passing mode.

Modern Token Ring technology allows a Dedicated Token Ring (DTR) connection so that a Token Ring switch port acts like a concentrator port. Instead of using a Token to pass data a new method called Transmit Immediate (TXI) is used which allows the switch and adapter to transmit frames at anytime. This type of connection can provide full duplex giving 32Mb/s for dedicated links to servers.

The following priorities exist for Token Ring using the priority bits:
  • 0 - 3 - set by the user
  • 4 - Bridge transmit priority
  • 5 - non-realtime multimedia (video playback) - NEW!
  • 6 - realtime multimedia (voice) - NEW!
  • 7 - critical MAC frames
Priorities 0 - 4 are placed in the Low Queue, 5 - 6 in the High Queue and 7 in another queue designed for MAC frames.

Using the ISL+ extension in Cisco switches, Token Ring can also use ISL trunking.

13.2 Token Ring Switching


Token Ring Switches provide Source Route Bridging and Source Route Transparent Bridging at far faster speeds than traditional bridges. This is called Source Route Switching (SRS) where forwarding decisions are made based on the RIF but no RIF modification occurs. Token Ring switches can also use Transparent Bridging, however where RIF information is not passed on.

The way rings can be distributed around a large network (similar to an Ethernet VLAN) is by defining port groups that have the same ring number. Such a port group is called a Concentrator Relay Function (CRF). SRS works within the CRF to forward frames based on MAC address or the Route Descriptor. You can connect multiple SRFs by way of the Bridge Relay Function (BRF) which provides SRT or SRB and is seen as a single bridge. With SRB duplicate MAC addresses can be used on different CRFs.

Source Route Switching forwards frames that do not contain RIFs, like Transparent Bridging. It also forwards frames based on the next ring number. If a switch has a number of Token Ring ports each operating source route switching then each port will have the same ring number as the other. The switch learns the MAC addresses of all the adapters on each connected ring plus the Route Descriptors (RD) which is the portion of the RIF indicating a single hop and is made up of the source ring number, bridge number and the destination ring number. Future frames with the same next hop RD are forwarded only to the port with the correct source-route bridge so the switch does not need to learn the MAC addresses of devices on the other side of the source-route bridge. Also, parallel source-route paths can be set up.

If a packet has has a RIF then this is switched onwards without amending the RIF so it does not participate in source routing. In an SNA environment, multiple FEPs have identical MAC addresses on different rings to provide resilience. Source route switching supports this since it does not decide where to route packets based on MAC addresses.

13.3 Switch Examples


A traditional workgroup ring may have even traffic all around as clients have similar needs, however this is often far from the case and as mentioned earlier, there are often quite distinct traffic patterns as perhaps certain users access the servers more frequently. A token ring switch can be introduced that keeps the heavier users on their own ring with their server and other rings separate so that there is less contention for the token. Using Source Route Switching the microsegments can have the same ring number on a per CRF basis.

An enhancement to the above is to have the servers on dedicated DTR links running at full duplex. It is possible to obtain server cards that support ISL trunking (Intel and Olicom make these cards).

The following network has issues with bridge congestion and high backbone utilisation:

Bridge Congestion

An example of a sensible upgrade is illustrated below:

Good bridge practice

Ring numbering can be maintained by implementing SRB or SRS. SRB allows the use of redundant MAC addresses and this would be required if there were more than one FEP for a client to access. This could be the case where there may be two or more backbone rings (each one accessing a different FEP). If this were the case then we would install multiple switch chassis and configure SRB so that forwarding would be based on ring/bridge pairs rather than MAC address as would be the case if we used SRT. Grouping the users into VLANs helps reduce the need for Explorer packets since users that access each other would be located on the same ring. If ISL trunks are used to the servers then no routing would be required. The ISL could run on DTR links but it may be prudent to run ISL on 100BaseT links running at full duplex or perhaps on ATM LANE links running at 155Mb/s.

The mainframe connection could be via a Front End Processor (FEP) or a device such as a Channel Interface Card (CIP) in a Cisco router that allows SNA connection on to a LAN.

If one is migrating from Token Ring to Ethernet there are a number of things to consider. Token Ring has some benefits:
  • Source Routing allows parallel paths for traffic load sharing.
  • Duplicate MAC addresses are allow with SRB so there is SNA automatic backup.
  • SRB provides a specific path via its RIF so this aids in troubleshootng.

Valid HTML 4.01 Transitional




IntroDelta     Earn on the Web    


All rights reserved. All trademarks, logos, and copyrights are property of their respective owners.