Tom Clark was with Nishan which McDATA acquired last year. It also acquired Clark, Nishan's director of technical marketing, who has become McDATA's director of SAN strategy. AS well as technology marketing at Nishan he wrote two books: 'IP SANs' and 'Designing Storage Area Networks', both published by Addison Wesley, and is now completing a third on storage virtualisation. It is expected to be published early next year.

McDATA has just announced its second SAN router, the Eclipse 2640, which re-emphasises the McDATA view that SAN routing is the better way to link SANs. Faults in any one component SAN are restricted in their effect to the component SAN only and not spread out into the whole interlinked set of SANs.

We asked Tom Clark to discuss other suppliers' approaches to linking SAN islands together. Firstly, he says that McDATA is ahead of everyone else in this field because the company has been doing it for longer; "We're in our 4.x release, i.e. the fourth generation. We've been in the market for two plus years and we have an edge."

What edge? "We have 2Gbit/s links between SAN islands with the 2640. It has four gigabit Ethernet ports which can be used for disaster recovery - SRDF, etc. - and for iSCSI attachment. We do wire speed protocol conversion for both. So we can support up to fifty SCSI devices per port - it varies with the application - and the 2640 has a limit of about 200." It's equivalent to a SCSI concentrator.

Thus the 2640 can be used for linking SANS together, for disaster recovery and also for SAN extension with iSCSI.

"There's a high level of interoperability: Brocade, even Brocade's proprietary mode; QLOgic; Cisco; and CNT's InRange." CLark believes there are weaknesses in other supplier's kit and approaches.

Cisco has its virtual SAN or VSAN concept. According to Clark the Cisco development sequence was effectively this: use FCIP for SAN extension; add VSANs for fault isolation; but you can't route between them so inter-VSAN routing has been tacked on. "It looks like batches of duct tape fixing stuff together. Why don't they use iFCP, which includes Network Address Translation (NAT) - key for SAN routing - which is what we do?"

Clark claims the VSAN implementation is restricted; "Cisco's SAN router still only works with Brocade. Our 2640 is in the qualification process with EMC, IBM and HDS. They say it outperforms anything else in the world."

CNT certainly has SAN extension products, but not SAN routing; "It has nothing like this (2640). It only offers SAN extension via FCIP; there's no routing capability. (Also) the InRange stuff isn't integrated with the SAN extension piece."

And Brocade? "Brocade is very weak on the SAN extension piece. It says to use CNT for enterprise SAN extension. It can't do wire speed over thousands of miles. It can't do iSCSI well; only five devices per SCSI port - we do fifty."

"The enterprise is very demanding. You have to function at wire speed. We build high bandwidth I/O into each port. We have foresight and insight and brilliant engineers and did it right first time. No one has been able to catch up with us yet with wire speed performance, the buffering, jumbo frame support, compression and bandwidth management. Customers move more data in less time over higher bandwidth and buy cheaper links (with us)."

Given that SAN routing is well understood at McDATA and in its fourth generation what is next? Earlier we mentioned that Clark is completing a book on storage virtualisation. He told us that storage virtualisation in the iSCSI area is "very interesting" and that iSCSI/Ethernet has different characteristics from Fibre Channel. Bearing in mind that the Eclipse 2640 does SAN extension via iSCSI and that McDATA has intelligent switch technology as a result of its earlier Sanera acquisition we might expect McDATA to launch products with iSCSI storage virtualisation features some time next year.

Perhaps we might even envisage virtualised pools of mixed Fibre Channel and iSCSI storage as well as virtualised iSCSI pools?