 which we discuss in Chapter 17, "Security Coprocessors," traffic man- agers are proposed in either one of two major architectures: look aside and flow through. In the look- aside approach, the traffic manager shares some functionality with the network processor. More specifically, they can share the same packet buffer memory and even the same buffer management function. In the flow-through approach, all the required modules out of which the traffic manager con- sists are laid out in a pipeline-like fashion and treat the incoming information in a sequential way, like in an old-fashioned assembly line. Each TM submodule receives packets from one side, processes them accordingly, and outputs them on the other side to the following TM submodule. The requirements for traffic managers depend on the nature of the network in which they are called to function, as shown in Table 15.1. This means that not all traffic managers are able to offer the same level of help in every single type of envisioned network. In fact, some may not even be able to func- tion in all possible settings. Consequently, this is an area where vendors have tried to differentiate themselves by capitalizing on the types of networks where they already have an advantage. This particularly true for vendors who also propose network processors and/or switch fabric chipsets, they try to promote one-stop shopping for their customers. Conversely, customers often find them- selves confronted with the dilemma of choosing a superior traffic manager from another vendor or making their systems life easier by simply opting for the traffic manager of the same chip family with their choice of network processing unit (NPU) or switch fabric platform. Before we look at how traffic managers work, however, we first need to introduce some basic notions about their macroscopic functionality. We will then put things into context by stepping back one moment and looking at the QoS realm within which the traffic manager is called to perform intensive, complex, and noble tasks.