Business Case

Token Ring-to-Ethernet Migration

Purpose of This Document

The purpose of this document is to communicate to enterprise network managers with an installed base of Token Ring technology that Token Ring is going away and to provide them with the information necessary to build a business case and plan for migrating to switched Ethernet-based LAN technologies. Enterprises need to put plans in place immediately to replace their Token Ring installed base with all deliberate speed.

A solid business case for any technology investment includes market projections, an analysis of various options, technical considerations, and financial calculations. This document provides the background information and generalized financials that can be utilized by an IT organization in building its own, specific business case. The document also offers case studies of large multinational organizations that have completed or are in the process of migrating from Token Ring to Ethernet. These case studies provide real-life feedback and lessons learned that are useful to those organizations still in the planning stages of their own migration.

The intended audience for the document includes individuals at all levels within the IT infrastructure of an enterprise involved in planning, implementing, or maintaining local and campus area networks. A secondary audience includes individuals involved in providing products and integration services to enterprise IT organizations.

Executive Summary

Long ago, Ethernet eclipsed Token Ring as the dominant enterprise LAN technology for new installations. It did so because it was less expensive and was offered by a larger number of vendors than Token Ring. However, some of the largest enterprises in the world continued to maintain and enhance their installed Token Ring networks, at least within a portion of their networks. Often their reasoning was driven by the fact that, historically, Token Ring was the preferred technology to support mission-critical SNA traffic.

Token Ring has now become a niche technology. The number of vendors providing Token Ring solutions is shrinking rapidly, and for some products there is only a single vendor still in the market. The prices for Token Ring solutions remain high compared to Ethernet-based solutions and, because of the lack of competition, will continue to do so. Finally, Ethernet is better equipped to support emerging networking applications and technologies such as gigabit speeds, multimedia, multicast, and voice/data integration applications. Therefore, most enterprises with Token Ring installed are implementing plans to migrate to Ethernet.

A popular misconception of some proponents for maintaining a Token Ring infrastructure is the belief that sticking with Token Ring is a "zero-investment" decision. In reality, the decision to remain with Token Ring implies a continued investment in the technology, with the purchase of new network interface cards (NICs) for each new PC installed, in addition to the purchase of new switches and routers to support the demand for increased network bandwidth. In most technology migrations of this type, financial metrics usually dictate a migration over time. However, for Token Ring users who are not already well into a migration away from that technology, time may well be short. The Token Ring migration is often coupled with other infrastructure changes, such as the elimination of legacy protocols in favor of IP or the refresh of desktop PCs.

One common stumbling block cited about migration to Ethernet is the existence of shielded twisted-pair (STP) wiring. STP was the recommended wiring for Token Ring networks, and many enterprises have massive investments in STP. Many network managers believe that a migration to Ethernet, which typically utilizes Category 5 unshielded twisted-pair (UTP) wiring, will require a complete rewiring of all buildings. This is not true—the Ethernet standard explicitly supports STP wiring, and inexpensive solutions exist for converting the connections. As a result, organizations with STP cabling can migrate to Ethernet without any rewiring in most cases. Both Cisco Systems and IBM have certified the operation of a selected number of their Ethernet products over STP.

Cisco has already announced the "end of sale" of many Token Ring platforms, and many other Cisco Token Ring products are rapidly approaching their end of life because of a greatly diminished number of customers still using Token Ring products. This lack of demand, in turn, results in an increasing difficulty in obtaining the necessary components for these products. As the popularity of the technology fades, this trend is inevitable and the Cisco experience is, no doubt, also occurring at all the remaining Token Ring vendors as well.

The message from industry analysts and organizations that have undergone the migration is clear—make the decision to migrate right now. To delay the decision means risking your ability to react in the future to deploy new networking applications and new networking technologies or even to maintain your current Token Ring network. In the long run, delaying the migration will cost more and will place your network at higher risk than if you get started today.

Market Data and Trends

The year 1999 was pivotal for Token Ring. Until then, a case could be made that Token Ring would continue to play a role, albeit a niche role, in the local and campus networks of some large enterprises. However, in 1999 several occurrences sealed the fate of Token Ring, which has succumbed to the market economies of scale and critical mass of Ethernet-based technologies, including switched Ethernet, Fast Ethernet, Gigabit Ethernet, and the emerging 10-Gbps Ethernet. Organizations that put off plans to migrate to Ethernet-based technologies run the risks of rapidly increasing cost of ownership and shrinking availability of products and vendors.

Market Data

The Dell'Oro Group, a research and consulting firm specializing in the networking industry, has tracked LAN hub and switch ports for a number of years. A January 2000 report highlights the negative growth in the Token Ring market, as depicted in Figure 1. The downward trend in the number of ports is obvious in this chart and dramatizes the niche status of Token Ring as compared to Ethernet.

Ethernet versus Token Ring Shipments

In this report the Dell'Oro Group also took the dramatic step of discontinuing coverage of Token Ring in its overall LAN hub/switch report. The rationale for this move was that Ethernet had become ubiquitous. In 1999, according to Dell'Oro, "Ethernet accounted for 98% of the ports shipped and 90% of the revenues within the LAN."

The Dell'Oro Group's findings are similar to those published by other research firms. NetReference, a Virginia-based technology consulting firm now owned by The Burton Group, teamed with Business Communications Review to conduct a survey of end user organizations with regard to their plans for LAN switching and routing. The survey, conducted in spring 1999, asked respondents to indicate which LAN environments they currently supported and planned to support in three years. The results were published in the May 1999 issue of Business Communications Review, in an article written by David Passmore of NetReference.

Respondents were first asked about their current and planned desktop LAN attachment standards. The results were clear—switched Fast Ethernet is the dominant choice for desktop connectivity to the network (see Figure 2).

Standard Desktop Today versus Three Years from Now

Respondents were next asked about their current and planned server LAN attachment standards. Again, the results were clear that Token Ring is being displaced. In the case of server attachment, however, the favored connectivity was Gigabit Ethernet, followed closely by switched Fast Ethernet (see Figure 3). Almost three years after this survey all indications are that the trend predicted by the responses was right on target.

Server Connectivity Today versus Three Years from Now

Market Trends

One of the primary reasons for the prolonged dominance of Ethernet technologies is the price/performance curve available to users of Ethernet-based products. In the early days of shared Ethernet environments, major enterprises could point to the higher speeds and more deterministic operation of Token Ring as justification for continuing to invest in the technology. However, with the more open nature of Ethernet and the continued investment by a number of vendors, the price of Ethernet-based solutions declined almost exponentially while the transmission speeds on Ethernet continued to increase. Shared 10-Mbps bandwidth was quickly replaced by switched 10-Mbps bandwidth. Switched 100-Mbps is now commonplace at the desktop, and gigabit solutions are being widely implemented on the campus backbone. Token Ring simply has not kept up. The price of 16-Mbps Token Ring switch ports is still higher than 100-Mbps Ethernet switch ports. High Speed Token Ring (HSTR), a standard for 100-Mbps Token Ring, has not taken off and there is no talk of implementing a gigabit Token Ring solution. The price/performance curve will continue to favor Ethernet solutions.

As a result of the declining customer interest in Token Ring products, the number of vendors supplying Token Ring NICs, hubs, and switches has declined. Perhaps more ominous for the long-term viability of Token Ring, however, is the lack of widespread support for HSTR. HSTR, originally supported by Bay, Cisco, 3Com, IBM, Madge Networks, Olicom, TI, and Cabletron, was the one hope that would provide increased bandwidth for Token Ring backbones and server farms and therefore allow customers with Token Ring to continue to reap benefits from their continued investment in the technology. One by one, the original proponents of HSTR dropped their plans for support until only IBM, Olicom, and Madge were left. In late 1998, IBM quietly cancelled its previously announced HSTR-based switch. Then, in August 1999, IBM and Cisco announced that IBM would exit the Ethernet switching and routing markets, which includes most of its LAN switches and all of its routers. IBM continues to support the Token Ring NICs and switches but does not aggressively promote Token Ring switching anymore. At about the same time as the Cisco/IBM announcement, Olicom exited the Token Ring business, selling to Madge Networks. The net effect of these recent moves is that there is only a single vendor (Madge Networks) still actively promoting HSTR.

As a result of the market data, the Ethernet price/performance advantage, and the narrowing field of vendor support for Token Ring, industry analysts and experts are warning customers to put plans in place immediately to convert from Token Ring to Ethernet. GartnerGroup, a highly respected IT research and consulting firm, issued a research note entitled "Token Ring to Ethernet: The Time for Migration Is Now" (T-08-8889, October 12, 1999). The author noted: "Organizations can now expect to see only small improvements in the price performance and functionality of Token Ring, while Ethernet continues to evolve rapidly, further widening the gulf in TCO between the two technologies. By 2001 the capital cost of constructing a high-throughput LAN using Token Ring (individually switched 16-Mbps duplex) will be three times the cost of constructing a comparable network using Ethernet (individually switched 100 Mbps)." [emphasis added]

Kevin Tolly, president of the independent testing lab The Tolly Group, writes in a December 13, 1999, Network World column, "[w]ith the near simultaneous implosions of IBM's Networking Hardware Division (NHD) and Olicom at the end of August, any remaining hope that token ring would continue as a strategic network technology was snuffed out." He concludes: "Convert? No longer is it a question of 'if,' but merely of 'when'." (Quoted with permission of Network World, 1999. Rights reserved.)

Summary

The research clearly indicates that enterprises are no longer installing Token Ring products in significant numbers. Shipments of new NICs and hub/switch ports over the next few years are expected to dwindle to almost zero. Ethernet has now essentially replaced the once large Token Ring installed base. Customers who continue to maintain an installed base of Token Ring equipment will face rapidly increasing costs of ownership relative to the Ethernet alternative. Over time, the number of vendors offering Token Ring products will shrink even further and the number of solutions available will be limited. As this implosion of the Token Ring base occurs, it will become more and more difficult to find, train, and retain personnel to work on Token Ring networks. The migration to Ethernet can be swift and dramatic or phased over time. The important thing that enterprises with an investment in Token Ring need to do is to put in place a migration plan and begin executing to that plan immediately.

Migrating Layers 1 and 2

The enterprise network manager faces a number of difficult decisions when evaluating the possible options for the installed Token Ring network. Organizations need to immediately set a goal of deploying a switched Ethernet-based infrastructure. How they achieve that goal and the areas that may need consideration are the subjects of this section.

Cabling

Many organizations that implemented IBM's Token Ring products beginning in the 1980s standardized on IBM's building wiring system. The IBM Cabling System (ICS) was a set of products and specifications that ranged from faceplates and connectors to the cabling used to implement Token Ring networks. ICS specified STP as the appropriate cabling for Token Ring networks. As a result, there are many large enterprises that have wired entire buildings with STP cabling. Because the standard for Ethernet networks is Category 5 UTP cabling, many IT managers believe that converting to Ethernet is not possible until they have rewired their buildings. If this were true, it would be a major impediment to many organizations and would effectively delay the conversion to Ethernet.

However, the Fast Ethernet standard specifies that it can operate over either Category 5 UTP or STP cabling. Still, some customers do not have faith that they can safely run Ethernet or Fast Ethernet over their STP cables. To aid these customers, both IBM and Cisco have performed a series of tests to certify selected Ethernet/Fast Ethernet products operating over Token Ring STP for cable lengths up to the IEEE 802.3u standard of 100 meters. Based on these tests, Cisco has announced support for Fast Ethernet over STP cables for many of its products. Many customers worldwide have successfully implemented 10/100-Mbps Ethernet networks using their existing Token Ring STP cabling. The testing and products supported are described in detail in the product bulletin "Shielded Twisted-Pair Cabling Support for Cisco Fast Ethernet Products".

Source Routing versus Transparent Bridging

Token Ring networks often utilize source-route bridging (SRB) at Layer 2 along with dual network equipment and paths to ensure the high availability that is required for access to mission-critical SNA mainframe applications such as billing, customer record access, and manufacturing resource planning. The only bridging mode available in Ethernet networks is transparent bridging (TB), also at Layer 2.

SRB offers the following Layer 2 advantages over TB for SNA traffic:

• Provides active parallel paths for traffic distribution
  
  
• Allows duplicate Media Access Control (MAC) addresses for SNA gateway automatic backup
  
  
• Assists with problem determination by providing the entire path through the network
  
  

SRB achieves the first two advantages by allowing multiple active paths between stations, whereas Ethernet's TB spanning-tree algorithm does not support multiple active paths at Layer 2. The common implementation is to have two different paths and two different interfaces to the host, such as dual Token Ring interface couplers (TICs) in a front-end processor (FEP) or dual Token Ring interfaces in a channel-attached Cisco 7500 Series router. By allowing multiple active paths, SRB allows the host-bound traffic to be load balanced across these paths. Because the two host interfaces can have the same MAC address, the failure of one path or one interface allows sessions that had been using that path or interface to quickly and, without intervention, reestablish the sessions through the remaining active path and interface.

SRB assists with problem determination because each frame carries a routing information field (RIF) that details each interface and path through which the traffic is flowing. By examining the RIF, network management software and the network management staff can more easily isolate failed components and paths in the network.

When organizations convert from Token Ring to Ethernet, they will necessarily need to implement TB and spanning-tree algorithm, and therefore will lose the bridging-based load distribution and alternate session path reestablishment inherent in SNA SRB networks. However, these capabilities can be effectively replaced by converting SNA clients to IP. This is the recommended method, and the one that enables the greatest range of options. By converting SNA clients accessing the host from SNA 3270 emulation to TN3270 clients (which provides the same functionality at Layer 3 using IP as the transport), IP-oriented load balancing and alternate path functionality can be utilized. SNA LU 6.2 and subarea SNA traffic can be supported using Enterprise Extender for Layer 3 IP transport.

With more and more network and application services being based on IP at Layer 3, the ability to dynamically route data packets using IP at the network layer is increasingly in demand. One of the fundamental capabilities of routers and Layer 3 switches is the creation of routing tables that automatically adjust themselves to the ever-changing network topologies caused by link failures, device failures, and additions and deletions to the network. Dynamic routing protocol technology is used in routers and Layer 3 switches to populate routing table entries throughout an IP network infrastructure in order to provide the following:

• Optimal path determination based on metrics such as bandwidth, delay, number of network hops, and maximum transmission unit (MTU) size
  
  
• Redundant path information in the event of network link failures
  
  
• Load sharing across available redundant paths
  
  
• Fast convergence on redundant paths in the event of network link failures
  
  

Layer 3 functionality also enables a vast array of intelligent network features such as user authentication, fault tolerant route redundancy, network troubleshooting and quality of service (QoS) and Class of Service (COS) parameters. Because QoS is a systemwide solution, it is designed to be optimally effective when applied in an end-to-end fashion. It must be independent of platform, device, and underlying media, and it must operate at Layer 3 and above to ensure end-to-end functionality across multiple physical network devices and link-layer WAN and LAN topologies.

The Cisco IOS^® Software and technologies built into Cisco network devices share a related set of integrated QoS tools that interoperate to enforce QoS policy from the network core to its outer edges. QoS at Layer 3 can be enabled by specific application, protocol, or IP address, allowing a wide range of video, voice, and data applications (including SNA-based applications) to be simultaneously and reliably delivered.

In addition, Layer 3 switches are typically hardware-based application-specific integrated circuits (ASICs). This enables IP packet throughputs in the range of millions of packets per second. ASIC-based Layer 3 switches enable a significant number of routing protocols to be employed, including a variety of IP and other multicast technologies. The white paper "Gigabit Campus Network Design—Principles and Architecture" is highly recommended for information about designing redundant, highly available networks using Layer 3.

Frame Sizes

An oft-repeated advantage of Token Ring networking over Ethernet networking has been that Token Ring supports larger frame sizes. The advantage of this is that large frame sizes can make more efficient use of the bandwidth available. The amount of actual data as a percentage of overall traffic (which includes protocol headers and inter-frame gaps) is higher when the network is able to pass larger frames than when it breaks the same data up into multiple smaller frames. Large frames also demand less processing in the servers to which they are destined.

Except in the specific situation of Gigabit Ethernet on the Catalyst^® 6500 (which supports 9000-byte Jumbo frame sizes), Token Ring does support larger frames than Ethernet—up to 18 KB versus Ethernet's 1.5 KB. There are two factors, however, that are rapidly making this a non-issue for organizations comparing the two technologies:

• Most SNA transactions are small (100 bytes in and 1000 bytes out), meaning that the large frames are useful only for large SNA file transfers. Because many organizations are using TCP/IP's File Transfer Protocol (FTP) rather than SNA for transferring files, there are few remaining applications that can take advantage of the larger frame size of Token Ring.
  
  
• The bandwidth available to the Ethernet environment keeps increasing. Even large frames within a gigabit-speed pipe are small compared to the total bandwidth available. And although servers must do more work to process four 1500-byte frames than a single 6000-byte frame, the amount of additional work is relatively small, much less than four times the work.
  
  

Migration Considerations for Shared versus Switched LANs

A significant determining factor in deciding on a migration path to Ethernet is the current state of the Token Ring network (the interim mixed Token Ring and Ethernet environment can take on a number of different designs). Figure 4 depicts two common migration paths. The top path illustrates a typical migration when an organization is beginning with a classic, shared Token Ring design. The bottom path illustrates a typical migration when an organization is beginning with a switched Token Ring design. Figure 4 highlights two important concepts:

• The final goal of migration is a switched Ethernet environment.
  
  
• The recommended migration path is predicated on whether the existing Token Ring environment is already based on switching or whether it is still a shared Token Ring environment.
  
  

The basic difference between the two paths is in the design of the backbone during the period in which both Token Ring and Ethernet exist.

Common Token Ring-to-Ethernet Migration Paths

The typical steps taken in each of the two migration paths, the rationale, and the considerations are detailed in the following sections. Please note that these paths are generalizations based on the collective experience of the Cisco customer base. Each customer, however, has unique challenges and difficulties that must be overcome during the migration. Cisco recommends that customers carefully plan their migration and consider utilizing the expertise of a solutions partner with the experience and ability to get involved in the planning and implementation stages. Doing so can dramatically reduce the risk of the migration.

Migration from Shared Token Ring

An organization that has a shared Token Ring infrastructure still has hubs in the wiring closet. The 4-Mbps or 16-Mbps bandwidth available is shared between all of the end users and servers on the ring. The campus backbone is usually built with routers that are interconnected via Ethernet, Token Ring, or Fiber Distributed Data Interface (FDDI).

An organization such as this is probably feeling the constraint of the shared bandwidth. Even if the eventual goal is to migrate to Ethernet, the first step may be to augment the existing Token Ring environment with the deployment of switches. Token Ring switches can be deployed in the wiring closet to microsegment the existing rings so that each user or server receives a higher total bandwidth. The investment in the new switches should be viewed as a tactical, short-term investment that is made to address only the near-term problem of insufficient LAN bandwidth.

The router-based backbone can support both Token Ring (for the near term) and Ethernet and, therefore, can be kept in place. However, at some point this backbone itself will become a bottleneck. At this point the organization should implement a mixed-media, switched backbone that will provide sufficient bandwidth for the near and long term and that can support both Token Ring and Ethernet frames.

The two mixed-media backbone options available for consideration are:

• Cisco's Inter-Switch Link (ISL)
  
  
• Asynchronous Transfer Mode (ATM)
  
  

ISL is a Cisco-defined protocol that utilizes Fast Ethernet or Gigabit Ethernet links for the backbone so that it operates at 100 Mbps or 1 Gbps. ISL can simultaneously support both Token Ring and Ethernet frames without adding the complexity of ATM LANE services. ISL is simpler to implement and less costly than ATM. ISL sets the stage for a seamless migration to a pure Ethernet environment. After the migration to Ethernet is complete, a simple software reconfiguration of the switches converts the ISL backbone into a standards-based Fast Ethernet or Gigabit Ethernet backbone. Although ISL is implemented on a wide variety of Cisco switches and routers, it is not an international standard protocol. A third-party ISL NIC is available that supports both Token Ring and Ethernet frames and allows direct server attachment to the ISL backbone.

ATM is a scalable backbone technology that provides support, via LAN Emulation (LANE) services, for both Token Ring and Ethernet. ATM is also quite ubiquitous—there are a wide variety of server NICs, switches, and routers that support ATM. The downside of ATM is that it is a relatively complex and expensive option. In the last few years IP Layer 3-based transport solutions over Ethernet have made ATM essentially obsolete as a LAN technology. As a result, ATM within the campus network has failed to meet the market predictions of just a few years ago. Most organizations are reserving ATM implementations for the WAN and implementing the more cost-effective Ethernet/Fast Ethernet/Gigabit Ethernet solutions in the campus network.

After the new, switched backbone is in place, organizations can set their plans to migrate workstations or workgroups one at a time to Ethernet at the pace that makes sense. However, there will be certain groups or individuals who will question why the migration needs to progress beyond this step when the additional bandwidth has been obtained through the implementation of workgroup switching and a high-speed, switched backbone. These groups or individuals may argue that the new Token Ring environment can meet the future needs, and "if it ain't broke, don't fix it."

The simple explanation that Token Ring will cost three times more than Ethernet is probably not sufficient to change their minds, because they will argue that the investment has been made and the infrastructure is already in place. Bear in mind that the top, compelling reasons that an eventual Ethernet migration plan is essential are:

• Staying with Token Ring is not a "zero-cost" option—each new PC and new user requires a continual investment in Token Ring NICs and switch ports.
  
  
• Emerging technologies and applications may be difficult or impossible to implement on Token Ring (for example, Voice over IP (VoIP) and multicast distance learning); the lost opportunity cost for a delayed implementation can be very high.
  
  
• The pool of vendors providing solutions is shrinking rapidly; Cisco and other Token Ring vendors have already placed products in "end of life" status; replacement products will be increasingly difficult to find and support will become a real problem.
  
  
• The pool of skilled Token Ring technicians has diminished greatly, and it will become increasingly difficult in the future to attract and then train new workers willing to work on a moribund technology.
  
  

Migration from Switched Token Ring

Organizations that have already implemented Token Ring switches are different from those that are still operating with shared rings. By definition, these organizations have replaced the hubs in the wiring closets with switches and have implemented a campus backbone that interconnects the switches.

This type of organization can, like the previous type of organization, attempt to implement a single backbone that accommodates the existing and the new. However, this may be more difficult than it first appears. There may be interoperability issues. For example, consider an organization that has implemented IBM 8265 backbone switches for Token Ring-to-ATM connectivity. Adding new Ethernet switches to this environment is not trivial.

If the existing Token Ring environment is operating satisfactorily and providing ample bandwidth to meet current requirements, then replacing the existing backbone with a new multimedia backbone that supports both Token Ring and Ethernet is not the best approach to take in the majority of cases. Instead, it probably makes much more sense to simply build a parallel backbone to support Ethernet and migrate to Ethernet over time. This approach has the enormous benefit of being nondisruptive to the existing users and can virtually eliminate any continued short-term tactical investments in Token Ring technology. The obvious downside of this approach is the cost of building and maintaining a second backbone. Nonetheless, many organizations are implementing a dual backbone because this approach offers better risk containment than a backbone replacement approach.

Although it may be less risky, the dual backbone approach can be challenging to implement. To create the parallel backbone, one must:

• Install Ethernet switches in all wiring closets that will connect to new Ethernet desktops
  
  
• Install additional backbone cabling, if required
  
  
• Build a gigabit-capable Ethernet backbone with new switches
  
  
• Interconnect the existing Token Ring network with the new Ethernet network at Layer 3 or, in some cases, using translational bridging
  
  
• Attach servers to both networks (with two NICs) or move servers to Ethernet after a critical mass of users is on Ethernet
  
  

When the backbones are in place, then individual users or entire workgroups can be converted to Ethernet as the business case warrants.

Timing Considerations

The two previously described migration paths presuppose that an organization is planning to migrate to Ethernet, not convert to Ethernet. An Ethernet conversion plan is more aggressive, with a near-term goal of upgrading each and every desktop, laptop, and server with an Ethernet NIC and replacing all Token Ring wiring closet hubs and switches with Ethernet switches. This move is often termed a "forklift" upgrade because of its complete replacement of one infrastructure with another. Few organizations can contemplate this approach on a campus-wide basis, and the risk of a large conversion project is substantial.

A common approach taken in planning a migration to Ethernet is to convert a small, manageable number of users at one time. For example, a financial organization that has a large number of geographically separate remote offices can take each remote office one at a time, performing the conversion of a single office overnight or over a few days. With this approach, a standard plan can be created that is replicated at each office, with only exceptions outside of the norm requiring individual planning and attention. Because each branch location can be autonomously converted, the overall migration time frame can be short and aggressive or longer and more gradual, depending on the capital and technical personnel available.

Because the Ethernet migration eventually requires an organization to touch each and every desktop and each wiring closet, it is not uncommon for organizations to piggyback the Ethernet migration with another project of equal magnitude. For example, most organizations update and refresh PCs at the rate of one-third of the installed base per year. By piggybacking the Ethernet change with the desktop refresh, the cost of the change can be amortized over two projects rather than one. There may be synergies between the two projects, so that the Ethernet change makes the other desired change easier, or vice versa. For example, many new PCs come equipped with an Ethernet port integrated into the motherboard. Installing a new PC with Token Ring instead is harder and more expensive—one must purchase a new NIC (or remove the old one from the old PC), install it inside the new PC, and install and configure all required Token Ring network driver and protocol support. Another common project piggybacked with Ethernet conversion is the conversion of the desktop from SNA to IP. These considerations are discussed in the next section. One important consideration of piggybacking two projects together, however, is that the technical risk of the change may increase. A sound testing, fault isolation, and rollback plan is essential.

Migrating Layers 3 and Above

The migration from Token Ring to Ethernet or the coexistence of the two LAN environments involve technical considerations beyond the NICs, wiring closet equipment, and campus backbone design that have been discussed to this point. This section details some of the common technical considerations faced by enterprises undergoing migration.

Networking Protocols—SNA, IPX, and IP

Most large enterprises have a number of networking protocols implemented within their networks. IP, SNA, Novell IPX, and NetBIOS are common. However, IP is quickly becoming the dominant data transport protocol over the network for the following reasons:

• The unprecedented success of e-business and e-commerce solutions requires organizations to quickly build corporate intranets, extranets, and Internet access that are based on Internet standards, including IP.
  
  
• IP supports emerging multimedia applications, utilizing multicast and voice/video/data integration more effectively than other protocols.
  
  
• IP is the basis for new advances in load balancing and redundancy solutions, directory services, and other advanced networking services.
  
  
• IP is ubiquitous, scalable, and inexpensive.
  
  

Many organizations are standardizing on IP as the strategic enterprise networking protocol. This standardization may influence their decision to migrate from Token Ring to Ethernet. However, these are somewhat separate and distinct decisions and projects, because Ethernet can readily handle non-IP protocols like SNA and IPX. Nonetheless, organizations may couple the migration from SNA or IPX to IP with the conversion from Token Ring to Ethernet. With this approach, the joint effort can be amortized over multiple projects, and the business case for the overall strategic goal may be stronger than a standalone business case for Ethernet migration.

Organizations that are not yet ready to convert the client base to IP can still gain the advantages of a common, IP-based backbone network. Cisco offers a variety of different solutions to allow organizations to encapsulate legacy protocols within IP. In fact, there are in excess of 750,000 Cisco routers installed worldwide that provide encapsulation of SNA or NetBIOS in IP datagrams.

Access to Legacy Applications

Large enterprises around the world have massive investments in their legacy applications running on IBM mainframe systems and IBM AS/400 systems, among others. These organizations have found it impossible or undesirable to convert the applications to run on client/server or intranet IP-based systems. These legacy applications, in many cases, are the life-blood of the IT infrastructure—in fact, defining the term mission critical. Not only must existing users continue to have reliable and responsive access to these applications, in many cases the applications are being opened for secure access by a new breed of users across corporate intranets, extranets, or even the Internet.

The migration from Token Ring to Ethernet does not in any way impact the ability of existing and new users to access these legacy applications. SNA, the networking architecture and set of protocols used in IBM environments, operates over Ethernet just as well as it does over Token Ring, with the single exception being the SRB-versus-TB issue discussed in the section Source Routing versus Transparent Bridging. However, as organizations are migrating to Ethernet in large numbers, many are also migrating network transport from SNA to IP.

Most legacy applications on IBM mainframes and AS/400 systems communicate natively using SNA or its successor, Advanced Peer-to-Peer Networking/High Performance Routing (APPN/HPR). To convert these applications for native IP support would require massive application rewrites in many cases. However, there is a simple approach to allow the user base to migrate to IP while leaving the SNA-based applications untouched—implement host-based or network-based gateways that convert the client IP frames to SNA.

The majority of legacy applications are written to communicate with traditional terminal devices for interactive transactions. This is accomplished through the use of data streams—strings of commands and data that instruct the terminal how to paint the screen and accept input from the user. The standard for mainframe applications is the SNA 3270 data stream, named after the traditional 3270 terminal. The standard for the AS/400 is the SNA 5250 data stream. With the migration from fixed function terminals to PCs in the 1980s, PC software known as emulators were developed to allow the PC devices to emulate the functions of a traditional terminal. Most corporate users access legacy applications using these software emulators.

With the popularity of IP beginning in the mid-1980s and the 1990s, new standards developed to allow these legacy data streams to be carried within IP frames. TN3270 (and its follow-on, TN3270E) and TN5250 are these standards. All dominant emulator programs support these protocols as options for host access. TN3270 and TN5250 are also the basis for new products that allow Web browsers to access legacy hosts. The conversion from TN3270 or TN5250 to SNA for communication with the legacy application is performed by a gateway, either implemented in software in the host system or in a network-based device. The Cisco Channel Interface Processor (CIP) and Channel Port Adapter (ECPA4) support TN3270 conversion (the Cisco CIP and ECPA4 do not support TN5250 conversion).

TN3270 Client/Server

TN3270 is a protocol that primarily addresses the SNA logical unit (LU) type 2, "green screen" SNA 3270 terminal and print requirements using readily available TN3270 client software over an IP Layer 3 infrastructure to either a Cisco TN3270 Server running on a CIP or ECPA4 or a TN3270 server function running on an IBM S/390 or zSeries host.

TN3270 was originally defined in RFC 1576 and is based on the Telnet protocol. The difference between a Telnet session and a TN3270 session, however, is that a Telnet session uses the ASCII character set and sends a line of data at a time, whereas TN3270 session uses the extended binary coded decimal interchange code (EBCDIC) character set and sends a block of data (a screen refresh) at a time.

The following elements work together to enable TN3270 communication:

• The end stations run a TN3270 client, which emulates a SNA 3270 terminal display.
  
  
• The client accesses a TN3270 server over an IP network.
  
  
• The TN3270 server converts the TN3270 data stream to SNA 3270 and passes the data to the mainframe. The TN3270 server resides on either the mainframe, in which case it is considered an inboard server, or a CIP or ECPA4, in which case it is considered an outboard server.
  
  
• The mainframe provides Communications Server 390 (CS/390) Virtual Telecommunications Access Method (VTAM) support and the mainframe application that the user is attempting to access.
  
  

In an SNA 3270 network, the user is known by an LU name. In an IP network, the user is known by an IP address. One of the tasks of the TN3270 server is to provide a correlation between these two addresses. This correlation allows the SNA applications to maintain the LU requirements and allows the network to use IP as the transport infrastructure end-to-end. Therefore, TN3270 server support is the solution of choice for addressing end-user workstations requiring SNA terminal access to SNA applications.

TN3270 Server on a Cisco CIP or ECPA4

The implementation of Cisco's TN3270 Server on a channel-attached router, using the CIP or ECPA4, provides an efficient method of removing the processing of TN3270 sessions from the mainframe to a router-based platform. The CIP can be installed in a Cisco 7500 Series router, and the ECPA4 can be installed in a Cisco 7200 Series router. Figure 5 illustrates this method.

TN3270 Server Overview

TN3270 Server on the IBM Host

IBM has greatly improved the performance of the TCP/IP stack on the mainframe CS/390 and zOS/390 and has integrated the TN3270 server application on the host. Customers who are running the latest IBM mainframes (IBM G5/G6 or zSeries) and latest releases of host operating system (OS/390 and CS/390 V2R7 or newer) and who are interested in supporting only IP traffic to the host should consider using host TN3270 server and the IBM Open Systems Adapter (OSA)-Express operating in Queued Direct Input/Output (QDIO) Direct Memory Access (DMA) mode (Gigabit Ethernet) connected to a Catalyst 6500 multilayer switch. The OSA-Express running in Gigabit Ethernet mode provides significantly better performance than the older OSA1 and OSA2 adapters and provides better throughput for IP traffic than an Enterprise System Connection (ESCON) channel can possibly provide. In this case, the mainframe solution can provide comparable price/performance to the CIP- or CPA-based solution

SNASw Enterprise Extender

SNA Switching Services (SNASw) is Cisco's current APPN feature of Cisco IOS Software, and it is the optimal Layer 3 solution for Token Ring-to-Ethernet migration for peripheral SNA LU 6.2 and subarea devices and clients. SNASw enables operators of enterprise networks to develop their IP infrastructures while meeting SNA transport and underlying SNA application routing requirements. Enterprises can continue to enhance and deploy a converged network based on IP while handling traffic destined for SNA-based applications without changes to the application itself.

SNASw provides necessary SNA application routing support for SNA LU 6.2 Advanced Program-to-Program Communications (APPC) session routing using the Branch Extender (BX) Branch Network Node (BrNN) APPN node type, for SNA transport over IP using Enterprise Extender (EE), and for Dependent Logical Unit Requester (DLUR) functionality for subarea SNA. The support capability of SNASw is depicted in Figure 6.

SNASw Design Options

SNASw EE was created within the open framework of the APPN Implementers Workshop (AIW) and submitted to the Internet Engineering Task Force (IETF) as RFC 2353 in May 1998, and it has been commercially available since 1999. Cisco SNASw implements the EE feature as well as IBM CS/390 V2R6 (with APAR OW36113 applied) and higher. EE is a logical connection that represents IP connectivity from an EE-enabled IBM S/390 or zSeries enterprise server to the SNASw EE router. EE enables IP applications and convergence over a single network transport (IP) while preserving customer SNA application and SNA client endpoint investments. EE support on the CS/390 host enables users to build highly reliable SNA routed networks that run natively over an IP infrastructure directly to the S/390 Enterprise Servers. EE routing at Layer 3 is performed by the IP routing infrastructure. End-to-end reliability, error recovery, flow control, and segmentation support for the underlying SNA sessions are supported using APPN/HPR and HPR's Rapid Transport Protocol (RTP).

SNASw EE leverages the inherent redundant path and availability features of IP and dynamic routing capabilities at Layer 3 by providing high-performance SNA application transport across an IP backbone (see Figure 7). This results in providing a high-availability, failure-resistant infrastructure regardless of the underlying LAN or WAN media. When multiple paths to enterprise mainframe servers exist, normal IP dynamic reroute capabilities maintain all the SNA connections and can dynamically switch client sessions directly to the application host without session disruption, thus avoiding all single points of failure in the network.

SNASw EE

Consolidating SNA traffic onto a single IP network transport infrastructure creates a media-independent environment operating independent of the underlying Layer 1 and 2 physical media and data-link control functions, respectively. This eliminates the need to use SRB on physical Token Ring media at Layer 2 to maintain active redundant SNA Logical Link Control (LLC) paths upstream from the network to mainframe enterprise servers. The IP layer handles packet forwarding for EE, providing the following advantages:

• Maximizes router efficiency by using native IP routing
  
  
• Positions SNA applications to fully exploit advancements in dynamic IP routing technologies
  
  
• Enables a single end-to-end network transport model, which reduces costs and simplifies network design and management
  
  
• Overlays Layer 2 LAN/WAN technology-specific QoS signaling solutions with advanced Layer 3 IP QoS methods such as IP precedence, Differentiated Services (DiffServ), Integrated Services (IntServ), and Resource Reservation Protocol (RSVP)
  
  

Local LAN-attached SNA end devices connecting to Token Ring interfaces of Cisco routers running SNASw can utilize SRB support in the router to internally bridge SNA LLC traffic into SNASw. Locally attached SNA devices on Ethernet LANs or switches are supported using direct data-link control mechanism, eliminating the need to bridge LLC traffic coming from Ethernet LANs into SNASw EE (as is the case with Data-Link Switching Plus [DLSw+]). Local SNA- and Synchronous Data Link Control (SDLC)-attached devices can also be connected into SNASw using Virtual Data Link Control (VDLC).

SNASw provides the MAC address destination endpoint for remote SNA device connections to upstream hosts and also can provide duplicate MAC address support for downstream SNA devices. SNASw can also be deployed in existing central site DLSw+ aggregation routers in environments where DLSw+ is supporting existing SNA transport requirements over the WAN, as illustrated in Figure 8.

Combined SNASw EE and DLSw+ Network

Traffic flowing upstream from SNASw EE to the mainframe can utilize any physical mainframe transport facility such as the CIP, ECPA4, or OSA-Express. SNASw can also help to eliminate the need for SNA routing by FEPs for peripheral SNA devices in the network.

High-speed IP data transport (up to Fast Ethernet 10/100-Mbps wire speed) is supported by the Cisco CIP and ECPA4. When a host mainframe is configured with EE, the CIP and ECPA4 can provide robust upstream IP connectivity to the host from SNASw EE-enabled routers at remote branches or regional distribution centers.

For enterprises that need to transmit data in the gigabit range, the IBM OSA-Express can also be deployed in conjunction with Cisco Catalyst 6500 multilayer Gigabit Ethernet switches supporting Jumbo frames to provide the best IP host transport option. Cisco's design approach to building highly resilient network infrastructures makes optimal use of Catalyst 6500 multilayer switching technology to build campus intranets that are scalable, fault tolerant, and manageable. A multilayer campus intranet is highly deterministic, making it easy to troubleshoot as it scales. The multilayer design is also modular, so bandwidth scales as building blocks are added.

Intelligent Layer 3 services keep broadcasts off the backbone. Dynamic IP routing protocols such as Open Shortest Path First (OSPF) handle load balancing and very fast convergence across the backbone. The multilayer model makes migration easier, because it preserves existing addressing. Redundancy and fast convergence are provided by UplinkFast and Hot Standby Router Protocol (HSRP), which can also provide automatic SNASw router redundancy for SNA devices on Ethernet LAN. Bandwidth scales from Fast Ethernet to Fast EtherChannel^®, and from Gigabit Ethernet to Gigabit EtherChannel. The model supports all common campus protocols.

Management

Organizations with a large Token Ring infrastructure have implemented network management tools and procedures over the years to effectively manage the Token Ring environment. As described in the bridging section, Token Ring frames provide path information within the RIF that has been helpful in fault isolation and problem determination. IBM's LAN Network Manager (LNM) was a common tool for managing and administering Token Ring networks.

With the migration to Ethernet, organizations need to evaluate new tools and methodologies. Fortunately, the new innovative network management tools and products being introduced all natively support Ethernet and even Token Ring switches for organizations that plan to enhance their Token Ring infrastructure with new switches. The modern network management tools utilize the Simple Network Management Protocol (SNMP) and Remote Monitoring (RMON) to provide network operations staffs with a rich set of functionality. See information on the complete suite of Cisco network management solutions.

For More Information

Cisco.com and the trade press offer a wide variety of detailed technical and product information for organizations planning to upgrade their existing Token Ring environments or to migrate from Token Ring to Ethernet. Some of these resources are:

• "Gigabit Campus Network Design—Principles and Architecture" white paper
  
  
• Catalyst Family of LAN Switches
  
  
• The Business Case for Consolidating SNA and IP in the Enterprise Network
  
  
• "Shielded Twisted-Pair Cabling Support for Cisco Fast Ethernet Products"
  
  
• "Token Ring to Ethernet: The Time for Migration Is Now" (GartnerGroup)
  
  
• "Escaping Token Ring Without Losing Your Shirt or Mind" (Network Computing)
  
  
• SNA Switching Services Design and Implementation Guide
  
  
• SNA Switching Services
  
  
• IBM Router Interoperability and Migration Examples, SG24-5865
  
  
• "Extending the Enterprise: SNA Application Transport over IP"
  
  
• IBM and Cisco LAN Switching: An Interoperability and Migration Guide, SG24-5867-00
  
  
• Cisco Token Ring Solutions Web site
  
  

Developing a Migration Business Case

Most IT projects that are large in scope or require significant investments need to have a formalized business plan documented before the undertaking can be approved and gain funding. A full business plan addresses many business and technical issues, including:

• Business environment
  
  
• Competitive environment
  
  
• Strategic goals
  
  
• Tactics to achieve the goals
  
  
• Technical alternatives, with pros and cons and recommended approach
  
  
• Implementation plans, including resource requirements
  
  
• Return on investment or other financial model
  
  
• Impact of a "no-go" decision
  
  
• Risks and issues
  
  

As you can see, the financial return on investment is only one element of a comprehensive business plan. However, it is the culmination of the plan and summarizes and quantifies that plan. Some organizations require a complete financial analysis of all options and select the option that demonstrates the best return on investment. In other organizations, a strategic decision to move to a particular technology may be made without regard to the near-term costs and calculable return.

Some organizations with large investments in Token Ring technology are mandating migration to Ethernet from a strategic technology perspective. For example, a large computer company recently began a massive migration from Token Ring to Ethernet. This decision was made without the benefit of a detailed financial analysis. Several reasons were given for this strategic technology decision:

• Token Ring is perceived to be at the end of its life.
  
  
• Token Ring and ATM cost more than Ethernet and will continue to do so.
  
  
• New networking applications are more difficult to support on Token Ring than Ethernet (for example, VoIP and multicast applications).
  
  
• The company perceived that it could not compete effectively with an "obsolete" technology base.
  
  

Whether the decision is based on financial analysis or on business, competitive, or technology factors, the costs and benefits of a Token Ring upgrade or migration to Ethernet should be formalized and documented. This will help control costs and guide the implementation.

The purpose of this section is to serve as a guide to network managers with Token Ring infrastructure in developing a specific business plan and financial analysis for use within their organizations. It provides generalized figures and details the factors that should be included in a complete analysis.

Return on investment (ROI) is a common financial metric that is used by organizations to measure the relative attractiveness of various investments. Stated mathematically:

ROI = (Total Benefits - Total Costs) / (Total Costs) * 100

This calculation yields a percentage that represents the return to the organization for a given investment made (that is, Total Costs). ROI benefits and costs are calculated based on a particular time frame, often from 18 months to three years. ROI is not the only common financial metric used by organizations. Some prefer to calculate payback period, which indicates the number of months or years a given investment is paid for in reduced costs or other benefits. Others prefer to calculate the internal rate of return (IRR), which states the return in terms of the cost of that company's capital. There are other methods as well. You should check with your finance department or IT business analyst to see which method is preferred within your organization before you begin collecting and calculating the costs, because the method preferred may impact the time scale used and the way in which the data is collected or expressed. Whichever method is used, one must first quantify the total benefits and total costs.

Before summarizing the various costs and benefits, it should be noted that many of the benefits (and some of the costs) of migrating to Ethernet will be intangible rather than tangible. For example, how do you quantify a benefit like being prepared for future, unanticipated applications? If the applications are not yet known, the benefit of having an infrastructure that can support them is hard to pin down to a particular number, and the cost of not being prepared to adopt the applications is also impossible to know. There are many other examples of benefits or costs that are difficult to quantify. There are three ways of dealing with intangible entities:

• Do your best to quantify them. Talk to people in organizations that have already undergone a migration and ask them for their opinions and their experiences. Derive a figure that seems reasonable based on your current understanding. Always document the assumptions you used to derive the figure so that it can be adjusted if new information comes to light in the future.
  
  
• It may be more appropriate to come up with a range of possible values or a set of values such as an optimistic, realistic, and pessimistic value. Do your calculation with all of the values and present the range of possible outcomes. Leverage outside industry analysts to help put a percentage against each of the possible outcomes that reflects their relative likelihood of occurring.
  
  
• Do not include a figure for that cost or benefit in the financial return calculation. Document the cost or benefit in the overall business plan and describe it qualitatively rather than quantitatively.
  
  

Earlier in this document, three migration options for the Token Ring environment were detailed: stick with Token Ring, migrate to Ethernet, or maintain a mixed environment. There will be common elements in the financial analysis for any of these options. For example, in each case the near-term and long-term training requirements must be calculated. New equipment must be factored in for all cases. However, there will be marked differences in the financial analysis between the three options. For example, converting all existing desktops from Token Ring to Ethernet will have a sizable line item in the financial analysis for new NIC cards. Organizations that decide to only implement Ethernet on new desktop systems may have a very small figure on that line item because many PCs and laptops ship with an Ethernet connection.

Many organizations will adopt a hybrid approach to migration that could include all three migration options. For example, branch offices could be slated for near-term conversion to Ethernet. Headquarters could continue to support a mixed environment. Departments that will continue to support Token Ring may gain additional bandwidth through implementing Token Ring switching. The following sections detail the potential benefits and costs that an organization may encounter, depending upon the approach taken. Not all benefits or costs will apply in all cases. The intent is to offer these as a guide. Feel free to add factors and otherwise customize the factors to meet your particular situation.

Calculating Total Benefits

In terms of the financial analysis of the migration, the "benefits" side of the ROI equation includes any factor that is a cost saving or a cost avoidance. The potential benefits are categorized as equipment, personnel, non-personnel recurring costs, and business benefits.

Equipment and Software

• Token Ring NIC avoidance—Calculate the money that would have been spent on Token Ring NICs over the time period that will no longer be spent because of the migration. If the migration did not occur, you would buy "x" new Token Ring NICs over the period for new users, new servers, and upgrades to existing users. A rule of thumb is $150 to $250 per NIC.
  
  
• Token Ring wiring closet equipment—Calculate the money that would have been spent on Token Ring hubs or switches to accommodate new users or to replace obsolete existing hubs. A rule of thumb for new Token Ring switches is $150 to $500 per port.
  
  
• Campus backbone equipment—Calculate the money that would have been spent on upgrading and adding to an existing FDDI, Token Ring, or ATM backbone.
  
  
• Data center equipment—Calculate the money that would have been spent on upgrading data center equipment to support the Token Ring environment. Examples include additional FEP TICs and enterprise router Token Ring, FDDI, or ATM interfaces.
  
  
• Network management software and equipment—Calculate the money that would have been spent on supporting and possibly enhancing the current network management tools for management of the Token Ring environment. Only include software and equipment that will no longer have to be purchased under the migration plan.
  
  

Personnel

• Token Ring expertise—Estimate the cost of continuing to require Token Ring expertise, including the cost to find and retain employees with Token Ring skills and the cost to train other staff on Token Ring installation, management, and problem determination. Factor in to your estimate the reality that the available pool of Token Ring expertise is shrinking, while the available pool of Ethernet expertise is growing rapidly.
  
  

Non-personnel Recurring Costs

• Equipment maintenance—Calculate the money saved by eliminating the annual maintenance charges on Token Ring-related equipment that will be retired as a part of the migration.
  
  
• Software maintenance—Calculate the money saved by eliminating the annual maintenance charges on Token Ring-related software that will be retired as a part of the migration.
  
  
• Outsourcing charges—If you outsource any part of your network that includes Token Ring infrastructure, calculate the reduction in ongoing outsourcing charges as a result of your migration to Ethernet.
  
  

Business Benefits

• Flexibility—Try to estimate the value of having an infrastructure that is more flexible to easily adapt to new applications, such as multicast, multimedia, voice/data integration, and others. Include potential competitive benefits.
  
  

Calculating Total Costs

In terms of the financial analysis of the migration, costs include all outlays of money for equipment and software, personnel, and non-personnel recurring costs that are a direct result of the migration from Token Ring to Ethernet.

Equipment and Software

• New wiring and wiring adapters—Calculate the cost of new wiring and wiring adapters that will be required as a result of the migration. Be sure to read the Cabling section of this paper before doing this calculation.
  
  
• New Ethernet NICs—Calculate the investment in new Ethernet NICs. Note that many PCs and laptops come equipped with Ethernet interfaces today. Therefore, only include NICs that will need to be explicitly purchased as a result of the migration plan. Be sure to include new server NICs that will be attached to the backbone. 10/100-Mbps NICs are available for $15 to $20, while gigabit NICs are roughly $700.
  
  
• Wiring closet equipment—Calculate the total investment in new Ethernet switches for all wiring closets involved in the migration. Be sure to calculate the cost of the appropriate high-speed uplink for attachment to the backbone (that is, ATM, Gigabit Ethernet, other). A rule of thumb is $50 to $75 per switch port.
  
  
• Campus backbone equipment—Calculate the total investment in new equipment to build the campus backbone. Be sure to include the cost of any incremental routers if you plan to maintain dual backbones and route between them for some period of time.
  
  
• Data center equipment—Calculate the cost of new host interfaces and other modifications that need to be made within the data center to accommodate the new infrastructure.
  
  
• Network management software and equipment—Calculate the cost of new network management tools.
  
  

Personnel

• Training—Calculate the near-term training costs for building an Ethernet skill set in the existing organization. Note that future new hires will almost always be familiar with Ethernet.
  
  
• Consulting—Estimate the cost paid to outside consultants or temporary help for planning, implementing, and testing the migration.
  
  
• Implementation—Estimate the total effort of in-house personnel for the project, including planning, approval, design, procurement, testing, and installation. Be sure to include travel and related, direct costs.
  
  

Non-personnel Recurring Costs

• Equipment maintenance—Calculate the total hardware maintenance for all new equipment deployed as a part of the migration project.
  
  
• Software maintenance—Calculate the total maintenance for all new software deployed as a part of the migration project.
  
  
• Depreciation—Calculate the depreciation expense that will be carried on the books for the new equipment.
  
  

Case Studies

This section presents four case studies of Cisco customers who are either currently migrating from Token Ring to Ethernet or who have completed the migration. The case studies illustrate the factors that were most important in making these particular business and technology decisions and highlight some lessons learned by organizations that are actually in the process of migration.

Because of competitive issues and financial confidentiality requirements, the companies are not identified by name, and in some cases details have been changed somewhat to ensure anonymity. However, the rationale provided for the migration, the overall plan of migration, and the lessons learned are accurate and based on the real-life experiences of these firms. Input for these cases was gathered at both the technical and the executive level in the IT organization.

Multinational Computer Company

The firm has operations in many major countries. The computing resources are distributed, with major data centers, regional processing centers, and branch offices spread throughout the world. Networking comprises approximately 25 percent of the overall IT budget. The majority of the LANs are deployed with Token Ring; Ethernet represents a small but growing percentage. Most Token Ring LANs are shared, with an average of about 50 users and a few servers on each ring. Many of the buildings are wired with STP cabling. (In some European locations, cabling changes would require government approval because the buildings have monument status.) Campus backbones are based on FDDI and ATM. Gigabit Ethernet is emerging in some campuses.

The current Token Ring infrastructure has performed exceptionally well and is very reliable. Maintenance costs are considered minimal. Much of the installed Token Ring equipment has been fully depreciated. However, the firm is beginning to feel that the current infrastructure is holding it back. The servers are bandwidth-constrained and some user rings are near capacity in bandwidth. The firm wants to deploy IP multicast applications within the next 18 months and wishes to put in place an infrastructure that will be extensible for other future applications.

With the advice of the CIO, a corporate directive was issued that there would be no new campus Token Ring or ATM deployed. This decision was made without the benefit of a detailed cost and ROI analysis. It was made based on the judgment that:

• Token Ring technology is at the end of its life.
  
  
• Token Ring and ATM products cost more than Ethernet products and will continue to do so.
  
  
• New networking applications will be increasingly more difficult to support on Token Ring.
  
  
• The company cannot compete as a leading-edge company with an obsolete infrastructure.
  
  

Based on the directive, the IT organization has decided to implement a multiyear migration plan from Token Ring to Ethernet. Because of the prohibitive costs of a "forklift" upgrade from one technology to the other, the migration will be phased. Desktop PCs are normally refreshed on a three- to five-year time frame. New desktop PCs come equipped with Ethernet. Therefore, the desktop refresh will be coordinated so that a single branch or wiring closet can be converted all at once, "overnight." STP cabling will be utilized in existing locations whenever possible. All new wiring will be Category 5 UTP. The standard desktop will have a 10-Mbps or 100-Mbps switched connection. Servers will be equipped for 100-Mbps or gigabit connections.

The IT organization has decided that the new campus backbones to support the Ethernet users will be based on Gigabit Ethernet. It did not consider using ATM at the backbone (which would accommodate both Token Ring and Ethernet) because of the complexity of this approach and the inherent risks associated with disturbing the running "live" network. ATM was also inconsistent with the corporate directive against new ATM deployment. Therefore, the existing backbone supporting the Token Ring users will be kept in place while there are still Token Ring users at a particular campus. Routers will provide a connection between the new backbone and the existing backbone to ensure complete interoperability.

The three platforms planned are the Catalyst 3500 in the access layer, the Catalyst 4000 in the distribution layer, and the Catalyst 6000 in the core. The Catalyst 3500 Series XL is a scalable line of stackable 10/100-Mbps and Gigabit Ethernet switches. The Catalyst 4000 Series is a modular, advanced wiring closet switch that provides flexibility and investment protection. The Catalyst 6000 family is a high-performance, multilayer switching platform for campus networks. All of these platforms may appear in a large site network, whereas only the Catalyst 3500 and, perhaps, the Catalyst 4000 in smaller sites. See Appendix A for additional details on the platforms selected.

When asked what lessons were learned as a result of this migration, the IT staff indicated that it is their opinion that organizations facing a similar migration should partner with an outside service organization that has gone through the process before. It is their opinion that this will help avoid some common pitfalls and keep the process moving relatively smoothly.

U.S. Bank

This banking firm has almost 100,000 users spread throughout much of the United States. It has ten regional processing centers and four traditional IBM mainframe data centers. SNA is a dominant protocol throughout the network. The firm has more than 1000 Novell servers and therefore has a lot of IPX traffic as well. TCP/IP has been growing over the past few years, and there are small pockets of LAT, DECnet, and AppleTalk.

Shared Token Ring LANs connected to campus FDDI rings have been the common campus environment. Token Ring was installed from the mid-1980s until 1997. New installations since then have been Ethernet. The majority of wiring is Category 5 UTP, although some STP exists on the East Coast. New campus backbones are Fast Ethernet, with some interest in Gigabit Ethernet.

The Token Ring networks have been very stable and low maintenance. The ring size limitations of Token Ring are a minor problem. The major problem being felt right now is that the existing infrastructure cannot keep up with the growth and the increased performance required. The IT staff also believes that future applications (for example, multicast IP and VoIP) will be important and will be difficult or impossible to implement on the current infrastructure.

The decision was made to migrate to Ethernet as rapidly as possible. However, cost is a major concern and a major factor. Therefore, new investment will be spread over time. There is no specific time frame for the migration; it will occur as the resources are available. The firm did perform an exhaustive cost analysis before making the decision. The details of the analysis are confidential, but the firm estimates that it will cost approximately $300 per user to complete the migration (not including Ethernet NIC cost, which is paid for out of a separate budget). The standard desktop will be connected to a switched 10/100-Mbps Ethernet switch port. Servers will be moved into a server farm configuration and attached directly to the backbone. The backbone for the new Ethernet users will be Fast or Gigabit Ethernet. Interoperability with existing FDDI backbones will be achieved through routing between the two backbones.

This firm is deploying Catalyst 1924 switches in the branches and Catalyst 6500s in the large sites. The Catalyst 1924 is an extremely cost-effective Ethernet switch suitable for branch office configurations. The Catalyst 6500 series is a scalable, high-performance, multilayer-switching platform suitable for campus networks. The firm began the migration project using Catalyst 5500 switches in the large sites, but switched to the Catalyst 6500 when it became available. See Appendix A for further information on the Catalyst products selected.

When asked what lessons the staff had to share with organizations considering a similar migration, the Vice President of IT was unequivocal. He stated: "Don't drag your feet. Get it done as soon as possible. Mixed environments are a bother to support."

Major U.S. Food Manufacturer

This company is a major international manufacturer of biscuits, snacks, and grocery products and markets a variety of food products in more than 85 countries worldwide. The company's Token Ring network was a classical collapsed-backbone network with FDDI connections between routers. The network was installed in 1992 using Synoptics hubs and Cisco AGS routers and connected more than 6000 users worldwide at approximately 160 sites. Servers were Novell and network protocols were IPX, Novell NetWare, and SNA. After the LAN was installed, it ran very well with a minimum of problems, and users were quite satisfied with the network. The Synoptics Optivity product was used to manage the network.

In 1996, the company's executive management became convinced that the future lay in Ethernet, not Token Ring, and a plan was adopted to convert the network to Ethernet. This decision was reached on strategic considerations rather than specific ROI analysis, because management was convinced that a state-of-the-art network was required to ensure competitiveness. A budget of $6 million was allocated to the project.

The migration was accomplished by creating parallel Ethernet and Token Ring networks using the Cisco Catalyst 5000 family of switches. The networks were interconnected at Layer 3 using the Catalyst 5000 RSM router. Servers were moved to Ethernet first, with the desktops still on Token Ring. The company also upgraded its servers to Microsoft Windows NT as part of this migration. DLSw+ and TN3270 were used to make IP the only Layer 3 protocol on the network.

During 1996 and 1997, all of the smaller sites were migrated to Ethernet. With this experience under its belt, the company undertook a major effort in 1998 and 1999 to migrate the large headquarters sites. The headquarters consists of three sites containing approximately 3000 users.

The primary IT technical personnel responsible for this network offered the following suggestions for others considering or planning a migration from Token Ring to Ethernet:

• Design the new network using the latest technology to avoid subsequent upgrades to accommodate new innovations and applications.
  
  
• Pay close attention to researching the history and bug list of switch and router software prior to deployment to avoid "rediscovery" of known problems.
  
  
• Buy VoIP-enabled switches to allow the greatest flexibility for future applications.
  
  
• Ethernet autonegotiation can sometimes be a problem because of incompatibilities between NICs and switches. Set this manually until you are sure it works.
  
  
• Use PortFast on switch ports that connect Dynamic Host Configuration Protocol (DHCP) clients.
  
  
• To prevent future problems, purchase sufficient switch memory.
  
  

Large Health Services Organization

This organization is an integrated network of care-giving services featuring more than 70 sites, including hospitals with 1832 beds plus a full range of other facilities such as outpatient health care campuses, nursing centers, assisted living centers, primary care practices, urgent care facilities, ground medical transport services, mobile diagnostic vans, and health and fitness facilities. The organization also provides the region's only air ambulance, Level One trauma center, and organ transplant program.

The organization's current network consists of 35 sites located in three metropolitan areas and two states. These sites are both large and small. An example of a small site is a doctor's office with about 25 workstations. An example of a large site is a hospital with about 5000 users.

On the advice of a consultant and because of Token Ring's better performance, the organization installed a Token Ring LAN around 1989 in a classical hierarchical design using Ungermann Bass hubs attached to Cisco 7507 routers with Token Ring Interface Processor cards. The routers formed the classical collapsed backbone and were connected together with FDDI. Connection to the data center was via Switched Multimegabit Data Service (SMDS). The Token Ring network proved to be very reliable and, except for an occasional beacon because of misconfigured NICs, minimal problems were experienced.

Over a period of almost two years, the organization migrated its primarily 3270-based network to a PC and file server-based, LAN-connected system, with a Novell file server at every site. All sites did both Novell file and print sharing. Hospitals also had specialized applications for clinical care, finance, and insurance. The data center contained multiple mainframes, was the center of the network, and was also the aggregation point for the WAN. IP was the only protocol used between sites, which helped greatly during the migration.

In 1994 the organization installed a Token Ring MAN using Token Ring bridges from Racal and dark fiber to seven major sites in the area. All seven sites were migrated from SMDS to the Token Ring MAN. In the same timeframe, the organization's primary Token Ring equipment vendor, Ungermann Bass, went out of business, forcing a reevaluation of the network design. Although this was the primary factor influencing the decision to replace the Token Ring LAN with switched Ethernet, other factors included:

• Performance was becoming a problem with the Token Ring network.
  
  
• Because switched Ethernet was available by that time, the performance difference (10 Mbps versus 16 Mbps) was no longer a Token Ring advantage.
  
  
• Ethernet was seen as the growth path for the organization's network.
  
  
• The same consultant recommended the conversion to Ethernet.
  
  

No ROI study was completed; instead, the justification was based on these strategic issues.

Migration from Token Ring to Ethernet was performed using a combination of the techniques previously discussed: smaller sites (less than 100 users) were done by "forklift" upgrade, and mechanical work such as carpentry and rewiring were done "offline," for example, on the weekend and at night.

In the larger sites, parallel networks were implemented using existing routers. Dual Catalyst 5500s were used to interconnect the parallel networks during migration. Servers were moved first, then users were migrated one wiring closet at a time. The total budget for the migration was $2.4 million, with the biggest expense being equipment, then labor.

Some comments from the manager of the network include:

• A major recommendation is to set up a test bed for testing migration design and components. Thorough planning and testing are a must.
  
  
• Server configuration was almost always done wrong the first time (for example, frame size and duplex setting configured incorrectly).
  
  

Conclusions and Recommendations

The time has come for organizations with an investment in Token Ring technology to formulate a reasonable business plan for an orderly migration to a switched Ethernet-based network. The reasons are compelling and clear:

• Token Ring has lost critical mass and is quickly becoming an obsolete technology.
  
  
• High Speed Token Ring will never gain critical mass.
  
  
• The number of vendors providing Token Ring solutions is rapidly decreasing.
  
  
• The long-term costs will be much higher to maintain a Token Ring environment than an equivalent one based on Ethernet.
  
  
• Unlike Token Ring, Ethernet supports emerging technologies, networked applications, and gigabit speeds.
  
  

Therefore, the ultimate goal of the enterprise network migration should be:

• 10/100-Mbps switched Ethernet to the desktop
  
  
• Gigabit Ethernet backbone architecture
  
  
• IP as the only Layer 3 protocol
  
  

The big question that each organization must answer based on its own individual situation is how to migrate. Because it can be difficult to integrate Token Ring and Ethernet environments, the simplest approach is simply a forklift upgrade to Ethernet. With this approach, the Token Ring infrastructure is replaced, from the NIC up, with a switched, gigabit-capable Ethernet infrastructure. A forklift upgrade may be viable in certain environments, for example, when a user community is about to move to a new building. However, for many organizations a forklift upgrade is not practical. They must implement a phased approach, instead.

If a phased approach is necessary and the existing Token Ring infrastructure is operating satisfactorily, it is best to leave the Token Ring network alone and build a new Ethernet-based infrastructure. Implement Ethernet switches in all wiring closets and interconnect them using a Gigabit Ethernet link. Interconnect the Token Ring network to the Ethernet network using routers. Put together a plan to move workgroups one at a time from the Token Ring network to the Ethernet network.

Some organizations may decide that a slower approach to migration is necessary. To provide immediate relief for Token Ring LANs that are already bandwidth constrained, it may be reasonable for these organizations to implement new Token Ring switches as a tactical approach. However, any assumption that Token Ring will continue to meet the organization's long-term needs is probably short-sighted.

The network transport for SNA traffic should be converted to all-IP using TN3270 and Enterprise Extender (Cisco SNASw and IBM
CS/390). If data centers are involved, use a Layer 3 design to achieve the required level of redundancy.

In summary, Cisco recommends the following:

• Adapt, or convert, all applications to use IP transport.
  
  
• Do a forklift upgrade to Ethernet wherever possible.
  
  
• Set up a new, gigabit-capable Ethernet network for the switched Ethernet users and interconnect it to the existing Token Ring network via routers.
  
  
• If you are forced to keep Token Ring for a while, implement Token Ring switches as a tactical solution to gain performance. Consider a media-independent ISL backbone if necessary.
  
  

The key point, reiterated by end-user organizations and industry experts and analysts, is to get started today. Make the decision, gain the internal approval through financial justification, and decide on an implementation. The risk of waiting is too high to justify. If you wait until an upgrade is mandatory, brought about by a new strategic application that simply must be implemented, then you will invariably have fewer options, you will pay too much, and you will place your network at higher risk than if you begin the migration today.

Appendix A: Cisco Product Specifications

Token Ring Switches

Cisco has three industry-leading switches that support Token Ring: the Catalyst 5500/5000 (which has two modules, one supporting copper and one supporting fiber), the Catalyst 3900, and the Catalyst 3920. A brief summary of the specifications of these products is provided in Table 1.

The case studies demonstrated the application of four different Cisco Catalyst switching solutions—the Catalyst 1900 Series, the Catalyst 3500 Series, the Catalyst 4000 Series, and the Catalyst 6000 family (which includes the Catalyst 6500 Series). A brief summary of each of these solutions is provided in this section.

Catalyst 1900 Series

The Catalyst 1900 Series switches, available in Standard and Enterprise editions, provide industry-leading performance and Cisco end-to-end network integration at an exceptionally affordable price. Enterprise edition software enables the Catalyst 1900 Series to deliver unmatched network configuration flexibility and scalability through embedded Cisco IOS technologies, delivering comprehensive management and security, bandwidth optimization, networked multimedia, and virtual LAN (VLAN) support. A brief summary of the specifications of these products is provided in Table 2.

Key Features

• 1024 MAC address cache
  
  
• Web-based interface for ease of installation, administration, and management
  
  
• CiscoWorks device-management support
  
  
• Telnet and SNMP support for in-band management and a menu-driven, out-of-band management console
  
  
• Cisco Group Management Protocol (CGMP) for dynamic and selective forward routed IP multicast traffic to target multimedia end stations, reducing overall network traffic and reducing network disruptions
  
  
• Embedded RMON software agents that support four RMON groups and Switched Port Analyzer (SPAN) port for connection to RMON probe
  
  
• Support for up to four overlapping bridge groups to manage bandwidth and provide added security through broadcast control
  
  
• Cisco IOS command-line interface (CLI) (Enterprise edition)
  
  
• Cisco switch clustering technology enables up to 16 interconnected Catalyst 1900, 2900 XL, and 3500 XL switches—regardless of geographic location—to form a flexible, single IP-managed network
  
  

Catalyst 3500 Series

The Cisco Catalyst 3500 Series XL is a scalable line of stackable
10/100-Mbps and Gigabit Ethernet switches that delivers premium performance, manageability, and flexibility with unparalleled investment protection. This line of low-cost, high-performance switching solutions provides next-generation stackable switching through an independent high-speed stacking bus that preserves valuable desktop ports. Cisco's breakthrough Switch Clustering technology expands the stacking domain beyond a single wiring closet, enabling up to 16 interconnected Catalyst 3500 XL, 2900 XL, and Catalyst 1900 switches—regardless of geographic location—to form a flexible, single IP-managed network. A brief summary of the specifications of these products is provided in Table 3.

Key Features

• Switch fabric of 10 Gbps, forwarding rates of up to 7.4 million pps, and a maximum forwarding bandwidth of 5 Gbps, delivering wire-speed performance across all 10/100 ports
  
  
• Built-in Gigabit Ethernet ports accommodate a range of Gigabit Interface Converter (GBIC) transceivers, including the Cisco GigaStack GBIC and the 1000BaseSX and 1000BaseLX/LH GBICs
  
  
• Low-cost, two-port Cisco GigaStack GBIC offers a range of highly configurable stacking and performance options by delivering 1-Gbps connectivity in a daisy-chained connection or up to 2-Gbps connectivity in a dedicated, switch-to-switch connection
  
  
• Support for IEEE 802.1p technology for prioritization of mission-critical and time-sensitive application such as voice and telephony traffic
  
  

Catalyst 4000 Series

The Catalyst 4000 Series provides advanced enterprise wiring closet switching. The Catalyst 4000 Series provides intelligent Layer 2 services leveraging a 24-Gbps bandwidth architecture for 10/100/1000-Mbps Ethernet switching. The modular, three-slot Catalyst 4003 leverages the same feature set with identical software code base along with the same enterprise functionality as the Catalyst 5500/5000 Series in the wiring closet, delivering a consistent end-to-end solution. The Catalyst 4912G offers 12-port, dedicated Gigabit Ethernet switching. A brief summary of the specifications of these products is provided in Table 4.

Catalyst 4003 Key Features

• Three-slot modular chassis with hot-swappable power supplies (dual option)
  
  
• Modular Supervisor Engine for long-term technology protection
  
  
• Variety of alternate Fast Ethernet and Gigabit Ethernet switch line cards (hot swappable)
  
  
• Supports up to 96 10/100-Mbps Fast Ethernet ports, or up to 36 1000-Mbps Gigabit Ethernet ports
  
  

Catalyst 4003 and 4912G Key Features

• Powerful 24-Gbps switch fabric capacity
  
  
• Wire-speed 18 million pps throughput, 16,000 MAC addresses
  
  
• Consistent Catalyst 5500 Series enterprise software code image
  
  
• Intelligent multilayer Cisco IOS services (Security, Multicast, QoS)
  
  
• QoS (802.3x support, dual queues), VLANs (1.024)
  
  
• Security (TACACS+, port lockdown)
  
  

Catalyst 6000 Family

The Catalyst 6000 Family provides a high-performance, multilayer-switching solution for campus networks. It is designed to address the increased requirements for gigabit density, data and voice integration, scalability, high availability, and multilayer switching in backbone/distribution and server-aggregation environments. Coupled with Cisco IOS Software, the Catalyst 6000 Family provides the required infrastructure to support high-capacity gigabit switching and the multilayer intelligence to efficiently manage network traffic. A brief summary of the specifications of these products is provided in Table 5.

Key Features

• Scalable backbone densities for Fast Ethernet and Gigabit Ethernet, high-performance multilayer switching, and policy enforcement in the backbone
  
  
• Supports up to 384 10/100-Mbps Ethernet, 192 100FX Fast Ethernet, and 130 Gigabit Ethernet ports—the highest in the industry
  
  
• Multilayer switching scaling to 15 Mpps on Catalyst 6000 Series and 150 Mpps on Catalyst 6500 Series switches
  
  
• Exceptional scalability and price/performance
  
  
• Efficient intranet multimedia and multicast support through Protocol Independent Multicast (PIM), Internet Group Management Protocol (IGMP), CGMP, and GARP Multicast Registration Protocol (GMRP)
  
  
• Extensive QoS features to support mission-critical applications
  
  

Appendix B: Glossary of Terms

ASIC—(application-specific integrated circuit) Integrated circuit designs that are specific to the intended application, as opposed to designs for general-purpose use.

ATM—(Asynchronous Transfer Mode) A packet-switching technology developed to support both voice and data on a common network infrastructure. ATM uses 53-byte cells and can be transported on both LANs and WANs at a variety of operating rates.

beacon—A frame sent by a Token Ring NIC indicating that the NIC is not receiving valid frames or clocking.

collapsed backbone—A network design concept where backbone LAN segments are replaced with high-speed switches, hubs, or routers. The backplane buses of these devices replace the LAN segment that had previously been the backbone.

FDDI—(Fiber Distributed Data Interface) A shared 100-Mbps fiber token-passing LAN technology using a counter-rotating ring technique for fault tolerance.

HSTR—(High Speed Token Ring) A standard for 100-Mbps Token Ring technology.

IP—(Internet Protocol) The primary Layer 3 protocol in the Internet suite. In addition to Internet routing, IP provides fragmentation and reassembly of datagrams and error reporting. Along with TCP, IP represents the heart of the Internet protocol suite.

IPX—(Internet Packet Exchange) Novell's proprietary networking protocol.

ISL—(Inter-Switch Link) A Cisco protocol that enables full-length frames from multiple Ethernet or Token Ring VLANs to be transported simultaneously across the same Fast Ethernet link.

LANE—(LAN Emulation) The ATM Forum-defined process whereby an ATM network emulates a significant part of an existing IEEE LAN, specifically Ethernet and Token Ring.

LNM—(LAN Network Manager) IBM's PC-based Token Ring network management product.

MAN—(metropolitan-area network) A network spanning several sites within a metropolitan area or similar, relatively short, distances.

microsegmentation—The process of reconfiguring stations from a shared-media LAN to smaller groups using LAN switches.

NetBIOS—(Network Basic Input/Output System) A session-layer interface specification from IBM and Microsoft.

NIC—(network interface card) A card installed in an expansion slot of a PC that provides an interface to a LAN.

SNA—(Systems Network Architecture) IBM's networking architecture.

RIF—(routing information field) The field in a Token Ring frame that contains the ring and bridge information used for routing through source-route networks.

RMON—(Remote Monitoring) Network management agents that can be placed in network components to monitor, gather, and report (via SNMP) management information, such as traffic statistics, error alarms, events, history data, and topology information pertaining to the network segment being monitored.

source routing—A network routing technique whereby the route to be followed by a packet is specified by the source station. In Token Ring networks, stations typically discover the routes available to be used via broadcast explorer frames.

SRB