riority traffic does not get delayed at the input. In such an arrangement, as shown in Figures 14.9(a) and 14.9(b), switch fabrics appear commercially as a chipset of two components-one as the actual core of the switch fabric and the other as the combination of input-based VOQs and the potentially existing output queues. Provisions are available to handle the serialization and deserialization of traffic in both directions over the backplane using serdes devices. The QoS requirements of today's switches are of paramount importance in the minds of the switch fabric designers. More specifically, the logical segregation of traffic in classes, flows, and queues occurs. Each port has multiple queues and multiple classes of traffic are treated at different levels of priorities. Queues are usually structured on a per-flow basis, and flow control is handled by the switch fabric, which works in conjunction with the traffic manager. 14. The following is an interesting article summarizing the debate: Craig Matsumoto, "Startups Look to Supersize the Switch Fabric," EE Times (June 3, 2002). This article is available at www.eetimes.com/issue/fp/OEG20020603S0026. Make sure you read it critically, however. This is not because the arbitration logic is distributed SO that the arbitrated crossbars suffer, as implied in the article. If the arbitration algorithm cannot keep up with the requests of all the input queuing managers, the result will be crossbar throughput degradation, leading to poor output link utilization. If collisions occur in the core, the solution is the fabric-overspeed idea (invented years ago by Clos). Furthermore, it does not sound intuitively correct that a centralized scheduler would be more efficient than a distributed one. To our knowledge, PowerX was the only fabric vendor who had tried it, and it is now out of busi- ness. Also although the statements in the article about iSLIP are correct, namely, that guaranteed bandwidth cannot be provided by it in a large system, especially as it requires tedious synchro