it will be called IP," says Scott Bradner, senior technical consultant, Harvard Office of Information Technology.
In part, that's becaus
e many networks are doing fine at the building or campus level with IP. With 100 Mbps as an upgrade to Ethernet (and Gigabit Ethernet in the wings), bandwidth is not an issue in most LANs.
But what about the backbone and the WAN, where bandwidth can be a crisis? Exploiting public ATM services would solve that problem -- but it also would create a host of new problems that all have to do with mapping today's routed, segmented, flow-controlled, connectionless IP world to ATM's point-to-point, connection-oriented world.
The problem with trying to run IP over ATM stems from the different natures of the two protocols. ATM is a link layer protocol, like Ethernet or Token Ring, in charge of moving data between two nodes connected to the same medium. IP is a network layer protocol that gets encapsulated within ATM cells for forwarding. IP is connectionless, moving individual datagrams from one host to another; it runs easily over broadcast media like Ethernet, where you don't need to set up and break down
circuits between source and destination hosts. ATM depends on point-to-point virtual circuits (VCs): Sending an IP datagram means setting up a circuit, breaking down the datagram into 53-byte cells (5 bytes of header and 48 bytes of payload), and shooting them across the VC; once the datagram is sent, the VC is taken down, and then the process has to be repeated for the next datagram. The trick to
using IP
over an ATM network is figuring out how to keep IP datagrams that are moving between two hosts flowing through the same ATM VC.
This should all be made easier by several emerging technologies that attempt to combine the best of IP and ATM. The two attracting the most attention are IP switching and tag switching. Tag switching, developed by Cisco Systems, is brand new and has not been deployed yet. Because Cisco is such a dominant player, tag switching will almost certainly be widely used. This technology is no easy trick. IP routing involves inspecting a number of fields in each
packet (at least source and destination, and perhaps a port number) and making some complex decisions about it, such as whether to filter it out, give it priority, or forward it. The processing power required to do all this gives IP routing some scalability problems. The line at the hotel desk can start backing up as patrons fill out registration cards and clerks check credit cards.
ATM, operating at Level 2, makes much simpler choices, basically just looking at the virtual circuit identifier (VCI) and forwarding the cell on the appropriate VC. That's one reason why ATM switches tend to be a lot more efficient than IP routers at high data rates. (Another reason is that ATM switching is hardware-based, while IP routing is software-based.)
However, there's a trade-off for ATM's speed: While the traffic is in the ATM network, you lose IP's decision-making intelligence. IP packets are being transferred reliably over ATM networks, in massive amounts. That's not a problem. But the ATM network lacks the
intelligence to make subtle distinctions between different kinds of traffic. That won't do for the emerging voice/data/video Internet/intranet of tomorrow. Different types of "flows" need different amounts of bandwidth. They have different tolerances for delay and packet loss. When network traffic consists largely of such specialized flows, it will be much more important to give them the special treatment they need. In addition, IP features such as network segmentation and the ability to quell broadcast storms will become more important as traffic volume explodes.
"Years ago, the industry transitioned from bridges to routers because we wanted the higher level of intelligence to build large meshed networks," says Todd Dagres, general partner with Battery Ventures (Wellesley, MA), a venture capital firm that focuses on the communications and software industries. "If we want to go back to Layer 2 switching for better performance, then the consensus is we need to try to preserve some of the things we got fr
om routing. Users aren't willing to throw that intelligence, control, error checking, and security away."
Hence the attraction of IP switching and tag switching, both promising but immature technologies. IP switching has been deployed, but its sales so far are minuscule. "It doesn't even show up on the map," says Dagres. Not on the sales map, perhaps. But it's there on the mind-share map. Everyone is claiming they have it or will have it soon. By the year 2000, according to Dagres, IP switching will be integrated into a variety of high-performance routers, ATM switches, and Gigabit Ethernet products and will hold 15 percent of that combined market.
Don't Fight, Just Switch
IP switching is basically IP routing intelligence controlling ATM switching (or potentially some other Layer 2 technology that offers multiplexing). The result is a device that can route or switch, depending on the traffic characteristics. Thus, IP switching complements rather than competes with ATM.
Th
e basic function of IP switching is to identify flows (or extended IP conversations). More precisely, a flow is a sequence of IP packets sent from a particular source to a particular destination and sharing the same protocol type (such as UDP or TCP), type of service, and other characteristics. The user can configure how many packets it takes before the IP switch controller says, "Aha! A flow!"
The IP switch controller is an add-on processor to an ATM switch, essentially a router with the switch. It can use ATM as the Layer 2 protocol, but it retains IP at Layer 3. For instance, it may be a Pentium PC running routing software. Once the IP switch controller has identified a flow, it asks the upstream node (from which the flow is coming) to label the flow with a new virtual circuit identifier. Then the traffic starts to flow into the ATM switch on a new VC. Independently, the downstream node can ask the IP switch controller to set up an outgoing VC for the flow -- meaning that the downstream node also rec
ognizes this as a flow. Once the flow is isolated to particular incoming and outgoing VCs, the IP switch controller instructs the ATM switch to make the appropriate port mapping in hardware, thus bypassing the routing software and its associated processing overhead. Thus, by mutual agreement, IP switches form a "bucket brigade," switching packets as fast as the ATM hardware can carry them. Only the first IP switch in line continues to examine IP header information. The rest of the IP switches look only at VCIs -- a much quicker operation.
Any packets that are not part of a recognized flow (about 20 percent of the bits on the network, according to Ipsilon Networks, inventor of IP switching technology) are simply routed by the controller to the appropriate port on the switch and sent to the next switch. There the process is repeated.
IP switches, because of the superior performance they can offer, will replace some backbone routers. IP switching will also enhance ATM "edge switches" that combine mul
tiple traffic streams into a single ATM pipe. IP switching will allow the edge switch to make intelligent routing decisions for different traffic streams rather than just dump traffic into fixed VCs. On private networks, IP switches will also be used in backbones and as edge devices. In addition, they'll provide broadband access to Internet service providers (ISPs). As an access device, an IP switch could, for instance, dump digital voice channels from a T-1 into fixed VCs while providing intelligent routing, security, and manageability for IP traffic. And finally, traffic can cross public ATM nets that have a virtual path service and still retain the VCIs assigned the private portion of the network; on the other side of the cloud, the switches can once again intelligently handle flows.
Vendors of ATM and frame relay switches, integrated WAN access hubs, and routers will all get into the IP switching game, says Dagres. In a typical ISP today, for instance, you might see an Ascend MAX WAN access hub, a C
ascade 9000 frame relay switch, and a Cisco 7500 router, says Dagres. By the year 2000, that ISP might have an IP switch that combines the functionality of all three products, or perhaps just the functionality of the router and the frame relay switch. If the ISP has moved up to ATM to connect its points of presence, the ISP might be using an IP switch that's the equivalent of today's Cisco router combined with an ATM switch from FORE Systems (Warrendale, PA).
IP switching is an immature technology today. A good many of its problems may be addressed by the year 2000. For instance, vendors might have developed a way of providing an equivalent for the end-to-end quality-of-service features of ATM. In addition, despite the IP switch's focus on bilateral flows, perhaps some means of setting up virtual LANs can be worked out. We will almost certainly have IP switching standards by that time -- something that's entirely lacking now.
A final problem with IP switching today is that it doesn't do anything f
or bursts of data too short to be identified as flows, and it may do unnecessary work for flows that are just barely long enough to be identified as flows but don't go on much past that point. Perhaps IP switches will learn to optimize performance by dynamically adjusting the flow-recognition threshold (the minimum number of packets it takes to be recognized as a flow).
Tag Along
The IP switch eliminates the need for a separate router. Not surprisingly perhaps, Cisco, whose routers handle about 80 percent of the Internet's backbone traffic, has developed a router-based alternative to IP switching:
tag switching
.
A tag is basically a handy label for an IP route. Although there are fundamental architectural differences between tag switching and IP switching, from the user's perspective they'll accomplish pretty much the same thing initially; that is, they'll both push traditional routing out to the periphery of the network, leaving pure ATM switching on the
backbone.
Cisco claims tag switching is more scalable than IP switching because multiple flows can be identified with a single tag. Each flow within the aggregate flow can have its own tag, too. Moreover, the process is recursive: Aggregates can be aggregated, and the "superaggregate" identified with a single tag. This allows the tag switch (e.g., a router with tag-switching capability) to perform a multiplexing function. When a combined flow reaches the demultiplexing tag switch, the tag switch strips off the aggregate tag and routes the subflows based on their individual tags. This lends scalability to the tag-switching architecture -- backbone routers between the multiplexing and the demultiplexing routers don't have to know about all those subflow tags. (Maintaining state information on lots of tags is tiring for a busy router.)
In contrast, each flow has to have its own VC all the way through an IP-switching network. In general, flows can't be aggregated because IP switching doesn't provide
any way to disaggregate them. Since some state information has to be maintained for each active flow, this architecture is less scalable than tag switching, according to Yakov Rekhter, a technical leader at Cisco. It would be easy to define an aggregation/disaggregation scheme for IP switching, but what you'd end up with would be tag switching, says Rekhter.
On the other hand, the whole idea behind IP switching is that there is very low overhead associated with a flow once it's handed over to the ATM hardware. That's what makes it more efficient than traditional routing. It's not clear to what extent maintaining state information is actually a bottleneck for IP switches.
When we look back from the year 2000, these arguments might sound like medieval discussions about how many angels can dance on the head of a pin. The big picture may turn out to be convergence of high-performance routers with IP switches.
"Just as switch vendors are adding routing functions through IP switching," says Dagres
, "router vendors are adding switch features like high speeds, lower cost, simplified administration, and quality of service. The IP switch market will evolve out of both the ATM switch and the router markets."
Perhaps IP switching and tag switching could even work together. "IP switching has a very strong emphasis on individual flows," says Rekhter. "Tag switching has individual flows as a special case."
Whichever technology managers adopt, they'll be happy to know that the combination of ATM and IP is already working well in a very demanding setting: MCI's Internet backbone. According to Vinton Cerf, senior vice president of data architecture at MCI Communications, "MCI is running IP on its 622-megabit ATM backbone right now. It works fine. The key is enough buffer space in the ATM switch to insure that it won't drop any packets."
That's significantly faster than most corporate backbones, and it points up issues that will have to be tackled as the century turns. Says Cerf, "I am concerned
that conventional routing may not work fast enough when we're running 1.2 gigabits or 10 gigabits in the backbone. You start to run out of gas in terms of how many packets you can pump through. That's why ATM will be challenged by IP switches during the next two to three years. And router and switch vendors of all kinds, I hope, are under some pressure now to deliver products that will actually work at high speeds."
Where to Find
Cisco Systems
San Jose, CA
Phone: (408) 526-4000
Internet: http://www.cisco.com/
Faster, Smarter Nets
