 that is not always feasible in real-life applications), one lookup can be accomplished in around 100 cycles (100 nanoseconds = 0.1 usec). Therefore, in one second, we can calculate that we can have 1/(0.1 usec) = 10 Mlps. This implies that the 1 GHz CPU is 100 percent dedicated to classification (an unrealistic proposition based on what we have seen elsewhere in this book). Even then, its performance should be compared with num- bers attained by current TCAM products as discussed in the previous chapter. The question, however, seems to still remain as to whether this structure is desirable in IPv6 environments. A more detailed discussion of these techniques would require us to describe the corresponding data structures and dis- cuss the efficient implementation of the algorithms, especially if they involve some clever architec- tural schemes like e.g. lookup tables, cache memory, etc. It is therefore beyond the scope of this book. For more information, consult the references at the end of the chapter. Perlman has invented a parallel hardware-based approach that seems to outperform any trie-based approach.¹ It requires a lookup engine that contains several parallel registers (called hash buckets) that function in a multiple-stage operation. Each stage of the lookup operation compares a portion of the destination address against the content of all hash buckets. The winner is the register that contains the longest match. The winning register at the end of the operation points to a data structure, which will hold the bit patterns that the registers will need to compare at the next stage. This parallel hard- ware approach drastically expedites the search. It obviously costs more to implement in silicon, but it allows the rapid acceleration of the lookup tasks. From a systems architect's point of view, algorithms used to implement lookup and forwarding operations are not surprisingly judged according to a short list of criteria that includes speed, instruc- tion memory footprint, the necessary data memory to run effic