cards, one OC-192 card, a master control CPU card, and a switch fabric card, in addition to power supply and extra backup features. Based on the figures shown here, there are 4X16X64X10 = 40,960 end users. If we assume 5 flows for each one of them, then we will have to manage 204,800 flows. With one queue per flow, the buffer management issue starts becoming clear. So how can we go about organizing the problem of managing these 204,800 active queues simul- taneously? We can perform one of the following actions: Logically split the traffic management function and distribute it to meaningful functional modules situated all over the MSR. More specifically, it can be distributed on the line cards as stand- alone traffic managers or as traffic manager work to be performed by the corresponding network processors. Concentrate it mostly on the central card (offering the OC-192 links in this case) that hierarchically dominates the network, and use commensurate standalone traffic manager chips. In order to combine the problem of traffic management with the switch fabric choice and config- uration, we must decide in this example whether traffic management must occur only on the egress (where traffic shaping usually occurs) or on both the ingress and egress sides of the switch fabric. Some trade-offs must be considered before making this decision. Creating these queues on the ingress side allows the implementation of virtual output queues (VOQs). Creating queues on the egress side usually allows the mapping of queues to multiple ports or channels for physical interface. Traffic man- agement implemented at the egress side takes care of shaping since packets are retained in buffers and are only released to the network based on specific QoS and SLA criteria. These criteria are imple- mented around two fundamental families of algorithms-algorithms that handle scheduling and buffer management. The functions of queuing and scheduling are inter-related and are required for the determination of transmission of packets as well as for