ight jitter and delay control from the switch fabric, but not necessarily buffer- ing or scheduling. Ethernet-type traffic is required to be able to count on the switch fabric's ability to provide deep buffering and some rudimentary levels of scheduling. The available capacity (or bandwidth) of the switch fabric that is given by the technology and architecture upon which it has been designed is of paramount importance as it decides the context within which the switch fabric can operate and function properly and efficiently. It is unfortunately not an infinite number, as this would make designing a complete multiservice switch/MSR a straight- forward process. As we have learned in a typical implementation by industry leaders in earlier chapters, in order to enforce and monitor/manage the flow of traffic according to the industry trend toward SLAs that rely on QoS and class of service (CoS) approaches and where users are billed based on usage, a traffic manager must typically be positioned at the egress paths of the switch fabric to manage and shape the traffic. The traffic manager, which we revisit as a generic concept in the next chapter, either by itself or in conjunction with a network processor manages the outgoing traffic and hands it over judiciously to the MAC/PHY stage of line cards to be injected into the actual network. However, this model of using a traffic manager only at the egress path is not necessarily the only way. 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 278 NETWORK PROCESSORS THE REDUNDANCY OF SWITCH FABRICS Bordering the scalability problem and entering into the territory of reliability and/or availability, we briefly discuss how to go about adding capacity and/or redundancy in a switch-fabric-based system. Several approaches can be taken: At the switch fabric design level, more ports per chip could p