ders are involved. A dedicated classification processor would immediately offload this function and therefore liberate these clock cycles from the network proces- sor SO that it can use them to do other useful work. The same problem looked at from a code-size standpoint shows that a RISC implementation of the application requires about 3,000 instructions, where 400 are classification related. A classification processor produces the result as a 32-bit tag attached to the classified packet. Processing that tag by the network processor usually involves about 30 instructions. Therefore, the code savings in this heavy-duty-classification example is 400 - 30 = 370 instructions. In a detailed example with meta- code showing the implementation for a simple content-inspection case such as the one needed for layer 7 web-based URL string processing, Welfeld shows that a multi-RISC engine must run at 1 GHz and be fully dedicated to classification just to produce the same results. A 100 MHz PSM-based clas- sification processor can produce these results much more easily. It is therefore safe to conclude based on what we have seen SO far that depending on the complexity of the application, the wire speeds required, and the available computational resources, the standalone classification coprocessor is more than a viable solution that often cannot be brushed aside by net- work processor vendors who purport that their chip can handle everything. CASE STUDY: RAQIA'S REGULAR EXPRESSION CLASSIFICATION COPROCESSOR Raqia Networks (whose technology has now been acquired by SafeNet) has looked at the overall clas- sification problem and realized that TCAM-based solutions can only handle applications where the number of classification-related instructions that need to be executed per packet is small and conse- quently the processing complexity of the classification needed is easily manageable. However, the higher we go on the protocol stack, the more complicated the classification becomes. When we are finally at layer 7 in load balancing