nization with all cards, be extremely circumspect about the thought of integrating the crossbar and queuing managers into one component, as this would completely negate the scalability approach of the architecture. This is a classic case where the economic need to integrate contradicts the modular future extensibility of a solution that is based on the arbitrated crossbar. Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. SWITCH FABRICS SWITCH FABRICS 285 Buffered Crossbar In the buffered crossbar switch architecture, the same principle is followed as shown in Figure 14.6. However, buffers will be placed on all three major stages, that is both input and output buffers as well as fabric buffers, right on the switch fabric card itself. With this approach, which is favored for instance by Vitesse switch fabrics, queues are naturally formed at each one of these 3 stages. At the output of every stage, some serious and coordinated scheduling must occur using RR or WRR or other sched- uling algorithms. Arbitrated Crossbar This approach is also based on the basic principle of Figure 14.6; however, as discussed earlier, arbitration scheme is implemented this time between the input queues and switch fabric on one side, and between the switch fabric and the output queues on the other side, if the specific fabric architec- ture requires output queues. VOQs are implemented in the arbitrated crossbar. They engage in a sim- ilar request/grant/accept handshake scenario with the arbiter that supervises access to the fabric core. The arbitrated crossbar has essentially three variations: one where the scheduling and arbitration are based on a centralized arrangement, another one that revolves around a concept of distributed switching, and a configuration like the one we showed in Figure 14.9, where a traffic manager is needed not only on the egress paths, but al