t from time to time through the fabric, no matter what higher-priority traffic is being mostly switched. In addition to the basic function of arbitration that we mentioned a little earlier, another important function inside the switch fabric is the scheduler. Scheduling decides from which port data must leave for the next step on their intended path. It is equally applicable to input queues for deciding which ingress port's data will be allowed to enter the fabric core and to output ports for deciding which egress port's data will be transferred to the traffic manager. Typical algorithms for scheduling are strict priority (SP), round robin (RR), weighted round robin (WRR), and weighted fair queuing (WFQ). Scheduling is also responsible for deciding (when necessary) whether one or more (and most impor- tantly which) packets must be dropped altogether due to lack of capacity. An ongoing debate among some switch fabric vendors exists regarding the problems that scheduling entails, especially if multi- ple levels of hierarchy are involved in shared resources. 14 This issue seems to be more of applicabil- ity in the context of arbitrated crossbars. We said a little earlier that the switching bandwidth of real-life switches is limited. This finite capacity imposes constraints into what one can realistically expect to accomplish in an entire switch- ing system design. Chances are that besides the implementation of VOQs at the inputs (which is irrel- evant to the possibility of having or not having queues formed also in output buffers), a traffic manager must also be placed at the ingress path next to the traditional NPU in addition to the traffic man- ager/NPU pair we have already come to expect at the egress path of the switch fabric. The reason why a traffic manager/NPU combination may be needed at the input of the switch fabric as well is that in order to maximize the usability of the available switching capacity, egress ports must not be starved by inefficient fabric core scheduling or by poor VOQ management while p