erformance eventually above 40 Gbps, AMCC realized early on that traffic management (a key foundation upon which a carrier can offer quality of service [QoS] and guarantees) cannot be fully integrated into one and the same silicon die with the network processor. Therefore, it adopted a chipset architecture, which is based on separate chips for the traffic manager as well as for the switch fabric. This physical separation allowed the company to pursue the optimization of these functions. AMCC realized early on that provisioning per-subscriber services requires many thousands of separate logi- cal queues and the ability to schedule these queues on an individual basis in order to provide guaran- teed access to network resources such as bandwidth. To illustrate the magnitude of the problem, consider, for example, the number of the queues required to handle the number of Digital Subscriber Line (DSL) connections that can be aggregated into an OC-192c trunk. For the sake of argument, assume that an average connection load has a rating of 0.5 Mbps per subscriber: 10.96 X 22,000 logical queues In order to provide these bandwidth guarantees, the traffic management engine must implement individual queues for each subscriber. AMCC has implemented a feature called per-flow queuing. This feature ensures that each traffic flow is managed as a separate entity. In other words, it is queued and scheduled independently from the other flows. It is impossible to integrate such a granular level of traffic management inside a network processor in hardware or software. However, service providers who must implement QoS contexts with different services and features as demanded by the market require such a granular level of traffic management. Congestion experienced by one flow is prevented from interfering with the traffic conditions of another flow. As a result, QoS is maintained. Traffic scheduling enables the hardware scheduling of traffic on a per-flow basis through the support of cell- and packet-based algorithms such as rate, stric