Fibre Channel interoperability: Are we there yet?
By Dave Simpson
As with any new interface, Fibre Channel poses daunting interoperability challenges for both vendors and third-party systems integrators, as well as for end users that want the flexibility of mixing and matching products from different vendors. Although significant strides have been made over the last year, the fact remains that the industry is still far from the promised land where any vendors` host bus adapter, disk drive, subsystem, switch, hub, etc., will work with every other vendors` devices.
As opposed to SCSI, which is typically configured in a relatively simple bus connection, Fibre Channel poses a number of additional hurdles. For one, it`s a storage and networking interface that, particularly in fabric configurations, can include a large number and variety of devices. "The main challenge with Fibre Channel vs. SCSI is that Fibre Channel is a network, and cabled SCSI is a storage channel," says Jerry Campbell, manager of systems at Ancor Communications, a switch vendor in Minnetonka, MN.
With many other interfaces, incompatibility problems arise when vendors add bells and whistles to differentiate their products while still adhering to the standard specification. However, that`s not yet the case with Fibre Channel because the industry is still in the first generation of product roll-outs, and vendors are primarily trying to differentiate in the management area, which doesn`t create interoperability problems at the hardware level.
In the current generation of Fibre Channel products, the problem is simple: The ANSI spec is open to interpretation. "Take a bunch of engineers with different sets of design tools and a varied set of management priorities, and ask them to implement according to a stack of paper. Some misinterpretations will occur, and there will even be deliberate decisions to not follow the standard," says Dal Allan, president of ENDL Consulting, in Saratoga, CA.
"There`s enough room in the standard for vendors to read different interpretations while still meeting the law of the standard," explains Mike Kane, senior product manager at Emulex, an adapter and controller manufacturer in Costa Mesa, CA. "Another problem is the sheer number and types of devices that can be linked in a Fibre Channel environment."
Interoperability problems can get worse as products hit the OEM stage, where new interfaces are seen as a way to get a jump on competitors, particularly third parties. OEMs usually require a lot of patches and revisions, and the vendors bidding for the OEM business are more than happy to make those changes by changing their microcode, for example. "Multiply this scenario by several OEMs and you can see how the same products from the same vendor start deviating between themselves," explains Allan. As a result, not only are products from different vendors often incompatible, first-generation products from the same vendors can even be incompatible.
How difficult the interoperability problem is may depend on the type of Fibre Channel configuration you`re considering. "The FC-AL [Fibre Channel Arbitrated Loop] configuration has been out there longer and is better understood. It`s more of a SCSI replacement market, and it`s easier to achieve plug and play," says Jim Morrin, director of market development and corporate planning at Computer Network Technology (CNT), a high-end connectivity device manufacturer in Minneapolis.
But Morrin says switched fabric Fibre Channel configurations can pose bigger interoperability problems. "Fabrics are more complicated because you have different protocols, such as SCSI for storage as well as, say, IP. As a result, the HBA [host bus adapter] has to be sophisticated in its driver software, and that also has to be coordinated with upper-level applications for backup or file transfer. A lot of different things can cause something to fail."
Unlike with SCSI, you can run multiple protocols--such as SCSI, IP and VI--over Fibre Channel, which can cause interoperability challenges. "When you add a network protocol like IP along with SCSI, interoperability becomes more complicated, especially because IP specifications are still being worked on," says Ed von Adelung, senior project manager at Interphase Corp., a communications equipment vendor in Dallas. The multiple-protocol issue may lead to more hurdles as switch and hub vendors add IP for network management across Fibre Channel fabrics.
Although no vendor argues that the industry has reached the stage of unfettered interoperability, they all agree that significant progress has occurred over the last year, and some even argue that the effort is proceeding much more rapidly than it did with SCSI more than a decade ago. "I`ve seen progress on Fibre Channel interoperability over the last year that took four or five years with parallel SCSI," says Skip Jones, director of planning and technology at Qlogic, an adapter and controller vendor in Costa Mesa, CA. "But the reason for that is we cut our teeth on SCSI interoperability, and the fact is that a good 90% of Fibre Channel implementations today are running the SCSI protocol over a single wire."
Not all of the interoperability problems occur at the hardware level. "About 50% of the time, the interoperability problems are at the SAN operating system level," says Nick Thickins, applications marketing manager at Eurologic, an enclosure manufacturer headquartered in Dublin, Ireland. "Interoperability isn`t just an issue with hardware devices such as hubs and switches; it also involves the operating system, drivers, and firmware."
Plug Fests promote interoperability
The progress made over the last year is in large part due to interoperability "Plug Fests," which are administered by the Fibre Channel Loop Community (FCLC) in conjunction with the University of New Hampshire. The Plug Fests usually take place at Interphase`s interoperability testing labs in Dallas. The next one will take place next month.
The Plug Fests enable a wide array of suppliers (see vendor list) to test their products in a lab environment. The University of New Hampshire`s InterOperability Lab (IOL) personnel establish the test plans and handle the on-site details of test operations, acting somewhat as referees among the vendors. (For more information on the Plug Fests, and technical details of Fibre Channel interoperability testing, see "FCLC Boosts Interoperability Testing," October 1998, p. 26.)
Testing at the Plug Fests concentrates primarily on error situations and corner cases that exercise an exhaustive number of error transition states. Root cause analysis is performed to isolate failure or non-conformance to a communication layer, with special emphasis on the link layer. (Fibre Channel allows multiple transport protocols to share the same link layer.)
Interoperability testing uses protocol analyzers from vendors such as Ancot (Menlo Park, CA), Finisar (Mountain View, CA), I-Tech (Eden Prairie, MN), and Xyratex (Newport Beach, CA). The analyzers allow test engineers to trap events and isolate error conditions, and to capture network events so that root cause analysis can be performed.
The FCLC recommends a horizontal approach to interoperability testing. "We advocate the horizontal approach because we want to stimulate innovation," says Howey Chin, an FCLC board member that heads the Interoperability Steering Committee. Chin is also chief strategic officer at Gadzoox Networks, a hub, switch, and gateway vendor in San Jose.
Chin explains the differences between horizontal and vertical testing: "The vertical approach focuses more on a single application and could ignore anything that doesn`t impinge on that; for example, an application that uses the SCSI protocol but doesn`t care about IP or VI, and may or may not use SAN services. Because of that, the vertical approach can create interoperability problems."
"With a horizontal, or layered, approach," Chin continues, "you define interfaces and contain a horizontal slice of the problem. As long as you define the interfaces, you don`t care what protocols run on top of the link layer [see diagram]."
Many of the perceived interoperability problems with Fibre Channel--compared to, say, SCSI--come from the fact that the spec encompasses so much more than the SCSI spec. For example, if a SCSI bus is broken, it`s broken; there`s no expectation of communications riding over a broken link. "Because the expectations are higher for Fibre Channel, the perceived interoperability is lower than with SCSI," says Chin. "They`ve both run a mile, but one is running a marathon and the other`s running a one-mile race."
Another outfit that has done a good deal of Fibre Channel interoperability and performance testing is Medusa Labs (www.medusalabs.com), a Georgetown, TX, third-party test organization that specializes in Fibre Channel, SCSI, RAID, and network testing. Medusa performs testing and analysis for vendors, systems integrators and end-user organizations.
Joe Mathis, president and CEO of Medusa, says the industry has made a lot of progress in interoperability since he began testing Fibre Channel products 16 months ago. "Initially, we had small pockets of interoperability through partnerships," says Mathis, "but now the vendors are trying to collectively grow the Fibre Channel market and they know that interoperability is required." Medusa uses its own proprietary tools for debugging and interoperability and performance testing.
Advice and consent
Advice on how to clear the interoperability hurdles depends on what camp you`re in. For vendors, the advice is straightforward: Solve your interoperability issues or risk losing business, because end users and systems integrators are increasingly demanding interoperability as they begin rolling out Fibre Channel fabrics and storage area networks (SANs).
For end users, the advice is consistent: "Test before deploying, and test with your actual application software," advises Eurologic`s Thickins.
Other players contend that, unless you want to become a test organization, use a third-party integrator or a large vendor that has tight partnerships, because those companies have already performed the interoperability testing. "My advice to end users is to use a systems integrator that`s well-versed in Fibre Channel," says Ancor`s Campbell.
The goal is to involve as few vendors as possible. "What`s important to end users is to have a single point of contact--one person with an `X` on their head that has to make it work," advises Emulex`s Kane. "There`s nothing worse than having three vendors, each saying it`s the others` fault that something doesn`t work."
Despite the current interoperability challenges, progress through efforts such as the FCLC Plug Fests suggests that the problems--at least those at the hardware level--will ease over the next year. "The last few months have seen dramatic improvements, and progress will continue at a steady pace until interoperability becomes a non-issue," says ENDL`s Allan. "This time next year you`ll be asking a different set of questions, probably about system administrative software or some other emerging issue, such as why the software for administering large fabrics is not compatible across vendors. The hardware problems you hear about today will have moved upstream to another point of integration, and companies will be trying to decide which software management tool is the best one to use. Compared to the past, this is all happening at breakneck speed."
For more information on Fibre Channel and interoperability issues, visit the Fibre Channel Loop Community`s Web site (www.fcloop.org) and the University of New Hampshire`s InterOperability Lab site (www.iol.unh.edu).
The multi-protocol Fibre Channel layers correlate to the ISO reference model.