. Only a few years ago, we had 1Mb CAMs. Now essentially all leading CAM suppliers propose their 18Mb models. The need to store large tables inside CAMs has tradi- tionally been seen as a problem that is easily addressed by cascading multiple CAMs. For instance, a Border Gateway Protocol (BGP-4) routing table with 100,000 IPv4 routing entries takes two cascaded 2Mb CAMs from SiberCore or one 9Mb CAM instead. With 27 mm 296-pin and 27mm 336-pin PBGA packages for each one of the two chips, respectively, the real-estate savings become apparent. Likewise, a 1,000,000 entry IPv4 address table can be implemented in sixteen 2Mb CAMs or in four CAMs from SiberCore. 10 The footprint savings are obvious, if the parallel need for larger tables is considered. Inflexibility with table configurations is a very broad issue. Unfortunately, many current CAM products suffer in one way or another from this generic weakness. Some CAMs offer more flexibil- ity than others, and the systems designer should verify what features each product offers and how they map to an application. Some systems need tables that are different sizes, but cannot afford the CAM structures that support such a solution. Others need the flexibility at initialization time and less at run time. The reproach has some validity; therefore, time will hopefully make it less pronounced. New research and development will undoubtedly continue to improve CAM products in this regard. Most current systems designs are based on proprietary ASIC designs for the packet-processing engine, but it is expected that for flexibility and improved cost as well as time to market, this situa- tion will be changing rapidly in the coming years with the engagement of more standard off-the-shelf network processors. One of the highest priorities for the industry is to gluelessly interface the search engine with the NPU that will handle the classification and forwarding. The first CAM designs have not reflected that fact for historical reasons. The wider acceptance of network processors will