IP SANs and Metcalfe s Law

IP SANs and Metcalfe's Law

In theory, IP SANs will outperform on a cost/value basis their Fibre Channel fabric cousins within a comparatively brief period of time. Vendors arguing this position cite Metcalfe's Law, which states (1) that the value of a network increases as the number of nodes connected to the network increase, and (2) that growth in terms of network cost flattens out as more nodes are added. (See Figure 4-1).

Figure 4-1. Metcalfe's Law.

It is assumed that using IP as a storage interconnect will produce the same results as we have seen in local area networks. This remains to be seen. Another question that arises is which IP storage standard will predominate.

The IP Storage Working Group actually produced three distinct IP storage protocols. One is iSCSI, a mechanism for encapsulating SCSI commands and data into TCP and transporting the resulting packages across an IP network (see Figure 4-2). A second is Fibre Channel Protocol over Internet (iFCP), a method for encapsulating Fibre Channel protocol traffic under TCP and transporting it between Fibre Channel gateways in two or more FC Fabrics . The third approach, called Fibre Channel over IP (FCIP), involves the tunneling of Fibre Channel Protocol traffic between "island SANs" across an IP network link.

Figure 4-2. SCSI encapsulation in iSCSI.

This "alphabet soup" of IP storage protocols is explained by the differing underlying assumptions behind each specific approach. FCIP was the product of a temporary alliance forged out of necessity between FC SAN switch vendor, Brocade Communications Systems, and IP networking giant, Cisco Systems. In late 2000, the two companies, which had only weeks before taken turns dismissing each other's roadmaps for SANs, made an unexpected announcement that they would work together to devise a protocol for tunneling FCP across IP. The grudging agreement was the result of demands from several key customers of both companies that had deployed small FC fabrics and did not want to incur the expense of deploying additional FC links in parallel to their existing IP networks to interconnect the SANs.

FCIP was contextualized by Cisco (off the record, of course) as a tactical measure. Its benefit was straightforward: dual use of IP infrastructure to move storage as well as LAN message traffic. Its inherent shortcoming was also obvious: Joining two or more SAN islands together using FCIP created the equivalent of one giant SAN. Local identities of the SAN islands were lost. And, in the process of joining the fabrics together by this method, a customer ran the risk of creating a fabric that wouldn't work at all. The same issues that created pain for technicians in local multiswitch fabric deployments ”from switch interoperability difficulties, and zoning scheme conflicts, to HBA firmware- related problems and constraints ”would present themselves when joining remote fabrics across an IP-based local, metropolitan, or wide area network (LAN, MAN, or WAN). The distances involved in the overall infrastructure would compound the resolution of these problems.

Regardless of these deficits, work proceeded and the FCIP protocol was created, supported by a Cisco Systems switch blade ”and later given RFC status by the IETF. A scant 18 months later, the relationship between Cisco Systems and Brocade Communications Systems was broken off with all the acrimony of a Hollywood divorce.

Cisco cried foul when Brocade purportedly engineered the protocol for compatibility only with Brocade's switches rather than with all Fibre Channel switches. Each company went its own way, but ”also in good Hollywood fashion ” neither was willing to give up the last name "Systems."

In contrast to FCIP, iFCP was a protocol championed by a cadre of vendors who sought to bridge the FCP world and the IP world by introducing the concept of a IP-FCP gateway. The solution was viewed as eminently practical by companies such as Nishan Systems, and anticipated the SAN landscape that exists today.

Like FCIP, iFCP provided a way of transporting data to and from Fibre Channel storage devices using TCP/IP. Advocates describe it as the best of both worlds with TCP providing congestion control as well as error detection and recovery services, and FCP providing a robust serialization of SCSI commands and data. iFCP also enables the merging of existing SCSI buses and Fibre Channel fabrics into the Internet.

The iFCP protocol can be used as a wholesale replacement for FCP, enabling the construction of FC fabrics using Ethernet. However, it is more often proposed for use as a supplement to existing FC fabrics and as an alternative to FCIP. Advocates observe that using iFCP to interconnect "island FC SANs" provides a more robust solution than FCIP tunneling for companies that have already deployed FC fabrics. The iFCP solution preserves the integrity of each SAN island's switch and zone scheme, and is less prone to general failure after a connection is made ( assuming that iFCP gateways are compatible) (see Figure 4-3).

Figure 4-3. FCIP and iFCP architectures.

At this point, iFCP is being positioned as a migration tool for companies that are electing to move from FC fabrics to pure iSCSI-based over time. Switch- makers are beginning to support both iFCP and iSCSI protocols, a sign that FCP's star is slowly fading.