F is for FCOE

is for FCoE.

Or Fibre Channel over Ethernet. NetApp announced last week providing a convergence-ready, end-to-end 10G infrastructure solution for FCoE.

NetApp has been the leader in Ethernet and TCP/IP-based storage. Redefining the landscape of file services with a unified architecture for UNIX and Windows networking. Later being the largest supplier of iSCSI-based storage solutions in the industry when we introduced iSCSI support for a new standard for block storage access.

In the storage world, the letter 'F' until recently meant Fibre Channel SAN. A separate high performance storage network for deploying critical applications in the data center. NetApp storage supports traditional Fibre Channel SAN solutions, of course. But the emergence of solutions like iSCSI certainly posed the question more forcefully of "Can I get to a single networking infrastructure for my data center?"

FCoE provides a way. The enabling underlying technology is Data Center Bridging, or DCB. The Fibre Channel networking standard provided a reliable physical transport for the encapsulation of SCSI for SAN storage deployments. DCB brings a set of features to Ethernet that finally allows for the physical fabric convergence that has been elusive to date. Two standards bodies were required to drive towards an FCoE solution. The IEEE driving the Ethernet standard, and T11 driving the requirements around the support needed for storage.

In October 2007, NetApp and several partners demonstrated a prototype FCoE solution pointing the way to the product announcements and solutions available today. Much of the direction in FCoE is tied towards the march of Ethernet to 10 Gb/s and beyond. 

What does this mean practically to you? As technology is refreshed and  you are looking at storage architectures you are now able to look at a single networking infrastructure in your data center. From the storage architect's viewpoint, FCoE provides a storage solution that co-exists with traditional FC-SAN deployments and the simplest path forward toward a single wire standard in the data center. FCoE and FC-SAN can be managed in the same way. From a green perspective, FCoE makes sense. As Ethernet bandwidth continues to leap forward, a single infrastructure can halve the number of ports coming from a host, and reduce the power consumption. All with a physical network that is compatible with TCP/IP, iSCSI and NAS solutions. The convergence-ready aspect of our announcement is that the 10GbE adapter runs FCoE today in initial release, and we are demonstrating and qualifying the other storage protocols now. This makes a lot of sense from many perspectives.

Technology change takes time, standards bodies at their best step in and provide the framework for new products and solutions. Bob Metcalfe, the co-inventor of Ethernet, allegedly quipped once "I don't know what the networking of the future will look like, I only know they will call it Ethernet." (If any reader has any information on whether that quote is true, or where it was first attributed, let me know - because I cannot verify it). It is turning out that not only is that what it will be called, but that it will be Ethernet in actuality also.

I did have the opportunity to meet Metcalfe when he was inducted as a fellow of the Computer History Museum last October. I handed him a bottle of wine as a gift, and when he asked me why I replied "Because of you I have a job. I work at NetApp and we're a leader in networked storage. And Ethernet is the network."

Comments

[Stephen Foskett]

I've heard that same quote myself, and I think I used it on my blog! Whether it's true or not, it's a great quote!

[Brian Pawlowski]

Hey Stephen! In searching (yet again) for the source of the quote, I found your blog entry referencing it.

Yep, it's a great quote.

(NB: I fixed the post to reflect the now standard term DCB for the enhance Ethernet capabilities).

[Keith Brown]

[From my one NetApp follower:-) Keith goes into some detail. I used the word "reliable" loosely in referring to the specific difference between the physical networks of Ethernet and FC along the lines of in order and quality of service.]

> The Fibre Channel networking standard provided a
> reliable physical transport for the encapsulation of SCSI
> for SAN storage deployments.

Indeed it does Brian, although I always thought there was a certain irony to be found in the fact that practically nothing uses that "reliable physical transport"! :-)

I guess it was nearly ten years ago now when I first stuck my nose into the Fibre Channel books, coming at them with the perspective of a guy who had worked in the Ethernet & TCP/IP world since 1984. Aside from my professional curiosity in understanding what Fibre Channel fabrics were all about (i.e. as a NetApp employee), I remember being genuinely bemused by the infatuation some folks seem to have for FC, and was curious to find out what all the fuss was about. One of the things I would constantly hear is "Fibre Channel is reliable, Ethernet isn't" (ergo Ethernet is not a suitable network for storage traffic, etc, etc...), so that was an area I was particularly interested in getting to the bottom of.

What I discovered was that Fibre Channel fabrics do indeed provide reliable transport services to their end-points, these being the so-called class-1 and class-2 FC Service Classes, but that most things that are commonly found on a Fibre Channel SAN, including FCP storage traffic, use the class-3 service, which actually doesn't guarantee frame delivery, or even in-order frame delivery at all. The FC class-3 service is sorta-kinda the UDP of the Fibre Channel world, not the TCP. Upon reading this, I nearly dropped the books on my foot!

So am I suggesting that the entire Fibre Channel industry is in fact built on a bogus premise, that FC SANs are all fundamentally flawed in some way, and that all the "FC is more reliable than Ethernet" arguments were/are totally baseless? No I'm not. Clearly there are many, many thousands of Fibre Channel SANs in the world that are humming along just fine, and of course we've sold FC SAN storage to many thousands of those environments ourselves, so we know they work just fine. I acknowledge the fact that most of the popular FC switch vendors do themselves guarantee in-order packet delivery (w/ class-3 service) in their own products, and that any tiny bit of packet loss that might occur in the FC fabric will typically be handled quietly and reasonably-efficiently using simple retries of I/O operations by connected hosts, but... I still can't help but look at the ground and smile when I hear folks talking about FC SAN reliability over Ethernet! :-)

Keith