gust 1999): 277-283. 17. A. Feldman and S. Muthukrishnan, "Tradeoffs for Packet Classification," Proceedings of Infocom 2000 3 (March 2000): 1193-1202. 18. T. V. Lakshman and D. Stiliadis, "High-Speed Policy-Based Packet Forwarding Using Efficient Multidimensional Range Matching," Proceedings of ACM Sigcomm 1998 (September 1998): 191-202. 19. P. Gupta and N. McKeown, "Algorithms for Packet Classification," IEEE Network Special Issue 15, no. 2 (March/April 2001): 24-32. 20. P. Gupta and N. McKeown, "Packet Classification on Multiple Fields," Proceedings of Sigcomm 1999, Computer Communication Review 29, no. 4 (1999): 147-160. 21. P. Gupta and N. McKeown, "Algorithms for Packet Classification," IEEE Network Special Issue 15, no. 2 (March/April 2001): 24-32. Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. CLASSIFICATION PROCESSORS CLASSIFICATION PROCESSORS 251 Packet Chunk 0 Chunk 1 Chunk 2 Chunk 3 Chunk 4 Chunk 5 Chunk 6 Chunk 7 index index index index Preprocessed index tables Classification result FIGURE 13.6 Flow through the RFC algorithm after a packet is split into chunks.20 IMPLEMENTATION A classification engine is a state machine, and it is only natural that it can be implemented in hard- ware, software, or a combination of both. The predominant choice of venue is dictated by the wire speed it must sustain and by the size of the table of rules. Low-speed and small-number-of-rules contexts are easily amenable to a software implementation on a reduced instruction set computer (RISC) CPU. The more these two parameters start becoming sizable, the more one is confronted with performance choking-hence, it becomes critical to engage more powerful implementations. Later in this chapter, we look closer at the question of whether a TCAM or a classification processor is required. If a classification processor is required, it must be determined whe