iSCSI, FCIP, iFCP ... and iFUD? Page 3
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.