ponent pieces, and deciding which ones will be implemented on the fast path (data path) and which ones on the slow path (control path). It is also a question of how to cleverly reorganize the protocol stack to ensure optimal processing and interfacing with other compo- nents and/or subsystems in the customer system's hardware, software, and firmware (drivers). 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. STORAGE NETWORK PROCESSORS (SNPS) 210 NETWORK PROCESSORS CASE STUDY 1: TREBIA NETWORKS' SAN PROTOCOL PROCESSOR (SPP) Trebia's SNP architecture, which is shown macroscopically in Figure 11.6, enables the company's flexible approach to be applied in several SAN applications. The company's SAN Protocol Processor (SPP) is a high-performance and storage-network-specific network processor that offers the flexible support of emerging IP storage technologies, which often must be seamlessly connected with legacy Fibre-Channel-based storage network infrastructures. When we say that SNP protocols are supported, we mean that IP storage protocols such as iSCSI and FCIP run natively on the SPP and at line rates, for example. An embedded, powerful, and feature-rich TOE completely removes the burden of handling the proper termination of multigigabits-per-second TCP flows from the proverbial shoulders of the host processor. As a result, plenty of processing horsepower is readily available for other critical storage network-processing tasks such as classification and security. Such a robust TOE approach is required for the efficient iSCSI termination in HBAs and endpoint devices. The Trebia SPP architecture is optimized for storage I/O flows. More specifically, it can process pipelined storage commands and provides low-latency IP and FCP flow termination. It is also equipped with multiple reissue features (for both the IP and Fibre Channel realms) that are