Tip

IP SANs: Two standards too many?

IP SANs: Two standards too many?
By Jon William Toigo

One problem that IT professionals confront when they begin reading up on IP SANs -- the hot new storage networking topologies based on Gigabit Ethernet and TCP/IP -- is the issue of standards. The folks at the Internet Engineering Task Force have seen fit to bless us with not one, but three, IP SAN standards recommendations for protocols that can be used to build these wee beasties. All three Requests for Comment (RFCs) will be moving out of the IP Storage Working Group and working their way up the food chain at IETF over the next couple of months seeking ratification as formal standards.

To some, the diversity of standards is seen as a good thing -- April showers bring May standards, so to speak. To others, three standards for IP SANs are just two standards too many. To most, the proliferation of IP SAN standards is, in a word, confusing.

The "Big 3" contenders for IP storage

IP-based SAN standards, according to proponents at Cisco, IBM and elsewhere, describe true network protocols. That is to say, they are protocols for moving storage traffic that leverage an underlying network commonly called TCP/IP.

The three protocols soon to be ratified as IP SAN standards are:
1) Fibre Channel tunneling through IP (FCIP);
2) Native Fibre Channel operated as an application across IP (iFCP); and,
3) Native SCSI operated as an application

Requires Free Membership to View

across IP (iSCSI).

FCIP is widely viewed as a point-to-point tunneling protocol for use with Fibre Channel SANs. Specifically, it is viewed as a protocol to leverage a TCP/IP network to interconnect Fibre Channel-based "island SANs." FCIP was developed in response to companies who were deploying small FC SANs at a departmental level, but who had lost faith, ran out of money or otherwise decided not to field an FC backbone to connect the dots. Last Fall, they turned to Cisco Systems to find a way to link the SAN islands together using a ubiquitous IP network backbone. Cisco made a "tactical alliance" with Brocade Communications to enable a tunneling approach and FCIP was born.

Purists complained that tunneling didn't establish a SAN on a broader scale. They sought to enable Fibre Channel as an application that could be operated across the IP network with the full functionality of a SAN island FC deployment. Nishan Systems and others were early proponents of iFCP.

However, while all of these Fibre Channel-focused initiatives were under way, IBM -- which had first developed FC, then abandoned it in favor of Serial Storage Architecture (SSA) -- and others, including Cisco Systems, were asking the obvious question: "Why use Fibre Channel at all? Why not simply operate SCSI as another application over the TCP/IP stack?" The elegance of iSCSI, in concept at least, was the result.

Open standards, Fibre Channel and IP in the SAN box

Open standards -- that is, those articulated by a formal standards body -- are generally seen as preferable to proprietary technology approaches because they prevent customers from becoming locked into a particular vendor's products over time. In the best case, open standards establish a level playing field on which the products from different vendors compete on a price/performance/function basis -- usually to the benefit of the consumer.

However, as the Fibre Channel SAN debacle has taught us over the past three years, open standards do not guarantee interoperability between products from different vendors. As evidenced in FC SANs, open standards -- which are the product of months of argument and compromise between proponents representing proprietary vendor interests -- tend to leave considerable "wiggle room" in their specifications. Such wiggle room enables vendors to make proprietary implementations of the same standard. That explains why Fibre Channel switches, host bus adapters and controllers have a nasty way of dropping out of a heterogeneous SAN during operation -- rather like Christopher Columbus' little known fourth ship, the Titanica, which fell off the edge of the world.

The guys who write standards recognize the problems with wiggle room, but they figure that:
1) Consumers will eventually choose which vendor's implementation they prefer; and,
2) The market will eventually impose a kind of selective breeding -- favoring only products that work and play well with that particular implementation.

That's the way it was in the early days of Ethernet, the Fibre Channel Industry Association is fond of saying, and that is the way it will be with SANs.

Ah, but here's the rub. . .

The difference between Ethernet and SAN standards, however, is that Ethernet did not confront a plethora of standards coming out of the gate. In the realm of SANs, there is the still-evolving Fibre Channel standard, under the aegis of the T-11 Committee at ANSI, as well as three, up-and-coming, IP-based standards from IETF IPS Working Group.

In point of fact, the Fibre Channel standard isn't a SAN standard at all: It describes a serial interconnect between server and storage, and not a network per se. Since the FC standard does describe three topology options -- point-to-point, Arbitrated Loop, and Fabric -- it was pressed into service as a SAN standard in lieu of something that actually was a network. We have been struggling with the consequences of this ever since.

It remains to be seen which of the IP-based protocols will win the day, or whether they will each find a niche market. For the consumer of storage technology, one thing is certain. It will take time for the standards to shake out and for one standard and one implementation of the standard to become predominant.

About the author: Jon William Toigo has authored hundreds of articles on storage and technology and is our searchStorage.com resident expert on storage management issues. Toigo is also the author of storage books, including, "The Holy Grail of Data Storage Management." http://www.digitalguru.com/dgstore/product.asp?isbn=0130130559&ac_id=69


This was first published in May 2001

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.