nloaded 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. PACKET PROCESSING 56 NETWORK PROCESSORS bits and maybe whole packet headers most likely have already exited the switch and continued their trip downstream. The reader should be able now to see the trade-offs involved with the two design approaches. All incoming packets must undergo a deep examination by the switch that goes beyond the tradi- tional header inspection. Based on the results of such an inspection, the packet will be immediately classified to some class or category for subsequent processing. Therefore, the correct classification of packets may be implied by various needs. For example, a user may have to deal with making a specific routing decision (layer 3) for some packet based on some specific routing protocol, which may use the LPM algorithm based on a handy data structure called a trie. We will discuss this in more detail in Chapters 12 and 13. In the imple- mentation of address-prefix matching algorithms, the forwarding database that must be consulted gen- erally contains a dictionary of address prefixes. The algorithm is used to find the longest initial substring of the destination address that is included in the forwarding database. During a classifica- tion operation, the network processor (or ASIC, or other CPU for that matter, chartered to take care of the task) will traverse the trie looking for the LPM. We look at several approaches to improving this technique in Chapters 12 and 13. As we briefly discussed in Chapter 1, "The Evolution of Network Technology: Distributed Computing and the Convergence of Networks," with the arrival of MPLS, data flows are tagged by each router with a small route-specific label that is extremely reminiscent of ATM headers on top of IP traffic. It might be tempting to conceptualize about MPLS traffic as merely network load that must be routed/swit