, we just start rolling all prefix blocks one by one (that is, shorter-prefix blocks that must be located in an orderly fashion below the new entry) downwards one memory slot at a time in order to open up one slot space for our new entry. The number of prefixes determines the amount of time it takes. Latency on an update operation becomes prohibitive for the intended wire-speed performance of the design. For example, if we have a 100 MHz TCAM-based device where the clock cycle is 10 nanoseconds, then this is the amount of time it takes to conclude one lookup operation. Now if there are 64,000 prefixes, as is usually the case, and these must all be relocated by one position to lower memory positions in order to allow a new clumsy entry, then such an update of the table according to this method will consume the following time: 10 nanoseconds X 64,000 = 640,000 nanoseconds = 640 usec = 0.6 milliseconds If this system is an application, for example, on an OC-192 link with small packets (40 bytes), then to achieve an equivalent rate of 31.25 million packets per second (Mpps), there would be a need for: 31.25 18.75 18,750 packets These packets would need to be buffered temporarily (multiplied by the size of the typical packet we chose, which yields 750K bytes of extremely fast and expensive buffer memory) while we wait for the table update to conclude. If this process happens too often, then the buffer estimate is not even close to being enough, as new packets will continue piling up while others are still lined up in the buffer awaiting treatment. This will continue until we are forced to discard the new ones. To avoid causing too much disruption, some designs intersperse a few empty positions between prefix blocks in case new entries must be inserted. This approach has many variations, and several interesting algorithms have been proposed to that effect. Their performance has been studied and ana- lyzed in terms of the number of clock cycles they require for the insertion and deletion of an entry into a table. One of