ct to the Terms of Use as given at the website. TRAFFIC MANAGERS TRAFFIC MANAGERS In realms where thousands of different applications may be simultaneously sharing the network, exhaustively compiling policies can be impossible. Two approaches can be taken: One approach is to not do anything, capitalize on cheaply available bandwidth and sharply drop- ping prices of gigabit routers, and hope that the backbone throughput will always be more than enough when spikes of demand appear. The problem with this approach is that no one can accu- rately forecast traffic loads in packet networks and major customers insist on preferential treatment for some of their key applications. This can only be achieved through SLAs, which can only be implemented when traffic is segregated into classes. SLAs stipulate the number of classes possible and the amount of traffic (bandwidth) allowed per class. SLAs can be static and therefore be nego- tiated at some predetermined frequency (monthly, yearly, and SO on), or they can be dynamic, which requires a signaling protocol such as the Resource Reservation Protocol (RSVP) for the application to request more resources from the network in quasi-real time. The diametrically opposite approach is to first define a limited number of specific classes of traffic and then assign individual applications to a class. All applications in one class of traffic receive the same treatment from the network. As the classes benefit from different treatment standards we can also talk about differential QoS. Carriers employ SLAs, which stipulate service level guarantees and consequently the levels of the net- work performance that the customer requires, expects, and pays for. This way carriers can also actu- ally guarantee the minimum assured level of performance. Traffic managers facilitate this process through a judicious use of traffic policing. More specifically, flow tables are stored in a memory sub- system with which the policer module of traffic managers works. In terms of classes of service, how many c