Your Guide to High Speed Token Ring Networks

High Speed Token Ring
Your Guide To Token Ring For The 21
st
Century

Page 2 © 1998 Madge Networks Ltd
Table Of Contents
1. Token Ring – The Story So Far .............................................................................1
1.1 Getting the LAN Basics Right ................................ ................................ ............2
1.2 LAN Management ................................ ................................ .............................. 3
1.3 Optimized Packet Size ................................ ................................ ........................3
1.4 Anticipating Voice and Video on the LAN ................................ .........................4
1.5 Source Routing – Getting the Most Out of Bridging ................................ ..........4
1.6 Switching – Taking LANs into the Future ................................ ..........................5
1.7 Point-to-point Links and Full Duplex Operation ................................ ................5
1.8 Ethernet’s Evolution ................................ ................................ ...........................7
2. Anticipating the Demands of the 21st Century.....................................................7
2.1 Applications and LAN Traffic Load ................................ ................................ ...8
2.2 Intranets and LAN Traffic Patterns ................................ ................................ .....8
2.3 Voice and Video and LAN Traffic Characteristics ................................ .............9
3. Enter High Speed Token Ring ...............................................................................9
3.1 The HSTR Standard and the HSTR Alliance ................................ ....................10
3.2 HSTR Technology ................................ ................................ ............................ 10
3.3 The HSTR Product Roadmap ................................ ................................ ...........11
3.4 Meeting the Needs of 21st Century Networks ................................ ..................12
4. Evolution not Revolution......................................................................................15
4.1 The ROPE Fallacy ................................ ................................ ............................ 15
4.2 Life Beyond FDDI ................................ ................................ ............................ 17
4.3 ATM Backbones for Token Ring LANs ................................ ...........................17
4.4 Virtual LANs ................................ ................................ ................................ ....19
4.5 Voice and Video on the LAN ................................ ................................ ...........20
5. Conclusion .............................................................................................................22

© 1998 Madge Networks Ltd Page 1
Executive Summary
This guide is intended for network planners and administrators in Token Ring network installations
who are concerned with LAN evolution strategy. Beginning with an explanation of the special
features and characteristics of Token Ring that originally made it the LAN technology of choice for
large scale, mission-critical networking, the guide goes on to discuss the next steps for evolving
Token Ring LANs. The latest technology initiative in the Token Ring industry -- High Speed Token
Ring -- is described in detail, and this technology is compared with other approaches for dealing with
21st century demands on the LAN. While many Token Ring users feel they are under pressure to
migrate their LANs to Ethernet, it is very difficult to construct a rational financial justification to
carry out such a migration -- particularly now that HSTR offers such an easy upgrade path to 100
Mbps and Gigabit backbone speeds.

1. Token Ring – The Story So Far
Token Ring began its life in the networking labs of IBM around 1982.
In those early days of enterprise data communications, IBM’s networking engineers were by far the
most experienced in the business. After all, they had created the System Network Architecture
(SNA), which totally dominated large enterprise networking at the time, and even today is still the
most widely-used protocol for mainframe-based networking.
It is easy to imagine those IBM engineers studying the first implementations of Ethernet, just
freshly emerged from Xerox labs, the Palo Alto Research Center. And it is easy to see why IBM
chose not to adopt Ethernet as the basis of its enterprise LAN solution, but instead to invent a
completely new technology.
For a start, those IBM engineers would not have been impressed with the variability of Ethernet’s
response time under load. True, 10 Mbps would have seemed a lot of bandwidth by comparison
with typical application requirements at the time. But the fact is, Ethernet’s CSMA/CD access
mechanism suffers increasing delays as load builds up. At around 60-65% loading, almost all of
the 10 Mbps bandwidth is consumed by collisions, throughput falls to virtually zero, and access
time effectively extends to infinity.
If there was one thing that the SNA experience had taught IBM, it was the importance that business
users attached to rapid, consistent and predictable network response times. SNA is excellent in this
respect, and IBM were not about to compromise their network architecture principles by adopting a
LAN technology like Ethernet with such inherently unpredictable response times.
The issue of variable response times was, in itself, probably enough to convince the IBM engineers
that they needed to invent an alternative to Ethernet. But there was a second issue with Ethernet
that would have been a big concern to IBM – the practicality of accommodating a coaxial bus-based
cabling scheme in real office environments. With these two issues uppermost in their minds, IBM
set about devising a new LAN solution that was worthy of its place as part of the System Network
Architecture.
1.1 Getting the LAN Basics Right
The IBM engineers solved the response time problem by devising a mechanism for access to a
shared medium that gave each network node an equal opportunity to transmit on a round-robin
basis. The token-passing access mechanism has three valuable attributes:
• It provides deterministic access to the shared medium. There is an absolute upper limit on the
time that a node has to wait before it can gain access to the medium to transmit data. Users of
the network therefore enjoy guaranteed network response.
• It enables the shared medium to be utilized up to almost 100% of its theoretical capacity, while
maintaining predictable access times for all nodes.
• It provides fair and equal access to all nodes that are sharing the medium, and does not suffer
from the “capture effect” which, in CSMA/CD networks, allows one node to hog the medium,
sending multiple packets one after another and denying access to other nodes.

IBM also solved the cabling problem by devising a star-wired scheme to implement the physical
ring, and by making use of twisted-pair cabling. The result was the first structured cabling solution
for premises data distribution. This approach to cabling was far easier to install and manage than
the “thick coax” bus on which Ethernet was then based.
With these advantages at the time of its introduction, it is easy to see why Token Ring was hailed as
the superior solution to enterprise Local Area Network needs. But this was only the start – there
were many other aspects of Token Ring’s original design which demonstrated convincing built-in
superiority to Ethernet at the time.
1.2 LAN Management
IBM understood that Token Ring networks would need to support mission-critical enterprise
applications, and that high availability and ease of troubleshooting would be priority requirements.
To meet these needs, IBM included in the design of Token Ring a number of management
protocols and mechanisms to improve fault tolerance and make it easier to find problems.
Every Token Ring node is capable of identifying error conditions on the ring and reporting these
errors to a management station. Furthermore, Token Ring’s management protocols enable a
management station to build a map of the network showing the addresses of all the nodes in order
around the ring.
Intelligent hubs in Token Ring networks take advantage of these management protocols to find and
isolate faults automatically. Management console applications also use these protocols to help
network administrators find and fix problems.
Ethernet has no equivalent to Token Ring’s management protocols. Network administrators who
work with both technologies invariably report that Token Ring is both more reliable and easier to
trouble-shoot.
1.3 Optimized Packet Size
IBM’s experience with SNA had taught it the lesson that considerable computing power is
necessary for the processing of networking protocols in end stations, and that the amount of
computing power needed is a function largely of the number of packets per second that are being
sent or received, not the total data throughput. The use of larger packets minimizes the amount of
processor cycles that are consumed by handling network protocols, leaving the system with more
power to deal with the data processing tasks.
Furthermore, IBM had found that using larger packet sizes resulted in greater overall network
throughput.
As a result, IBM chose a maximum packet size for Token Ring that was considerably larger than
that used by Ethernet: 4550 bytes compared with 1518 bytes for Ethernet. This decision means that
Token Ring networks can deliver greater throughput with less usage of end system resources than
equivalent Ethernet networks. (Note that the 4550 byte limit applies to 4 Mbps Token Ring, while
16 Mbps can actually support a maximum packet size of 18200 bytes. However, the vast majority
of Token Ring installations work within the 4550 byte limit because this is the maximum permitted
by many widely-used software packages).

As networks scale up in speed to the Gigabit/second range, this decision by IBM will prove to be
especially valuable. Early experiments with Gigabit Ethernet have demonstrated that the 1518 byte
maximum packet size severely limits the ability of even the most powerful end systems to use the
full capacity of a Gigabit network. Gigabit Token Ring – of which more later – will suffer much
less from this problem.
1.4 Anticipating Voice and Video on the LAN
IBM engineers were far ahead of their time in predicting that LANs would eventually carry time-
sensitive voice and video streams as well as bursty data transmissions. To accommodate this, they
devised a sophisticated enhancement to the round-robin token-passing scheme that enabled stations
with high priority time-sensitive traffic to pre-empt other stations waiting to send data on the ring.
The eight-level priority scheme was engineered into the Token Ring specification from day one,
and all Token Ring products that comply with the IEEE 802.5 standard support it, although to date
few applications make use of it.
Almost 15 years after IBM devised this priority scheme, the first applications that can really benefit
from it are beginning to roll out on enterprise LANs. Video and multimedia conferencing and
LAN-based telephony will soon be making very effective use of the Token Ring priority scheme, in
a manner that is fully compatible with the entire installed base of Token Ring equipment.
Recognizing the necessity for a priority scheme to support real-time conferencing and telephony
applications, those responsible for the Ethernet standards have recently been working on a new
standard, IEEE 802.1p, which defines the addition of priority information to the Ethernet packet
format. But the priority tag can only be recognized by new generations of Ethernet equipment,
requiring forklift upgrades to existing Ethernet installations.
Token Ring may have been well ahead of its time in supporting multiple levels of access priority,
but those responsible for deploying LAN-based videoconferencing and telephony applications on
Token Ring networks have good reason to be grateful for the foresight of the original engineers. In
this area at least, Ethernet is scrambling to catch up.
1.5 Source Routing – Getting the Most Out of Bridging
There are practical limits to the number of nodes that can be connected to any LAN segment based
on shared media, and both Token Ring and Ethernet solved the LAN interconnection problem with
bridge devices that forward or filter packets between LAN segments according to destination
addressing information.
In devising the Token Ring bridging solution, the engineers placed the emphasis firmly on fault
tolerance and efficient use of network resources. This led them to invent source routing, which
involves a little extra intelligence in each end station that finds multiple possible routes through a
bridged network and selects the best one. In the event of a failure that renders the chosen route
inoperable, the end station establishes an alternative route.
The recommended architecture for mission-critical bridged Token Ring networks involves a dual
redundant backbone, with each workgroup ring bridged to both backbones. While everything is
operating normally, load is shared between the two backbones thereby providing additional network
capacity. In the event of a bridge or backbone failure, end stations that are affected find a new path
to the resources they need through other bridges – without interrupting end user activity.
By contrast, the Ethernet solution emphasized simplicity. The transparent bridging approach avoids
the need for any additional intelligence in end stations, but is severely compromised in its fault
tolerance capabilities as a result.

Where a transparent bridged network provides multiple paths between any two points, a complex
protocol known as the “Spanning Tree Algorithm” (STA) is required to shut down one or more
bridges so as to avoid packets circulating endlessly on looped paths. Protection against bridge
failure is possible, but STA takes a long time to reconfigure the network when a fault occurs and
users may see minutes of downtime. Furthermore, there is no possibility of load-sharing between
multiple paths through the network. This means that some parts of the network are overworked
while others stand idle, to be brought into use only when there is a fault condition.
1.6 Switching – Taking LANs into the Future
Difficulties with Ethernet’s transparent bridging scheme convinced many Ethernet users to migrate
to large collapsed backbone routers at the core of their LANs. With the fault tolerance and load
sharing provided by source routing bridges, Token Ring users have not been so convinced that this
move is necessary. But for both Ethernet and Token Ring users, one common theme has emerged
as the way forward in the LAN – switching.
LAN switching has provided a low cost, high performance solution to the problem of
interconnecting many LAN segments. Furthermore, LAN switching provides an efficient method
for interconnecting LAN segments of the same technology but running at different speeds; for
example, Ethernet at 10 and 100 Mbps, or Token Ring at 4 and 16 Mbps. Offering higher
performance at lower cost than collapsed backbone routers, and being much easier to install,
configure and manage, LAN switches are now by far the fastest growing segment of the LAN
equipment market.
But LAN switches are, in reality, nothing more than fast multi-port bridges. In a LAN switching
environment, exactly the same issues of fault tolerance and load-sharing crop up as we see in a
bridged environment. Eliminating single points of failure in a switched Ethernet network means
relying on the Spanning Tree Algorithm with all its implications of long recovery times and under-
utilized equipment. By contrast, using source routing with switched Token Ring enables us to build
fully redundant networks that share load between switches under normal operating conditions, and
recover faults so fast that users don’t notice anything has happened.
The ability of source routing to support load sharing has a further benefit to switched Token Ring
users. If a Token Ring link between two switches is becoming overloaded, a second link can be
installed in parallel with it, and source routing will ensure that load is shared equally between the
two links. This enables capacity to be scaled very easily in a switched Token Ring network, based
on the standard operation of source routing that is supported by all Token Ring equipment. To
achieve this kind of scalability in an Ethernet network involves proprietary schemes for load-
sharing on parallel links between switches. These schemes are not part of any standard and won’t
work in multi-vendor environments.
1.7 Point-to-point Links and Full Duplex Operation
As server resources become more and more heavily loaded, it becomes necessary to find ways to
increase server access capacity. One of the easiest ways to do this is to move servers off shared
LAN segments and connect them directly to dedicated ports on LAN
switches. Then the entire bandwidth of a LAN switch port – for example, 16 Mbps for Token Ring
– can be dedicated to a single system attached to the port.
But connecting servers directly to switch ports can provide an additional capacity boost.
With a point-to-point connection between switch port and server, we don’t need to treat

the transmission medium as shared any more. Instead, we can use the connection as a
full-duplex or bi-directional point-to-point data link. By doing this, we can transmit data
in both directions over the link at the same time. When multiple workstations are
accessing the same server, the server can be sending data to one workstation while
simultaneously receiving data or acknowledgements from another. The actual
improvement in overall throughput that can be achieved with full duplex operation
depends on the relative amounts of traffic in each direction. If traffic flow were
symmetrical then throughput would be doubled, but in real environments the
improvement would be somewhat less than this.
Both Ethernet and Token Ring define standards for full duplex operation, which is
intended for both switch-to-switch and switch-to-end-system connections. But here the
similarity ends, because standard Ethernet hardware is not capable of full duplex
operation whereas most Token Ring hardware is.
When Token Ring servers are moved from shared rings and connected direct to switch
ports, a simple software driver update for the Token Ring adapter is all that is required in
most cases to support full duplex operation. Ethernet users, by contrast, must install a
new adapter in the server to benefit from full duplex.
Figure 1: Token Ring network with switched backbone

1.8 Ethernet’s Evolution
In this introductory section, we have discussed some of the key differences between the original
Token Ring and Ethernet specifications, and some of the key areas in which Token Ring is clearly
superior.
Ethernet technology has, of course, come a long way since the introduction of those first generation
products. The arrival of the 10BaseT specification enabled Ethernet to run over twisted pair cabling
from desktops to hubs located in wiring closets, neatly addressing the cabling issue. Then came
Ethernet switching, which has now evolved to the point where it is economical to connect each
desktop to a dedicated switched 10 Mbps port. Fast Ethernet brought a ten-fold increase in the
capacity of Ethernet connections. And now the standards for Gigabit Ethernet, with a further ten-
fold speed increase, are imminent.
• Many industry observers have claimed that the emergence of economical solutions for switched
Ethernet to the desktop nullify the main advantage of Token Ring – its deterministic response
time. While this statement may have some basis in truth, it ignores three other key advantages
of Token Ring, namely:
• Source routing continues to provide the basis for highly fault tolerant LAN architectures, which
support load sharing over multiple paths through the network. There is no equivalent means of
matching this capability in Ethernet LANs, whether shared or switched.
• The larger packet sizes supported by Token Ring continue to provide better efficiency and
greater data throughput for real networked applications. Ethernet’s packet size limitations are
becoming a key performance issue as networks scale to Gigabit speeds.
• Token Ring’s built-in priority scheme, which is supported by the entire installed base of Token
Ring equipment, provides a very effective basis for the Quality of Service that will be needed
for the integration of voice and video services over the LAN infrastructure. Ethernet will need
a new frame format to handle priority tagging, and will consequently require a forklift upgrade
to those parts of the LAN that must support Quality of Service.
• Many “experts” in the LAN industry would brush off these arguments, and claim simply that
Ethernet has won the battle for the desktop. But those who currently have Token Ring installed
in their networks (and there are 20 million desktops connected by Token Ring today) know that
such black-and-white views have little relevance to the harsh reality of day-to-day LAN
operations. Token Ring’s advantages are real and they deliver measurable benefits in the
enterprise LAN environment. And as we will see, Token Ring technology continues to evolve
to meet the emerging needs of the most demanding LAN users.

2. Anticipating the Demands of the 21st Century
In the world of networked applications, foreseeing the future is tough to do. When, a couple years
ago, browsers and the World Wide Web first made the Internet accessible and useful to both home
and business users, who could have guessed that we would be writing Web-based front ends for
mainframe applications today? And who could have anticipated the huge impact of intranet traffic
on the enterprise LAN?
Despite the uncertainties of the future, there are some things that we can foresee. We may not be
able to guess the details of the next few generations of networked applications, but we can at least
identify some mega-trends that will clearly impact on LAN evolution planning.
2.1 Applications and LAN Traffic Load
There seems to be an immutable law of data networking that each new generation of applications
applies a greater level of loading to the network.
First generation networking was based on dumb terminals connected to mainframes. Concise
screen formatting commands and fixed 80 x 24 character displays made for very economical usage
of data communications resources.
But today’s PC-based office productivity software, client/server applications, email, networked
printers, document imaging and intranet web-based applications, all involve data transfers across
the LAN that are many orders of magnitude greater than those needed for dumb terminals.
Each successive generation of software seems to generate larger and larger application files. For
example, a completely blank Microsoft Word 97 document file occupies more than 19,000 bytes. If
diagrams or pictures are included in a 20 or 30 page document, then the file size can stretch to a
megabyte or more. As the usability of the software improves, and as more and more computer-
literate staff enter the workforce, so more and more information-rich documents are created, printed,
stored on servers and sent by email – all consuming more and more network resources.
2.2 Intranets and LAN Traffic Patterns
The pattern of traffic flows in a LAN is determined by the relative locations of the information
consumers and information sources in the network. Most early LAN deployments supported
departmental applications with local servers, so most traffic was local to the workgroup. Traffic
across the LAN backbone between workgroups, or from workgroups to central mainframe systems,
was relatively light.
This situation has changed dramatically in the last few years, as more and more server functions are
moved to central locations in the LAN. Centralizing server resources reduces support issues, makes
it easier to provide a suitable physical environment for mission-critical systems, and lowers cost by
employing fewer, larger machines.
But moving servers to the core of the LAN brings a great deal more traffic onto the LAN backbone,
and this has been a major factor driving the need for LAN backbone upgrades. Faster LAN
technologies and LAN switching have both played a valuable role in addressing this need.

The latest trend to impact on LAN traffic patterns is the roll-out of corporate web-based
applications, which use technology developed for the Internet to disseminate information within the
enterprise. The browser paradigm makes it far easier for desktop users to locate and access a wide
range of information from a wide variety of different sources within the enterprise. Furthermore,
the ability of the browser to display pictures, graphics and even video has encouraged providers of
content on the corporate intranet to make generous use of these rich information types – with a
corresponding increase in LAN traffic loading.
As new sources of information appear on the corporate intranet, and users hop from one web site to
another with the click of a hyperlink, so traffic patterns on the LAN will change rapidly and
unpredictably. No longer can network administrators expect to plan LAN capacity growth in an
orderly manner based on steady trends – in the future, generous over-provisioning will be required
to cope with unforeseen and unpredictable shifts in loading.
2.3 Voice and Video and LAN Traffic Characteristics
Today, very few LANs carry real-time voice and video traffic. Telephony is handled by the PBX,
and videoconferencing takes place mostly in dedicated rooms served by ISDN lines.
All this is about to change. The latest generation of PCs has the processing power to support video
compression and decompression in software, and no longer requires add-in video codec cards.
These PCs also provide a new kind of Input/Output port, the Universal Serial Bus, and low cost
video cameras are now shipping that plug directly into the USB. And there is finally a standard for
desktop videoconferencing over IP-based networks (H.323) which allows for multivendor
deployment of videoconferencing to the desktop.
With high quality desktop videoconferencing over any LAN that supports IP available for a couple
of hundred dollars per desktop (and falling), we can expect to see a dramatic upturn in the
deployment of video at the desktop. The use of PC-base videoconferencing to participate in remote
business meetings and collaborative work will become routine. And with it, a huge amount of
additional traffic will start hitting the LAN.
Real-time video presents a double challenge to the LAN administrator. First, videoconferencing
consumes a substantial amount of LAN bandwidth – an absolute minimum of 175 kbps each way –
for the entire duration of the video session. And secondly, video can’t tolerate the kinds of
transmission delays that are typically seen in the LAN at times when it is heavily loaded.
Congestion points in the LAN lead directly to picture break-up and unacceptable loss of
interactivity in desktop videoconferencing sessions.
The short term solution for videoconferencing on the LAN is massive over-provision of bandwidth
and switching capacity, to eliminate traffic congestion. But this approach does not work for long
because LAN traffic has an annoying tendency to grow so as to occupy all the available capacity.
The only viable solution for the long term is to treat real-time video traffic differently from data
traffic in the LAN, by enhancing the LAN to provide Quality of Service. And the easiest way to do
this is to recognize multiple levels of packet priority in the LAN – of which more later.
3. Enter High Speed Token Ring
Today’s 16 Mbps speed limitation is beginning to cause some concern in many Token Ring
installations. So far, Token Ring switching has done a great job in addressing congestion issues on

shared rings, particularly in the backbone. Switching allows server rings to be micro-segmented,
and it also supports dedicated full-duplex 16 Mbps server-to-switch connections. But in networks
that use multiple switches, 16 Mbps may not be sufficient for inter-switch links. And the latest
generation of server machines are capable of driving far more than 16 Mbps of I/O bandwidth.
Today’s Token Ring products can deliver a variety of solutions to these problems. For example, we
can install multiple parallel 16 Mbps connections between switches and take advantage of source
routing to share load between these links. And we can install multiple 16 Mbps adapter cards in
servers to increase I/O capacity.
But these approaches are limited in their scalability, which is why some Token Ring shops have
looked towards higher speed LAN backbone technologies such as ATM to provide a longer term
solution.
Now Token Ring users can look forward to another option: High Speed Token Ring. The purpose
of HSTR is to provide a native Token Ring solution for switched backbone and workgroup
requirements that scales to 100 Mbps and 1 Gbps link speeds. HSTR preserves all of the key
advantages of native Token Ring, based on source routing, large packet sizes and support for
priority tagging, and offers the same scalability of transmission speed as Ethernet. For Token Ring
users who need more bandwidth in the backbone, the server farm or the workgroup, HSTR delivers
a simple, cost-effective incremental upgrade that fits right in with the existing network architecture
and requires no new technology learning or support skills.
3.1 The HSTR Standard and the HSTR Alliance
Token Ring standards are defined by the IEEE 802.5 project, which has embraced HSTR and is
working to publish the first HSTR standards in mid-1998.
The concept of HSTR has been promoted by a group of vendors that came together in August 1997
to form the High Speed Token Ring Alliance. All the leading vendors of Token Ring equipment
and solutions including (in alphabetical order) 3Com, Bay Networks, Cisco, IBM, Madge and
Olicom, are members of the HSTRA and are actively supporting the development of the standards.
Recognizing the urgency of the need for HSTR, the IEEE 802.5 committee and the HSTR Alliance
have set very ambitious timescales both for the completion of the HSTR standard and for the first
public demonstrations of HSTR interoperability.
The 802.5 committee is working on three standards. First is a specification for 100 Mbps HSTR
over copper cables. Recognizing the amount of Shielded Twisted Pair (STP) or IBM Type 1
cabling in the Token Ring installed base, the 802.5 committee is setting out to create a standard that
is compatible with both STP and Category 5 UTP.
Following closely behind the 100 Mbps HSTR over copper standard will be a similar specification
for 100 Mbps HSTR over fiber cables. The target for both of these specifications is June or July
1998.
Meanwhile, work is proceeding in parallel on a specification for 1 Gbps HSTR over fiber cabling.
This standard is likely to be complete by the end of 1998.
3.2 HSTR Technology
In designing the technology behind HSTR, the Alliance began with the following principles:

• Native Token Ring frame formats should be preserved throughout. This allows for the simplest
and most cost-effective switched connections between 4 and 16 Mbps Token Ring and HSTR,
by eliminating any frame format translations.
• All Token Ring’s native bridging and switching modes should be handled. Support for source
routing, transparent and SRT bridging and switching modes allows for a seamless extension of
the Token Ring environment to higher speeds.
• The HSTR specifications should be based as far as possible on existing standards in order to
minimize time to market. At the Physical layer, the 100 Mbps and 1 Gbps transmission
schemes developed for Fast and Gigabit Ethernet are being adapted to support HSTR, while at
the Data Link and Media Access Control layers, the existing 802.5r standard for Dedicated
Token Ring with Full Duplex Operation provides the basis for HSTR.
• HSTR should support all the widely-used cable types that are capable of handling 100 Mbps
and 1 Gbps transmission. At 100 Mbps, both STP Type 1 and UTP Cat 5 will be supported
with lobe lengths up to 100 meters. Multimode fiber will also be supported. At 1 Gbps, HSTR
will provide the same cable compatibility as Gigabit Ethernet over multimode and single mode
fiber cables. The subject of Gigabit transmission over copper cables is still being studied.
• Special features of Token Ring that provide additional robustness and fault tolerance will be
supported in HSTR. For example, the lobe test that Token Ring nodes perform to prove cable
integrity before they insert is preserved in HSTR.
• HSTR should provide a solution for dedicated point-to-point links in a switched Token Ring
environment, and should not set out to address shared media implementations. Creating a
shared media solution for HSTR would delay the standard by many months or even years, and
the cost of switching has fallen to the point where there is no economic justification for a
shared media implementation.
• HSTR will be compatible with the emerging IEEE 802.1Q standard for Virtual LAN tagging.
Where Virtual LANs are being used, this standard defines the tags that need to be inserted in
each packet on inter-switch links to identify which VLAN they belong to. The 802.1Q
specification also defines a standard way to carry Ethernet packets over HSTR links, and this is
expected to assist in situations where Ethernet workgroups need to be integrated in a
predominantly Token Ring environment.
Members of the HSTR Alliance found these principles easy to agree on, and there has been very
little debate necessary to settle the technical details of the HSTR specifications. Because of this,
and because HSTR is based on a judicial combination of pre-existing standards, the time taken from
initial project approval to publication of the first HSTR specification is expected to the be the fastest
in the history of the IEEE 802 standards.
3.3 The HSTR Product Roadmap
The vendor members of the HSTR Alliance have committed to undertake public interoperability
demonstrations of HSTR commencing in mid-1998. The first such demonstrations are expected to
take place at Networld+Interop in Las Vegas, May 4th-8th 1998.
The first HSTR products to hit the market in the second half of 1998 will address the need for high
speed inter-switch links and switch-to-server connections. Thus we can expect to see 100 Mbps
HSTR switch cards for Token Ring backbone switches that provide both fiber and copper
connections, and also 4/16/100 Mbps server adapter cards.

The next step is likely to be the deployment of lower cost Token Ring switches in the workgroup.
These switches will need 100 Mbps HSTR uplinks from wiring closet to backbone in order to
deliver more bandwidth to the workgroup.
Continuing growth of demand for bandwidth in the backbone will lead to the development of much
larger scale Token Ring switching systems offering multi-Gigabit switching fabrics. Such switches
are likely to offer Gigabit HSTR cards as options so as to provide another step up in backbone
scalability.
Finally, it may be necessary in the future to handle some very demanding applications at the
desktop which require more than dedicated 16 Mbps connections. These desktops will be served by
a new generation of 100 Mbps HSTR workgroup switches, with Gigabit HSTR uplinks into the
backbone and perhaps also Gigabit connections into servers.
3.4 Meeting the Needs of 21st Century Networks
Token Ring users who are planning for LAN evolution over the next 3-5 years should be evaluating
their strategies under the following eight headings:
• Scalability
• Fault tolerance
• Performance
• Manageability
• Compatibility
• Simplicity
• Ethernet co-existence
• Cost of ownership
For existing Token Ring shops, HSTR scores very highly under all these headings. Many
alternative approaches are, by comparison, weak in several areas.
Scalability. HSTR scales to 100 Mbps and 1 Gbps speeds. This provides ample capacity to handle
total traffic growth way beyond the 3-5 year horizon.
Fault tolerance. HSTR supports all of the fault tolerance capabilities that are characteristic of
native Token Ring. In particular, HSTR allows the source routing environment to be extended to
100 Mbps and 1 Gbps backbones, enabling fully redundant switching configurations to be created,
with load-sharing across all available switching capacity. HSTR with source routing also supports
multiple duplicate Locally Administered Addresses for front-end processors, so as to provide fault
tolerance and load-sharing across FEPs for SNA-based mainframe traffic.
Performance. HSTR supports all native Token Ring packet sizes. Most Token Ring networks use
packets up to 4500 bytes, around three times the size of the maximum Ethernet packet. Larger
packets mean both greater transmission efficiency and lower end station overhead. And as
transmission speed increases, larger packets provide even greater performance benefits.
Manageability. HSTR preserves all the MAC-level management functions of full-duplex Token
Ring and supports all the familiar Token Ring management tools.
Compatibility. HSTR is compatible with all protocol types that run in the native Token Ring
environment, and supports the full range of Token Ring packet sizes. The implementation of HSTR
in an existing Token Ring network requires no changes of any kind in the application or networking
protocol environment.

Simplicity. HSTR is simply a faster version of full-duplex Token Ring. No new knowledge is
required to implement, configure, support or troubleshoot HSTR in an existing Token Ring
network.
Ethernet co-existence. Many Token Ring installations also include some workgroups based on
Ethernet. With support for 802.1Q tagging, HSTR links can handle the transmission of both Token
Ring and Ethernet traffic. While not all HSTR products will support Ethernet connectivity via
802.1Q, those that do will provide an excellent solution for the integrated backbone, imposing no
compromises on either Token Ring or Ethernet environments at the desktop.
Cost of ownership. Of all the possible approaches for providing greater network capacity in a
switched Token Ring environment, HSTR is by far the most cost-effective. The cost of HSTR
interface technology is only a modest delta above that of 16 Mbps Token Ring, and all that is
needed to implement HSTR for inter-switch links is an additional line card in the switches at each
end. The new 4/16/100 Mbps server adapters will provide both investment protection and the
simplest possible path to high speed server connectivity.
The real test of HSTR is how it bears comparison with alternative high-speed solutions for Token
Ring networks. On each of these criteria, HSTR is at least as good as, and in most respects better
than, all of the alternatives. FDDI, ATM and router-based Fast Ethernet backbones all have
important shortcomings – of which more later.

Figure 2: Fault tolerant Token Ring network with HSTR backbone

4. Evolution not Revolution
Most large LAN installations have been established over a period of years to support the business of
the enterprise, and most corporate desktops are now LAN-connected. LANs are still growing, but
no longer at a dramatic rate. Technologies employed in the LAN are, by and large, well
understood, and future changes are expected to be driven by business requirements and be
evolutionary, rather than revolutionary, in nature.
The capital investment in LAN infrastructure may be very considerable, but rarely has this
investment been considered “strategic”. LANs evolve incrementally, and each increment tends to
be driven by the roll-out of some specific service or application that supports the business.
Nevertheless, there are some decisions that face LAN planners that must be viewed as strategic. For
example, the decision whether to adopt ATM in the LAN backbone.
One of the most important strategic decisions facing planners in Token Ring environments concerns
the adoption of Ethernet.
4.1 The ROPE Fallacy
LAN planners in many Token Ring shops are besieged by opinions from vendors, industry analysts,
trade publications and the “30-minute experts” within their own organizations to
• Rip
• Out Token Ring, and
• Put in
• Ethernet.
Ethernet just seems like the obvious thing to do. It’s cheaper, it’s more widely available, the
technology seems to evolve more rapidly than Token Ring, and everybody else seems to be using
it. So what are you waiting for?
If you have a totally new building to equip today, and you are starting with a clean sheet of paper
on the LAN design, it would be tough to argue that you should put in Token Ring and not Ethernet.
But if you have 5,000 nodes of Token Ring already installed, and this LAN is serving the current
needs of the enterprise, should you really rip this out and put in something else?
Many organizations that use Token Ring today have taken a strategic decision to move to Ethernet.
This decision is generally motivated by a belief that such a move will save money. For new
installations, Ethernet will certainly cost less than Token Ring. But for an existing Token Ring
installation, it is very tough to see how you can make the move to Ethernet and save money at the
same time.
Before you can move a single desktop to Ethernet, you have first to prepare both network and
processor environment for Ethernet compatibility. For example, Ethernet doesn’t support SNA
traffic, so you will have to install TCP/IP support on the mainframe and provide Ethernet
connectivity to it. This may require a substantial investment up front.
Having cleared the first obstacle, the next step may be to plan Ethernet connectivity for new
desktop systems. It is not economical to throw away PCs before they are fully depreciated, but
when a new PC comes in you can mandate that it will have an Ethernet NIC installed. Then you
have to make sure that you have Ethernet connectivity available in the wiring closet which serves
that desktop.

Trouble is, the PCs in any given workgroup don’t conveniently come up for replacement all at the
same time. PCs of different ages tend to be scattered all over the building. This means that you
have to put Ethernet hubs or switches in a number of wiring closets just to support the few new PCs
that need Ethernet connectivity. Utilization of these resources will initially be very low, and will
build up quite slowly over the 3-5 year depreciation period of the PCs. So a major investment in
new infrastructure must be made way in advance of when it is going to be effectively used.
Ethernet hubs or switches in the wiring closet must, of course, be supported by upstream
infrastructure – and here it is easy to underestimate the cost of delivering functionality equivalent to
that of the Token Ring network. Token Ring’s source routing capabilities support fully redundant
fault-tolerant networking with highly cost effective switching devices. No such equivalent
capability is provided by Ethernet, and obtaining the same degree of fault tolerance requires that
workgroup switches be connected to collapsed backbone routers, typically with Fast Ethernet links.
This is another major investment – and again, it will be very under-utilized for the first couple of
years of the migration.
Next there is the question of performance. While Ethernet may perform adequately for most
business applications, users will be accustomed to the performance characteristics of Token Ring.
In networks that are not heavily congested (which is true of most Token Ring LANs), the larger
packet size and 16 Mbps wire speed of Token Ring delivers appreciably better throughput and
faster response times than Ethernet – even when switched Ethernet is used to deliver dedicated 10
Mbps to each desktop. So expect some complaints about performance when you move people off
Token Ring.
Figure 3 below shows how the throughput of a file transfer session on 16 Mbps Token Ring varies
with packet size. When the packet size is reduced from 4000 bytes to 1500 bytes, throughput drops
from 1300 Kbytes/sec to 880 Kbytes/sec. When we take into account the difference in wire speed
between 16 Mbps Token Ring and 10 Mbps Ethernet, we can predict that throughput on Ethernet
will be around 550 Kbytes/sec in this configuration, or almost 60% lower than we get with 16 Mbps
Token Ring and 4000 byte packets.
0
200
400
600
800
1000
1200
1400
1600
0 1000 2000 3000 4000
Packet Size (Bytes)
TransferRate(KB/s)
1500 bytes
880 KBytes/sec
1300 KBytes/sec
4000 bytes
Figure 3: Typical relationship between packet size and workstation data throughput
(Win 95, 16 Mbps Token Ring, Perform3 test)

And finally, there is the issue of support costs. Most LANs today run with very lean support staffs.
They can only do this because the LAN environment is pretty stable and the technologies that are in
place are well understood by the people who have to support them. Migrating to Ethernet places a
tremendous additional load on the support people. Introducing a new technology into a hitherto
stable environment is bound to drive up the number of support calls. The support staff have to
learn about the new technology and how to configure and manage new products. They have to
wrestle with new network management applications and get to grips with new diagnostic tools and
new management techniques. All this does not make for good control of support costs. On the
contrary, those who are making the migration to Ethernet need to plan for substantial additional
investment in the support area.
LAN planners who are used to working with Token Ring often feel like an oppressed minority,
surrounded by those who insist that moving to Ethernet is the right thing to do. But the reality of
planning such a move is painful, the investment is very substantial, and the payback is often
unclear. In fact, most Token Ring shops that have undertaken a detailed project payback analysis
have come to the conclusion that the “strategic” decision to migrate an existing Token Ring
installation to Ethernet cannot be justified in financial terms.
4.2. Life Beyond FDDI
Token Ring switch products first came to market in 1994, early enough to provide backbone
congestion relief for the majority of Token Ring installations. But some of the larger and more
demanding Token Ring shops had to deal with congestion problems prior to this, and chose the
only viable high speed backbone technology at the time: FDDI.
Initially, FDDI was deployed as a means of linking together large routers, each of which was
equipped with multiple Token Ring port cards. As Token Ring switches with FDDI uplink
capabilities began to appear, so these products offered a more cost-effective means for
interconnecting Token Ring with FDDI.
For Token Ring users, FDDI has the advantages of supporting 4500 byte frames, and (in some
implementations) source routing. FDDI also makes use of a highly fault tolerant dual-reconfiguring
ring topology, which has strong appeal in mission-critical backbone environments.
Today, though, there is very little new investment in FDDI, and cost is a major factor here.
Volumes of FDDI shipments never grew enough to drive costs down, and the technology is
inherently expensive. FDDI’s frame format is not identical to Token Ring, and there are complex
frame format translations to perform when the two technologies are interconnected, which drives up
cost further. But perhaps the most telling factor against FDDI is that it does not scale beyond 100
Mbps.
Network planners who have FDDI in their Token Ring networks today should be planning a
migration strategy which protects their existing investment in FDDI but enables further network
enhancements to be made with alternative technologies. Token Ring switches that accommodate
both FDDI and other interface technologies such as ATM and HSTR provide the means to
accomplish this.

4.3 ATM Backbones for Token Ring LANs
ATM is a very high performance switched network technology that lends itself well to LAN
backbones where the ultimate in performance, scalability and fault tolerance is required.
Connectivity between Token Ring and ATM is accomplished by means of the ATM Forum
standard for LAN Emulation over ATM (LANE). This technology accommodates all of the native
characteristics of Token Ring, including large packet sizes and source routing. As a result, ATM
backbones can be introduced into Token Ring LANs without the need to make any changes in the
application or network protocol environment.
Three new networking elements are required to implement an ATM backbone for a Token Ring
LAN.
First, Token Ring switches must be fitted with ATM uplink cards. A Token Ring switch with an
ATM uplink card can connect a number of rings into an ATM backbone, typically with an uplink
speed of 155 Mbps running over multimode fiber cabling. The ATM uplink card contains all the
logic needed to perform Token Ring to ATM connectivity.
Next, one or more ATM switches are required. ATM switches intended for LAN backbone
applications may have from 4 to 60 ports, with most ports operating at 155 Mbps. Higher speed
ports running at 622 Mbps are also available. The software services that are needed to configure,
manage and run LAN Emulation over ATM are typically located in the ATM switch.
And finally, ATM adapter cards are required if servers are to be connected directly to the ATM
backbone. Again, the most widely used connection speed is 155 Mbps, and the connection from
server adapter card to ATM switch may be via copper or fiber cabling.
Despite the apparent complexity of ATM technology, the installation and configuration of an ATM
backbone for a Token Ring LAN is really quite easy. Nevertheless, introducing ATM represents a
substantial investment both in capital equipment and in the acquisition of new knowledge and skills
that will be essential to successful day-to-day network operation and troubleshooting.
Until the introduction of HSTR, ATM was seen as the only viable way forward for large-scale
Token Ring LANs seeking long-term congestion relief in the backbone. In medium to large Token
Ring installations where the case for implementing ATM is marginal, HSTR now offers an
alternative approach which may well make it unnecessary to consider ATM further. And in Token
Ring networks where ATM is already installed or committed as a LAN backbone, HSTR can
provide a more cost-effective means of extending the high speed environment to workgroups or
server farms.

Figure 4: Token Ring network with ATM backbone

4.4 Virtual LANs
In some situations it can be useful to divide the Token Ring LAN into a number of
separate broadcast domains or “Virtual LANs” which are defined logically, rather than
physically, and to use routers to move traffic from one VLAN to another. Typically,
VLANs are defined by assigning each switch port to a particular VLAN identity. Traffic
arriving at that port from end stations is deemed to belong to the VLAN associated with
that port.
For a VLAN solution to be useful, it should be possible to assign ports on multiple
different Token Ring switches to the same VLAN. The key property of a VLAN is that a
broadcast or multicast packet originating within a given VLAN must only be delivered to
switch ports that belong to the same VLAN. So, whether we are using conventional 16
Mbps or High Speed Token Ring connections between switches, it becomes necessary to
mark each packet with its VLAN affiliation so that we know which switch ports this
packet may be delivered to.
Where source routing is used, the originating ring number in the source routing
information field of each packet is sufficient to identify the packet’s VLAN affiliation,
and we don’t need to do anything new or special. But packets that are being
transparently switched don’t contain any information from which we can deduce VLAN
information. To solve this problem (for both Ethernet and Token Ring networks) the
IEEE 802.1Q working group are defining a packet tagging scheme the enables VLAN
information to be associated with each packet.
The emerging 802.1Q standard is fully compatible with High Speed Token Ring, and will
enable VLAN-tagged packets to be carried between Token Ring switches. Thus 802.1Q
provides a standards-based solution for implementing VLANs across multiple switches in
a transparently-switched environment.
4.5 Voice and Video on the LAN
For the vast majority of Token Ring installations, the integration of voice and video on
the LAN is not yet an issue. However, it may become an issue within the planning
horizon for LAN infrastructure.
The conventional wisdom regarding voice and video integration has been that ATM is the
only technology which has the Quality of Service characteristics necessary to deliver real-
time traffic streams with consistent low delay.
However, while ATM undoubtedly does provide an excellent solution for integrating
voice and video on the LAN if ATM is used end-to-end, the fact is that ATM is not being
adopted at the desktop. A substantial proportion of large LAN installations are
introducing ATM in the backbone, but most desktops will continue to be served by
Ethernet or Token Ring.
If ATM is installed in the backbone, the solution for integrating voice and video in the
LAN must deal with a mix of technologies: switched or shared frame-based connections
at the desktop, and cell-based ATM connections in the backbone.

Unfortunately, the techniques for providing Quality of Service in the frame-based world
are different in many important details from those implemented in ATM. Voice and
video applications running at the desktop will request Quality of Service for real-time IP
packet streams using the Resource ReSerVation Protocol, and will send these packets
over the LAN tagged with priority information. ATM, on the other hand, requires that an
individual virtual circuit be set up for each real-time stream.
The upshot of all this is that the edge switch used to connect between Token Ring and
ATM must provide must very complex protocol translation and packet discrimination
functions. And while the latest Version 2.0 LAN Emulation standard provides a
framework for these functions, the software complexity required to implement them is
daunting.
Support for voice and video integration can actually be provided rather more easily in an
end-to-end Token Ring network than in one that uses ATM in the backbone, by taking
advantage of Token Ring’s built-in packet priority scheme. The only requirement here is
that the network is based on Token Ring switches that support multiple levels of queuing
within the switch fabric. High priority packets are given precedence whenever
congestion occurs at an output port, and don’t suffer delays when bursts of data cause
traffic to back up within the switch.
This approach, based on the expedited delivery of priority packets, can’t offer the same
level of guaranteed Quality of Service as ATM. But it can provide a solution that meets
the need of all practical voice and video applications, so long as the network has plenty of
bandwidth and switching capacity. And since HSTR makes speed a relatively
inexpensive commodity for Token Ring networks, this will turn out not to be a problem.
Figure 5: Quality of Service over Token Ring with end-to-end packet prioritization

5. Conclusion
History has taught us that simple is good. Simple means low cost, easy to understand,
easy to live with. Arguably that is why Ethernet now commands the lion’s share of the
LAN marketplace – LAN technologies don’t come much simpler.
But LAN evolution decisions don’t take place in a vacuum. Every decision has a context,
and if the context is an existing Token Ring LAN installation, then simple means staying
with Token Ring. And HSTR represents by far the simplest path forward for Token Ring
LANs to meet the challenges ahead. Ethernet itself may be simple – but migrating an
existing Token Ring LAN to Ethernet is not.
ATM remains the backbone technology of choice for Token Ring users who need the
ultimate in performance, scalability and fault tolerance. But HSTR will provide an
alternative evolution path for those who are concerned about the complexity and entry
cost of ATM. And even in LANs where ATM is clearly the right backbone choice,
HSTR has a role to play in connecting server farms and supporting high speed
connections to workgroup switches.
For all those who have questioned the future of Token Ring, there is now an answer.
High Speed Token Ring is it.

Your Guide to High Speed Token Ring Networks

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Your Guide to High Speed Token Ring Networks

Similar to Your Guide to High Speed Token Ring Networks (20)

More from Ronald Bartels

More from Ronald Bartels (20)

Recently uploaded

Recently uploaded (20)

Your Guide to High Speed Token Ring Networks