IP Switching & Tag Switching: Two Fast IP Strategies 1.0 Abstract In the quest for larger and faster networks, driven par- tially by the growth of the Internet, shared media is giving way to switching. The network layer protocols have remained IP, but instead of classic Ethernet, link layer technology such as switched Ethernet, fast Ethernet, and Asynchronous Transfer Mode (ATM) are beginning to provide the pipes in which IP data travels. To date, ATM has proven a difficult platform for IP. Although ATM switches are very fast, and provide an isochronous net- work upon which both voice and data can be sent, adop- tion of ATM in the IP community has been inconsistent. Two internetworking equipment vendors have introduced technology designed to overcome some of the drawbacks of running IP over ATM, and to enable users of IP to reap the benefits of fast ATM switching technology; Ipsilon, with IP switching, and Cisco, with Tag switching. This paper offers an overview of these respective mechanisms as well as an analysis of these two approaches in terms of some key issues important to internetwork designers and engineers. The paper assumes a general understanding of the IP protocols, switching, and ATM, and a familiarity with the issues associated with the Operations, Adminis- tration, Maintenance, and Provisioning (OAM&P) of high speed local and wide-area data networks. 2.0 Introduction 2.1 IP Networks Although the Internet Protocol (IP) is not new, the tre- mendous growth the Internet has seen over the past few years has resulted in more widespread use than anticipated in earlier years. Originally developed under ARPA con- tract in the late 1960s, the IP suite of protocols (TCP, UDP, IP, etc) have become the defacto standard for connecting computers both within and between organizations. Alter- native network protocols seem to come and go regularly, OSI and IPX, for example, while support for IP has gener- ally become the standard by which network implementa- tions are judged. Prior to the advent of the World Wide Web (WWW), the vast majority of Internet traffic consisted of electronic mail, file transfers, and interactive terminal sessions. The rise of the WWW and hypertext transfer protocol (HTTP) as well as the new ways in which people use computers have changed the response expectations and traffic charac- teristics. Much more real-time, or near-real time multime- dia-like data is being sent over IP networks today, and these new types of traffic are much more sensitive to latency and other indeterminate delays than the historical traffic. These new requirements, often called Quality of Service (QoS) have given rise to such things as Multicast, Resource Reservation Protocol (RSVP), and Real Time Protocol (RTP). In addition to new protocols, however, the increase in traffic and response requirements have resulted in demand for faster media. Switching, fast Ethernet, FDDI, and ATM have been developed to help satisfy the ever growing bandwidth demands of the Internet and IP networking community. 2.2 ATM ATM was originally intended to unify two common approaches to networking, packet switching and circuit switching. This would enable the simultaneous transmis- sion of voice, data and possibly video traffic over the same network, without one type of traffic having undue negative impact on another. ATM, also known as cell-switching, divides traffic into 48 octet cells, with a five octet header. Because different types of traffic may have very different packaging and transmission requirements, the ATM com- munity defined what are known as adaptation layers. An adaptation layer essentially maps a higher layer protocol into a form suitable for transmission in an ATM network. The pejorative description of this scenario is that ATM was designed to be equally painful for everyone to use, as it favors no traffic more than another. One positive element of the development of ATM has been the ATM/cell switch. Manufacturers such as Fore have created extremely fast switching fabric, capable of tremendous throughput by implementing the layer 2 paths entirely in hardware. Unfortunately, deployment of ATM has been slow, in favor of technology alternatives that may not offer as much potential, but that are available today and offer full support for IP. 2.3 ATM Versus IP LAN emulation and "classical" IP over ATM may be used to simulate a shared medium IP network on top of ATM. Both of these approaches have their drawbacks, such as lack of broadcast or multicast capability. More fundamentally, however, the traffic characteristics of IP tend to conflict with the dynamics of the connection-ori- ented ATM model. For example, the domain name service is a commonly used service, designed to allow hostname to IP address mapping. By default, DNS lookups use UDP datagrams, typically a single request packet followed by a single response packet. Over an ATM network, this short lived session would require an end to end call setup and teardown, which in real time will likely exceed that required for the actual data transmission. Van Jacobson, one of the principle developers of IP multicast services and the MBONE, has often pointed out the shortcomings inherent in ATM versus IP, particularly those associated with multicast. 2.4 The Rock Versus the Hard Place The problem, at this point, seems to be that IP is the standard for network layer data communications, ATM hardware is an excellent, high speed switching solution for voice and data networks but they do not work well together. With bandwidth demands ever-increasing, it would be nice to try to mate these technologies. In addi- tion, ATM has native support for QoS. Ipsilon Networks has addressed this problem with their IP switching products, Cisco followed shortly after with tag switching. These technologies are similar, in that they purport to allow IP users to reap the benefits of fast ATM switching technology without suffering the com- plexity of connection establishment, adaptation layers, and the other baggage of ATM. In the following pages, I will present an overview of these respective technologies, and analyze them in terms of a few key issues. 3.0 Key Issues 3.1 Scalability Scalability refers to the ability of a particular solution to evolve along with increasing or changing needs. For example, static IP routing is an excellent way to handle smaller, simple networks, but as the network grows more complex, the manual labor associated with maintenance of these static routes becomes intrusive. In other words, it does not scale. Similarly, cascading shared-media 10BaseT Ethernet hubs is a reasonable topology for light duty, single segment type networks. However, once traffic increases to much more than 30%-50% occupancy, more scalable approaches to traffic management will be neces- sary, such as dividing like traffic into switched segments connected through routers to a high speed backbone. A network architecture may be considered scalable if, as the number of users and/or amount and type of traffic increase significantly, the network can change to accommodate this growth incrementally, rather than requiring large-scale rework, and wholesale changes in technology. One of the primary scalability problems both of these technologies are attempting to address is the explosion of routing data required in the Internet today. It is very difficult to main- tain good performance in the critical core routing infra- structure of the Internet if each packet must be forwarded based on many megabytes of route data. As will be clear further on in the paper, each vendor has its own way of addressing this problem. 3.2 Performance Performance is difficult to measure objectively. In some cases, price/performance can be used to moderate some of the inherent subjectivity of performance. In this analysis, I am going to try to analyze performance without considering price. Because the scope of the analysis is two protocols designed to allow IP to take advantage of ATM- bandwidth switching hardware, we can compare the per- formance of the two protocols using this criteria. 3.3 Manageability Having the fastest network in the world would be of marginal utility if said network was difficult or impossible to manage. Management refers generally to OAM&P type of activities, including the identification and resolution of alarm and failure conditions. Today, many networks are managed using a Simple Network Management Protocol (SNMP) based manager such as HP Openview or Sun Net- Manager, but in some environments, particularly tele- phone companies, CMIP/TMN-based managers are gaining favor. CMIP ultimately may be the last vestige of OSI that retains some market share. The criteria for man- ageability is related to how easily the equipment in ques- tion can be incorporated into an existing managed network. 3.4 Interoperability Interoperability is one of the most attractive reasons for using IP protocols. It can be safely said that at the core, almost any device that implements TCP/IP per the relevant RFCs will interoperate properly with other systems. Unfortunately, interoperability is not so easily guaranteed these days. Along with greater demands on the network come new protocols exerting these demands. We have seen how different vendors support different versions of HTML, for example, requiring web designers wishing to support universally whiz-bang pages to essentially code up two or more entirely different sets of pages to work prop- erly with Netscape and IE. The interoperable alternative is to code to a standard HTML dialect, but this may limit the in-your-face appeal of the site. The same thing goes on with such facilities as QoS, multimedia, streaming audio and video, and the like. In addition, both IP switching and Tag switching incorporate custom adjunct protocols, which may or may not be supported by other vendors. This also contributes to the interoperability of the technology. 3.5 Openness Openness is related to interoperability, to be sure, but covers some specific cases that relate to only part of the interoperability problem. In particular, if there are custom, or non-standard protocols used in the technology, are these protocols publicly specified so that other vendors may adopt them if they wish, or are they unpublished, requiring the use of a single vendor in the network to gain the most benefit from the technology. 4.0 Tag Switching Analysis 4.1 Technology Overview In the process of standardization, Tag switching is evolving into MultiProtocol Label Switching (MPLS) and Cisco is working with the IETF to obtain recognition of this technology as a standard. Although there is some material available on MPLS, most of it is preliminary enough that I decided to analyze Tag switching as origi- nally documented by Cisco, rather than attempting to track the MPLS work-in-progress. This fits in well, as IP switching is also an invention of a single vendor, and one that the vendor would very much like classified as a stan- dard. Tag switching is a technology designed to improve forwarding performance in a large internetwork, incorpo- rate support for both unicast and multicast traffic, and to offer a platform upon which to build emerging network services. Ultimately, it lends credence to the old adage "There is no problem that cannot be solved by adding one or more levels of indirection." Indeed, the basis of tag switching is to enhance the large routing tables and heavy- weight forwarding algorithms of today with short tags that may be quickly looked up and acted upon. The two components of tag switching are forwarding and control. Forwarding refers to the actual act of packet forwarding based on the tag information inside a packet. Control incorporates the maintenance and distribution of tag forwarding information among a group of tag-capable network elements. 4.1.1 Forwarding Tag switches maintain a table called the Tag Informa- tion Base (TIB). This table is organized by incoming tag, and additionally contains sub-entries of outgoing tag, out- going interface, and outgoing link layer info. When an incoming packet arrives with a tag, this tag is used as an index into the TIB, and for each sub-entry matched, the tag and link layer info are replaced and the packet forwarded through the specified interface. In other words, unlike the destination-based routing used in standard IP, tag switch- ing uses a next-hop style arrangement, whereby packets do not necessarily carry enough information to be switched through to their ultimate destination (other than the Layer 3 header), but merely to the next switch. Unicast and multicast packets are handled in an iden- tical manner by tag switches, the only difference being that multicast entries in the TIB resolve to multiple sub- entries. 4.1.2 Control There are three tag allocation and distribution algo- rithms, downstream tag allocation, downstream tag alloca- tion on demand, and upstream tag allocation. Upstream and downstream refer to the end of the link at which the tags are generated. A switch using downstream allocation creates tag bindings that apply to incoming packets, while receiving outgoing bindings from neighbors. When a switch creates a binding between an outgoing tag and a route, the switch may update its network layer forwarding database with appropriate tag binding information so it can tag outgoing packets that arrive untagged. 4.1.3 Support for ATM The astute reader will have noticed by now that tag switching sounds very similar to cell switching, at least in terms of the handling of the VCI/VPI fields in ATM cells. To support tag switching over an ATM transport, one would merely store the tags in these fields in the cell header, and ensure that the appropriate TIB information has been preloaded into the ATM switch's tables. This brings up questions about other transport types. Where in the packet are tags stored? Clearly the classic IPv4 headers have no place for this tag information. The protocol offers three options: First, a tag header may be placed in between the layer 2 and network layer headers. Another option is to store the tag information as part of the layer 2 header, as would be done in an ATM transport. Another possibility is to place the tags in the network layer header someplace. Although many protocols may lack sufficient space for this additional information, IPv6, in particular, has included a field called Flow Label, which may be used for information of this nature. 4.1.4 Support for Multiprotocol Tag switching virtually sits between layers 2 and 3 in the OSI stack model, and therefore lends itself to operation in a multiprotocol environment. Because the additional information can sit inside either layer 2 or layer 3, or between them, in theory, there is no transport/network layer combination that would not be supported by tag switching. 4.2 Adjunct Protocols Distribution of control information in classic IP rout- ing is done using a protocol such as RIP or OSPF, which enables interior and exterior routers to build and maintain a forwarding table. Cisco defines a new protocol, Tag Dis- tribution Protocol (TDP) to distribute tag bindings within a tag switch network. TDP is defined in an internet draft, but I'll briefly describe how the protocol works. TDP uses a connection oriented reliable transport, and supports tag distribution, binding establishment and dis- establishment, as well as management of the TDP sessions themselves. A single tag switching router (TSR) may open TDP sessions with one or many other devices, and may exchange binding information with all of them. Once a TDP session is established between two devices, informa- tion may flow bidirectionally. Session keepalive is han- dled by TDP itself, rather than relying on a lower layer keepalive protocol. Once a TDP session expires, or is oth- erwise shut down, a TSR ceases to use bindings obtained from the device on the other end of the session. Obviously, if the device has failed, there is no need to send packets to it. Only when a group of adjacent switches build TIB entries that contain both incoming and outgoing tags, rather than the default forwarding information, can actual tag switching may take place. 4.3 Key Issue Examination 4.3.1 Scalability Tag switching is very scalable on a number of levels. Indeed, improving scalability over traditional network layer routing is perhaps the fundamental motivation behind the technology. To Cisco, a router equipment man- ufacturer, and the supplier of some of the largest backbone routers in use on the Internet, the problem people are bumping into with their equipment today is the bottleneck associated with packet forwarding. As I mentioned earlier, the size of the Internet routing tables have become tremen- dous, and these bottlenecks are largely problems of scale. Tag switching replaces this bottleneck by forwarding based on a table lookup using the tag as an index. The orthogonal processing of unicast and multicast data is also an advance in scalability. Multicast is some- thing of an afterthought in today's internetworking proto- cols, and support for it is a little spotty. As multicast has some real advantages in the transmission of multimedia streams, efficient support for this traffic model is another example of tag switching improving scalability. 4.3.2 Performance In a perfect scenario, an ATM switch that supports tag switching has exchanged tag bindings with its neighbors such that the vast majority of the traffic is being tag-routed through the ATM hardware, using VCI/VPI as the location for the tags. If this were to occur, the network would be exhibiting superior performance, at least for the flows travelling through this particular switch. In order to reach this scenario, however, lots of things need to happen. First, the routing information will somehow need to be transmitted to the switch. Allowing the switch to partic- ipate in an OSPF routing subsystem is one way to accom- plish this. Second, some provision for network layer routing will need to be made for those packets lacking tags, or flows in the process of being set up. Third, some traffic analysis may be necessary to determine whether multiple tags should be established for a given neighbor. Unless this is done, if there is a heavily used route to which traffic is routed from some number of disparate sources, congestion may occur on the switch with this interleaving of packets towards the same destination. Establishing multiple tags (really multiple VCIs) will allow more of the switch's hardware to be used, and avoid this potential bottleneck. Finally, tag bindings need to be shared with neighbor switches and routers using TDP or an enhancement to a standard network layer routing proto- col. It seems apparent that this optimal tag switching sce- nario would be difficult to come by. 4.3.3 Manageability Unfortunately, this area is poorly represented in the available material on tag switching. This is due, in part, to the nature of the documentation. This subject is rarely mentioned except in documents pertaining to an actual product. Based on experience with Cisco, however, we can make some assumptions about how a tag switch would be managed. Equipment running Cisco's IOS typically plugs right into an SNMP manager, and may be managed effec- tively right out of the box. It is likely that the management infrastructure of a tag switch or tag router would fit into this paradigm. It is not clear, however, what ability a man- agement station would have in manipulating tag bindings in the TIB. Particularly with the intricate setup required to achieve good ATM performance, it would be reasonable to allow some level of operator-interaction in establishing the TIB. 4.3.4 Interoperability Tag switching can be deployed in clusters, or autono- mous systems in IP routing terminology, such that tag routers on the borders exchange only Border Gateway Pro- tocol (BGP) with remote networks, but implement full tag switching internally. This allows a high degree of interop- erability, in that no network element outside the tag switching network need ever know that tag switching is taking place. Another type of interoperability that can be studied is the case of a large internetwork comprising tag switching equipment, but in multiple distinct routing domains. That is, the borders are capable of tag switching also. Tag switching across borders is facilitated by a stack of tags within a packet, rather than one. Border tag switches push and pop this stack of tags as packets cross borders. This is an elegant feature, however, if tags are stored in a size- limited area such as within an ATM VCI, clearly there is not a lot of room for a stack of tags. But limited to one or two deep, the facility appears to work properly. Finally, interoperability of a different sort is available with tag switching also. The ATM switch used for tag switching may also be used for garden variety ATM. Pro- vided some effort is made to separate the tag-space from the ATM VCI space (so that the tags may be stored in the VCI field). This can certainly result in more effective use of the switching resources, perhaps justifying a larger switch. 4.3.5 Openness Other than the tag switching algorithms which make up the bulk of the technology, TDP is required as an adjunct protocol to distribute tag information within a net- work. TDP has been specified in an internet draft, so one can assume that Cisco expects other vendors to freely implement it on their equipment. Indeed, for tag switching to be successful at all, it must be embraced by vendors other than Cisco, and put to the test in large scale networks such as the Internet. So, in this sense, tag switching is open. However, Cisco also wishes to sell tag switching equipment, so one can expect that protocols are published that allow tag bindings to be distributed to and from non- Cisco equipment, but that a fair amount of intellectual property is being developed for the packet forwarding engine that won't show up in RFCs. This is not an issue in the ATM environment, where the layer 2 switching algo- rithms are well known and preexisting. 4.4 Summary I see some conflicting objectives for Cisco in the development of tag switching. On one hand, widespread deployment of ATM switches as backbone routers could potentially erode some of the high end router business that Cisco owns today. On the other hand, they are hitting the wall along with everyone else in the Internet routing busi- ness. Until a major advance in IP routing performance is made, there will be limits to how much the Internet can grow. As a fast packet switching technology, tag switching is flexible, supports multiple protocols, and blurs the line between switches and routers, which, as the worlds big- gest, most successful router vendor trying to grow their switching business, is a very good thing. 5.0 IP Switching 5.1 Technology Overview Ipsilon Networks developed the IP switch to over- come what they perceive as the drawbacks of using IP over ATM. ATM is viewed as too complex, a poor plat- form for IP, and a technology that the Internet is largely ignoring, regardless of its merits. To gain the best of both worlds, they decided to throw away the ATM software, and attempt to use IP on ATM hardware. It is a novel idea, and I expect more of it acted as inspiration for the tag switching technology development than Cisco will admit. Through the addition of two new protocols, ATM labels may be attached to IP "flows" and the flow ultimately switched at ATM speeds. A flow can be a single connection between two ports, or a sort of aggregate pipe for traffic between all ports on the two end- points. An IP switch consists of an ATM switch and an IP switch controller. The switch controller is typically a high end UNIX machine running IP routing software, con- nected to the switch via an OC3 ATM link. In place of the standard ATM software, General Switch Management Protocol (GSMP) and Ipsilon Flow Management Protocol (IFMP) are used. GSMP is a control protocol that allows the IP switch controller to manipulate the ATM switch hardware. IFMP supports the actual association of IP flows with ATM virtual channels. 5.1.1 Flow Classification Flow classification is the key to effective use of the switch. Indeed, without flow classification, an IP switch controller is essentially a 1 armed router. There are many different types of traffic travelling over an IP network. Obviously, some of these will be more suitable for ATM switching than others. Short-lived, low volume sessions may not be worth it, and connectionless, UDP-style traffic is probably not either. An IP switch establishes a default channel with each of its neighbors on which it sends this lower volume data. By analyzing the traffic in a "flow", or connection, a decision may be made to switch the flow. This criteria may be customized by the owners of the switch. Once an IP switch has determined to switch a particu- lar flow, it allocates a label and forwards this information upstream using IFMP. At this point, however, the job is only half done. Assuming the upstream switch is IFMP- compatible, and chooses to accept the flow management advice, the packets on this flow will subsequently arrive with the assigned label. This scheme is similar to the downstream tag allocation algorithm in the Cisco technol- ogy. But, packets arriving on this flow will still be sent to the IP switch controller for network layer forwarding. True IP switching only takes place once the IP switch down- stream sends a flow label upstream to the original switch. Once this happens, the flow is routed directly by the ATM switching fabric without switch controller intervention. Flows are unidirectional. If a particular flow, say an ftp-data connection is being switched through the ATM fabric in the server to client direction, the TCP acks travel- ling in the client to server direction will be forwarded by the network layer routing software in the IP switch con- troller, and sent over the default forwarding channel. 5.1.2 Multicast Multicast services are supported by IP switching using the standard Internet Group Management Protocol (IGMP). However, ATM switches handle multicast traffic in a point-to-multipoint model, rather than the multipoint- to-multipoint assumed by Internet multicast. By establish- ing a point-to-multipoint virtual circuit from every source in the multicast group, a reasonable approximation of mul- ticast-to-multicast is possible. Within this constraint, flow management on a multicast flow does not differ from uni- cast. 5.1.3 Support for MultiProtocol As suggested by its name, IP switching is geared to IP networks, and the resulting algorithms and protocols are optimized for the single (IP) network layer environment. While offering support for multiple network layer proto- cols is often important to the marketing department, in practice, IP is being widely recognized as "necessary and sufficient," that is, if you support any network layer proto- cols, one must be IP, and further, if IP is supported, it may not be worth the trouble of adding additional protocols. While this is not a new idea for many of us, there are seg- ments of the computer industry that spent many years and millions of dollars trying to advance alternative network layer protocols. 5.2 Adjunct Protocols 5.2.1 IFMP IFMP is used in the same way as TDP in the tag switching environment. Although tag switching specifi- cally avoids the concept of flow, choosing instead to con- centrate on a router-style forwarding, the job these two protocols do in the ATM environment particularly is very much the same. IFMP incorporates an adjacency protocol, used to detect the identity of a peer and to synchronize state, and a redirection protocol, used to distribute flow labels. The adjacency messages are sent to a broadcast address with a TTL of 1, so the messages don't go further than a single hop. The redirection messages are sent as unicast mes- sages to a specific peer, as one would expect, also with a TTL of 1. Rather than using TCP as a transport, as TDP, IFMP is its own IP protocol, the adjacency portion having some lightweight notion of connection, while the redirec- tion portion operates in a datagram mode. Redirected flows must be periodically refreshed using an IFMP keepalive-style message, otherwise the flow is deleted. 5.2.2 GSMP GSMP is loaded into an ATM switch in place of all the standard call processing software. It is a fairly simple protocol, designed to allow the IP switch controller to take command of the ATM switching fabric at a low level. It runs over the ATM link connecting the switch to the switch controller. There are five classes of GSMP messages: • Connection Management • Port Management • Statistics • Configuration • Events An individual IP switch controller may control multi- ple ATM switches, but this requires a separate instantia- tion of the protocol, as the protocol assumes a single master/slave relationship. 5.3 Key Issue Examination 5.3.1 Scalability Like tag switching, IP switching can overcome some of the overhead of network layer routing at each hop by using ATM layer 2 routing for some portion of the traffic. In addition, flow analysis criteria can evolve as traffic pat- terns change, allowing potentially more data to be switched through the ATM fabric as time goes on. The similar treatment of unicast and multicast packets are also a step towards improved scalability. While this will become a factor in the interoperability and openness anal- yses as well, by publishing the switch management proto- col, any ATM switch that supports this protocol may be used without changing switch controllers. This allows an IP switch installation to incrementally upgrade their ATM fabrics as traffic requires. 5.3.2 Performance According to data presented by Ipsilon, a set of IP switches with proper flow classification criteria will per- form dramatically better than an equivalent router net- work. While the general rules for flow classification are intuitive, network traffic is so infinitely variable that there will be some loads that achieve much better performance than others. Also, if a link is crossing an administrative domain, and the other domain's border switch is using dif- ferent flow analysis criteria than yours, this particular link may never reach a high level of layer 2 switching due to the upstream-only, advisory nature of IFMP. That is the downside of such a flexible utility. Given that is a con- trived case, however, I would much rather have the flexi- bility to tune my own traffic than be limited to someone else's idea about what switchable traffic comprises. The notion of a host flow (type 2) allows traffic between two hosts that may not meet switching criteria on a connection basis but that do in the aggregate to take advantage of the faster path. It seems easier to get your traffic into layer 2 in the IP switching model than in the tag switching model, as in the latter, so much of building the TIB is left up to the charac- teristics of the network as a whole, while it would only take a few IP switches and the standard flow analysis crite- ria to have a reasonable amount of switched traffic. 5.3.3 Manageability Oddly, none of the IP switching reference material discussed manageability at all, other than discussions of GSMP which is limited to resource management between the switch controller and the fabric. I'll mention a possible management scenario for IP switches, and perhaps discuss it with Greg Minshall when he is in town later this quarter. The IP switch controller at the very least must have an SNMP MIB, which allows it to be managed by and send alarms and traps to popular man- agers. This MIB should provide an interface to the results of the adjacency protocol, the redirection protocol, and the network layer forwarding database and statistics. In addi- tion, flow analysis criteria should be manageable in real time, such that based on statistics collected by the network routing software, flow analysis may be tuned to the current traffic characteristics based on historical traffic data. With this, flow criteria could be changed dynamically by the management software, optimizing for new loads and traf- fic characteristics without operator intervention. 5.3.4 Interoperability An IP switch interoperates well with other switched devices, and in many cases would appear as a router. Ide- ally, however, IFMP will be supported by upstream devices and flow switching will occur. The ATM switch- ing component of the IP switch has had its existing call processing and any network layer protocols removed, so it is not capable to handling IP switching along with other ATM traffic. The switch is dedicated to IP. This may be a problem in some environments that wish to maximize their investment in ATM technology. This is mitigated by the ability to use any ATM switch that supports GSMP, allow- ing you to purchase a switch of appropriate size now, and move to larger one when traffic requires. It is possible that an ATM switch vendor may produce a switch that supports GSMP along with other protocols, enabling a switch to support IP and voice, for example. As long as the entities assigning VCIs were cognizant of each other, this should not be a problem. Ultimately, as an IP, and only IP, device, the IP switch is quite interoperable by today's standards. 5.3.5 Openness The IP switch is a very open device. The non-standard protocols are published, it speaks IP, and in many cases uses off the shelf ATM hardware. As more switch vendors support GSMP, and more upstream devices support IFMP, IP switching may gain a fairly wide appeal. The only thing that would disqualify it from some organizations is the lack of support for other network layer protocols. With luck, demand for this will decrease as the benefits of an IP-only strategy become commonplace. 5.4 Summary Ipsilon has developed a very interesting product with the IP switch. The amount of software required to use IP over ATM is extensive with LANE or MPOA, and the complexity of mating the two technologies underscores their conflicting characteristics. The IP switch simplifies this scenario considerably, grafting an IP layer 3 on top of the very fast ATM switching fabric. On the other hand, it could be described as a hack, and that in real networks, particularly backbones, the traffic is varied enough that flow management criteria becomes an impossible to manage task, and you end up with ATM- based 1 arm routers. In order to assure success in the very competitive internetworking marketplace, Ipsilon will require support from other, larger vendors. This has happened, to a degree, with many vendors supporting GSMP in their ATM switching gear. However, it will be the ability to consis- tently produce layer 2 flows in a real network with multiv- endor switching products that determines the success or failure of the technology, and to reach that point will require more industry support. 6.0 Conclusions Which way to go? Both of these technologies are new, and have little or no field time. From the technical descrip- tions alone, it is difficult to characterize market potential. 6.1 Tag Switching Environments If one needs to switch protocols other than IP, tag switching is of course the way to go. However, few proto- cols have the routing infrastructure that IP does, so to properly build and distribute tag bindings for other proto- cols may be challenging. Indeed, it is challenging for IP. If no ATM exists in your network, and you have a combination of shared media/switched ethernet, fast ether- net, and wide area packet networks of some sort, tag switching would likely be more applicable, assuming the tag protocols will be supported on these other layer 2 tech- nologies. 6.2 IP Switching Environments If one needs to build a wide-area IP backbone, IP switching is certainly worth looking at. It will be easier to realize benefit from your IP switches quickly, due to the flow analysis criteria. If I was building a switched back- bone from scratch, I would give the Ipsilon technology a hard look, but a side by side comparison is really neces- sary to determine which is more appropriate for a given internetwork. 7.0 References Stevens, W. Richard. (1994). TCP/IP Illustrated Vol- ume 1: The Protocols. Reading, MA: Addison-Wesley. Partridge, Craig. (1994). Gigabit Networking. Read- ing, MA: Addison-Wesley Newman et al. (1996). Ipsilon Flow Management Pro- tocol Specification for IPv4: Version 1.0[Online]. Avail- able: http://www.ipsilon.com/protcols/rfc1953.txt[1997, April] Newman et al. (1996). Transmission of Flow Labelled IPv4 on ATM Data Links: Version 1.0[Online]. Available: http://www.ipsilon.com/protocols/rfc1954.txt[1997, April]. Newman et al. (1996). Ipsilon's General Switch Man- agement Protocol Specification: Version 1.1[Online]. Available: http://www.ipsilon.com/protocols/ rfc1987.txt[1997, April]. Multi Layer Routing[Online]. (1997). Available: http://www.csl.sony.co.jp/person/demizu/inet/ mlr.html[1997, April]. Callon et al. (1997). A Framework for Multiprotocol Label Switching[Online]. Available: http:// www.csl.sony.co.jp/person/demizu/inet/article/MPLS- Framework-v2.txt[1997, April]. Doolan et al. (1996). Tag Distribution Proto- col[Online]. Available: http://www.internic.net/internet- drafts/draft-doolan-tdp-spec-00.txt[1997, April]. Rosen et al. (1997). Label Switching: Label Stack Encodings[Online]. Available: http://www.internic.net/ internet-drafts/draft-rosen-tag-stack-01.txt[1997, April]. Farinacci et al. (1996). Multicast Tag Binding and Distribution using PIM[Online]. Available: http:// www.internic.net/internet-drafts/draft-farinacci-multicast- tagsw-00.txt[1997, April]. Farinacci, Dino. (1996). Partitioning Tag Space among Multicast Routers on a Common Subnet[Online]. Available: http://www.internic.net/internet-drafts/draft- farinacci-multicast-tag-part-00.txt[1997, April]. Rekhter et al. (1997). Cisco Systems' Tag Switching Architecture Overview[Online]. Available: http:// www.csl.sony.co.jp/person/demizu/inet/rfc2105.txt[1997, April]. Newman et al. (1996). IP Switching and Gigabit Routers[Online]. Available: http://www.ipsilon.com/staff/ pn/papers/ieee_comm96.pdf[1997, April]. IP Switching: The Intelligence of Routing, the Perfor- mance of Switching[Online]. Available: http://www.ipsi- lon.com/productinfo/techwp1.html[1997, April]. Vendors, Cisco Begin Work to Standardize Tag Switching in IETF[Online]. Available: http:// www.cisco.com/warp/public/146/tag.html[1997, April]. Cisco Scales the Internet[Online]. Available: http:// www.cisco.com/warp/public/146/916_scales.html[1997, April]. Cisco's New Tag Switching Technology Fuses Rout- ing and Switching for Scalable, High-Performance Net- works[Online]. Available: http://www.cisco.com/warp/ public/146/916_tag.html[1997, April]. New Technology Fuses Routing and Switching for Scalable, High-Performance Networks[Online]. Available: http://www.cisco.com/warp/public/795/8.html[1997, April]. Will IP Switching Replace Routers?[Online]. Avail- able: http://204.254.77.2/ibmsu/iss31/network- ing.htm[1997, April]. Newman et al. Flow Labelled IP: Connectionless ATM Under IP[Online]. Available: http://www.ipsi- lon.com/staff/pn/papers/interop96.pdf[1997, April]. Newman et al. IP Switching: ATM Under IP[Online]. Available: http://www.ipsilon.com/staff/pn/papers/ newman0001.pdf[1997, April]. Newman, Peter. (1997). IP Switching: The Marriage of ATM Hardware and IP Control[Online]. Available: http://www.ipsilon.com/staff/pn/presentations/stanford97/ stanford97.pdf[1997, April].