In the early days of IP storage protocol development (all of three years ago), vested vendor interests spawned a protracted war between proponents of alternate IP-based solutions. Waged in the trade press, industry associations, and other venues, the contention between early variants of iSCSI, FCIP, iFCP, and other proposals sometimes generated a religious fervor, bordering on jihad. As further fuel to this raging fire, the hardcore Fibre Channel advocates opposed all attempts to develop storage over IP solutions, regardless of the sectarian disputes between the IP supporters.
After intense polemical skirmishes, the IP advocates finally agreed to work together in the IP Storage Forum of the SNIA (which at one point nearly became the iSCSI Storage Forum). As it turned out, the differences between the separate IP storage initiatives were substantial in terms of functionality, but certainly not worthy of divisions between technologists. Today, the SNIA has proven to be a productive common ground in helping to cultivate the value of IP-based storage solutions as a complement to mainstream Fibre Channel SANs. iSCSI, iFCP, and FCIP have all demonstrated their particular strengths, as validated by the confirmation of all three protocols by the Internet Engineering Task Force (IETF).
Lately, however, the civil relations within the storage industry among IP-based solutions have been challenged by aggressive marketing from a new entrant into the storage space. Not to name names, mind you, but a large internetworking company is attempting to mark its territory by dropping disparaging remarks about competing solutions at every opportunity. We’ll just refer to this vendor as Vendor X.
While it is common practice in any industry to bend the truth for the sake of competitive interests, breaking the truth outright requires a special disregard for both the industry and the customers it serves. All of which is to say the fear, uncertainty, and doubt (FUD) that was a common marketing tactic in former times of single vendor domination has unfortunately returned.
Page 2: iFUD #1: Join the Winning Team!
Join the Winning Team!
One of the “iFUD” arguments that is attempting to gain currency is the notion that Fibre Channel’s days are numbered and that it only makes good sense for customers to align with a vendor that already dominates mainstream IP networking. In other words, “Don’t keep buying from those dead-end Fibre Channel vendors; join the winning team, captained by Vendor X.”
The technical substantiation to this argument is that Fibre Channel, like early LANs, is a layer two (link layer) protocol, vulnerable to broadcast storms and other upheavals. The premise is that just as IP routing displaced bridged LANs, storage networks will soon jettison traditional Fibre Channel (FC) in favor of iSCSI and IP. So customers who buy Vendor X’s Fibre Channel products today will be positioned to migrate to the new storage paradigm, whereas the unfortunates who continue to buy from traditional Fibre Channel vendors will be locked in a link layer past.
This of course begs the question of whether or not Fibre Channel is truly a dead-end technology. At the current continued rate of adoption and increasing capabilities of Fibre Channel (including 4Gbps, 8Gbps, and 10Gbps speeds), there are no signs of weakening. Unlike IP networking, Fibre Channel is a channel architecture. Storage, in data center environments, is a channel application. High performance switching and minimal protocol overhead creates the most efficient means to move large volumes of data within a local environment.
The fabric reconfiguration and link layer broadcast issues associated with Fibre Channel really only appear when the technology is pushed beyond its original design specifications. Pushing native Fibre Channel beyond metropolitan distances, for example, may create problems, but new technologies such as SAN routing with fault isolation can deal with these. For properly designed data center installations, a channel-based link layer protocol such as FCP provides the optimum plumbing for enterprise storage transactions.
The tremendous value-add for IP-based storage, and in particular iSCSI, is to further amplify the benefits that have already been demonstrated by Fibre Channel SANs. Mission-critical business applications are better served by dual-pathed 2 Gbps Fibre Channel links running through five nines (99.999%) available Fibre Channel directors and a streamlined FCP link layer protocol. But enterprises typically have hundreds (in some cases, thousands) of second-tier servers and applications that could also benefit from SAN attachment. iSCSI offers flexible and very affordable options for connecting those platforms and extending the benefits of shared storage to a much broader server population.
So instead of sounding the death knell of Fibre Channel, iSCSI is validating and enhancing the value of Fibre Channel at the core, while creating new opportunities for customers to fully maximize shared storage as a corporate asset.
What advantage does this give Vendor X? None, really, considering that all the major Fibre Channel switch vendors have both Fibre Channel and iSCSI offerings. The winning team will be comprised of those who fully understand how the two technologies can complement one another and that can demonstrate truly useful business solutions.
As a customer, I would feel uncomfortable buying Fibre Channel products from a vendor that is simultaneously declaring Fibre Channel’s demise. I would feel especially uncomfortable if the vendor’s Fibre Channel products were based on a blocking architecture and unilaterally imposed proprietary frame tagging as a kludge for poor product design. The short of it is that I would have difficulty feeling part of a winning team.
Page 3: iFUD #2: Three Out of Four Doctors Recommend…
Continued from Page 2
Three Out of Four Doctors Recommend…
Another iFUDian argument that has surfaced lately centers on the virtues and demerits of FCIP compared to iFCP for linking SANs over distance. FCIP is a tunneling protocol, and so passes Fibre Channel fabric building protocols, simple name server data, and state change notifications between distant sites.
The problem with FCIP, though, is that it falls into the category of pushing Fibre Channel beyond its original design criteria. Creating one logical SAN stretched over hundreds or thousands of miles is not an especially good idea. A route flap in the wide area link or at one site can trigger a disruptive fabric reconfiguration on both ends. State change broadcasts can propagate across the WAN as well, causing disruption to ongoing storage transactions.
iFCP was deliberately designed to overcome these shortcomings of FCIP tunneling. The iFCP protocol includes an integrated networking address translation (NAT) mechanism that enables connectivity between independent SANs while blocking the potentially disruptive fabric building and state change broadcasts. From an engineering standpoint, iFCP is far more complex to implement in product, especially at wire-speed. iFCP was originally architected by Nishan Systems and is now part of the McDATA product offering.
Of the major fabric switch vendors, most have implemented FCIP for SAN extension, while only one supports the more robust iFCP protocol. The “three out of four doctors recommend” iFUD leverages this majority status of FCIP in an attempt to isolate and disparage iFCP. Do you want to be a lone ranger and use iFCP, or join the comfortable majority who, in their bulk, obviously have something good going with FCIP?
This majority rule for FCIP would have some credibility if it actually translated into something useful for customers. In reality, there is no practical benefit to customers but a very practical benefit for FCIP vendors. Despite the high price tag of many FCIP solutions, the protocol is fairly simple to engineer into products. Three out of four vendors are therefore benefiting from high margins with minimal product development, but this is obviously not being done for the customer’s sake.
One might expect that this majority status would translate into something tangible, like multi-vendor interoperability. Unlike iSCSI, however, FCIP and iFCP have not gone through the same rigorous interoperability testing process. During the requirements formulation for iSCSI within the IETF, the University of New Hampshire conducted regular iSCSI standards-compliance testing and the SNIA, through the IP Storage Forum, conducted periodic iSCSI interoperability tests and demonstrations at venues such as Storage Networking World (SNW). This helped ensure that as iSCSI became an official standard, products would already have achieved a reliable level of multi-vendor interoperability.
The FCIP and iFCP protocols did not undergo this process. Customers did not demand, and vendors certainly did not volunteer, to have interoperability between SAN extension products. As a consequence, although FCIP and iFCP are IETF-endorsed standard protocols, they are necessarily proprietary in implementation. As a result, Cisco FCIP only works with Cisco FCIP, Brocade FCIP only works with Brocade FCIP, CNT FCIP only works with CNT FCIP, and McDATA iFCP only works with McDATA iFCP.
The fact that three out of four vendors recommend FCIP therefore has no practical value for customers, any more than the three out of four drivers sitting behind the wheels of their Hondas have a particular advantage over the driver of the Toyota.
Page 4: iFUD #3: Betamax and VHS
Continued from Page 3
Betamax and VHS
At a recent conference, someone asked if iFCP might fade away, since despite being a more robust protocol for linking SANs, it is a kind of Betamax to the other vendors’ VHS solutions. The best technology, according to this particular iFUD, does not always win. This argument at least credits iFCP with being the optimum solution compared to FCIP tunneling, but also reveals ignorance of the history of video recording technology. Betamax did not fulfill the promise of its technological superiority because it was promoted as a proprietary architecture with premium profit margins. It failed to gain global dominance for the same reason that the IBM PC eventually succumbed to more open and inexpensive clones.
In the case of FCIP and iFCP, both are IETF-approved standards initiatives. Both are open protocols that any vendor can engineer product to. iFCP has significant advantages over FCIP tunneling, but also presents vendors with significant engineering challenges. At the same time, the fault isolation, SAN routing, and multi-point capabilities of iFCP have made a substantial impact on the market. Even vendors that are already committed to FCIP in their products are now declaring that they, too, will have some variant of iFCP-like SAN routing (e.g., Cisco VSAN routing and Brocade LSAN routing).
Considering the complexity of tacking different bits of code together (FCIP + proprietary frame tagging + proprietary network address translation for fault isolation) to achieve what iFCP already does in one standard protocol, it would have been much easier for FCIP proponents to adopt iFCP earlier on. In the current attempt to catch up on the feature/functionality front, however, FCIP is being bailing-wired to overcome the obvious deficiencies of simple tunneling.
In the end, this adds more expense, complexity, and code manipulation to FCIP products and validates the fact that iFCP was the proper solution for SAN extension to begin with. Given the fact that iFCP is both an open protocol and is now available at prices considerably below comparable FCIP solutions, it’s starting to look like the VHS winner after all.
Can’t We All Just Get Along?
Although technologists are not immune to fanatical allegiances, it’s really marketing excess that is driving iFUD in the storage industry. Technology development, after all, occurs within the crucible of capitalist economics and is spurred by those whose central obsession is market share and accumulation of profits. To meet their own business objectives, customers should remember that storage technology is simply plumbing to support upper layer applications and that the noise coming from the bickering plumbers down below, however distracting, may just be the clanging of empty FUD after all.
Tom Clark
Director, Solutions and Technologies, McDATA Corporation
Author: Designing Storage Area Networks, Second Edition (2003) (available at Amazon.com), IP SANs (2002) (also available at Amazon.com).
