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.
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
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:
- The AM broadcasts an Active Monitor Present (AMP) frame.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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)
- 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.
- Ring Poll Participation - The station learns its NAUN address and passes its address
to its nearest active downstream neighbour. This called Neighbour Notification.
- 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:
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.
- 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:
- 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.
- 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.
- Each bridge that receives the frame adds it's routing information to the RIF and forwards
the frame out of its ports.
- 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.
- 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).
- 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.
- The path is copied into every Non-Broadcast (NB) frame destined for the remote station
for that particular session.
- 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:
The client can reach the server through two ways:
- via ring 10, bridge 1, ring 20, bridge 5 and ring 40.
- via ring 10, bridge 10, ring 30, bridge 15 and ring 40.
The way back from the server can happen via two paths:
- via ring 40, bridge 5, ring 20, bridge 1 and ring 10.
- 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:
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:
Consider the following 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:
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:
An example of a sensible upgrade is illustrated below:
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.
|
