ent strategies, such that an ATM system cannot natively support IP forwarding. An example of the problem is shown in the highly simpli- fied scenario of Figure 13.3. In this example three routers are connected to an ATM network, which provides the transport infrastructure. B might have one physical connection, but over this connection two separate virtual circuits provide connectivity to A and C, respectively. (In a realistic network, router B would probably have Ethernet ports to stub networks not shown in the diagram.) In this simple scenario it is assumed that the ATM connections have been manually provisioned to provide the connectivity. Because the ATM and IP control planes are unaware of each other, it is not possible for A to know that it has a direct connection over the ATM network to C; instead, it sees B as its neighbor. The effect of this is that traffic passing from A to C has to pass through B, obviating the advantage of the fast ATM switching core. There have been many attempts to make ATM aware of the IP layer using architectures such as Classical IP over ATM (RFC 2225), LAN Emulation (LANE), and Multiprotocol over ATM (MPOA). The three stated techniques are in order of date of introduction and increasing complexity. In particular, it should be mentioned that MPOA helps to solve the problem shown in Figure 13.3. Using these systems requires an ATM management/control plane, an IP management/control plane, and an IP/ATM integration management system. Conse- quently, in practice it was found that these approaches were too complex and thus unpopular. Following the difficulties with ATM/IP integration, a number of vendors started work on solutions that provided either improved ATM/IP integration or switching systems for IP that replaced the need for ATM. Examples of the systems proposed are a cell-switching router from Toshiba, an IP switching system from Ipsilon, aggregate route-based IP switch- ing from IBM, and tag switching from Cisco. At the risk of oversimplification, one common theme among the so