The beginning of the end of FCoE

Never bet against Ethernet!

I am sure many IT experts and practitioners would agree. In the past 30 years or so, Ethernet has fought and won against many so-called would be “Ethernet killers”. The one that stood out for me was ATM (Asynchronous Transfer Mode) because in my past job, I implemented NFS over ATM, running in LANE (LAN Emulation) mode in a NetApp filer setup in Sarawak Shell.

That was more than 10 years ago. And 10 years ago, ATM was hot technology. It was touted as the next generation network technology and supposed to unify the voice, data and network together. ATM also had better framing and QOS (Quality-of-Service) control and offers several modes of traffic shaping and policies. And today, ATM is reduced to a niche telecommunication protocol, and do not participate much in the LAN technology space.

That was the networking space. The storage networking space is dominated by Fibre Channel for almost 15 years. Fibre Channel is a serial technology that replaced the channel-based technology of SCSI in the enterprise. And Fibre Channel has also grown leaps and bounds, dominating the SAN (Storage Area Network) landscape with speeds up to 16Gbit/sec today.

When the networking world and storage networking world collided (I mean combined) with Fibre Channel over Ethernet (FCoE) technology some years back, one has got to give some time soon. Yup, FCoE was really hot 2 years ago, but where is it today? Is Cisco still singing about FCoE like it used to? What about the other storage vendors that used to have at least 1 FCoE slide in their product presentation?

Welcome to the world of IT hypes! FCoE benefits? Ability to carry LAN and SAN traffic with one piece of wire. 10 Gigabit-style, baby!

Looking into it deeper, the FCoE Host Bus Adapter (HBA) has 2 set of “engines” to process Ethernet traffic and Fibre Channel traffic. When encapsulated within the Ethernet frame, the packaging looks like this:

But FCoE is not getting cheap fast enough to encourage a mass adoption of the technology. At the same time, the virtualization forces have been gaining strength and moment. When VMware purchased Nicira for USD$1.26 billion a couple of weeks ago, a new buzzword leaped into the fore – “Software Defined Networking (SDN)“. That was probably the final nail to FCoE’s coffin, as the IT world shifted its focus from the “unifying story” of FCoE to SDN, the new darling of the networking world.

OK, OK, maybe not exactly SDN per se, because a week later after the VMware acquisition of Nicira, Oracle decided to purchase Xsigo for perhaps the same reason(?). Perhaps that was what Oracle needed after seeing that Project Crossbow from Sun wasn’t going anywhere fast. That’s probably because all their core engineers and developers left for obvious reasons.

Xsigo isn’t exactly SDN. They are a I/O virtualization (IOV) technology just like Virtensys, but then again it could be SDN because it virtualizes the physical networking interfaces into many virtual networking interfaces. It can be Ethernet or FC-HBA, or even InfiniBand. Software is the technology that abstracts the underlying networking architecture. Here’s a short video of what Xsigo do:

This means that if SDN or IOV has anything to say about this, the next battleground for networking and storage networking will be virtualized network resources. Server virtualization such as VMware and Hyper-V already have network virtualization in the Compute Layer, with concepts such as vNICs, vHBAs and vSwitches. The Networking Layer dominated by Cisco and Juniper will have plenty to say with new disruptive technologies such as OpenFlow.

If the switching companies such as Cisco and Juniper and to a lesser case, Xsigo decides to use 10 Gigabit Ethernet or the future 40/100 Gigabit Ethernet as the only wire from the storage layer to compute layer, and deliver iSCSI over Ethernet (for now) and perhaps ditch the iSCSI overheads in the future for SCSI-over-Ethernet (is there such a technology yet?) ala ATA-over-Ethernet (AoE), the Fibre Channel protocol itself could be at risk of losing its shine. After all, all we want is to send and receive ATA or SCSI command sets over the wire, isn’t it?

Yeah, yeah, I know someone going to knock me for saying this is a stupid idea, because where’s TCP/IP? Where’s the addressing bit to ensure that the SCSI PDU (protocol data units) and the CDB (command data blocks) arrive at the correct destinations?

If TCP is able to establish a session once IP has found the target, then it would not be too difficult to work out a point-to-point connection over the TCP session between the target and the initiator and then offload to RDMA (remote direct memory access) do its job sending and receiving PDUs and CDBs efficiently. This idea might just work.

IF SCSI-over-Ethernet can be defined with the SDN or IOV technology, and that would be certainly the death knell for FCoE. Anyone heard of the Insieme spin-in project of Cisco? You can read about it here and here.

Tagged , , , , , , , , , , , . Bookmark the permalink.

About cfheoh

I am a technology blogger with 25+ years of IT experience. I write heavily on technologies related to storage networking and data management because that is my area of interest and expertise. I introduce technologies with the objectives to get readers to *know the facts*, and use that knowledge to cut through the marketing hypes, FUD (fear, uncertainty and doubt) and other fancy stuff. Only then, there will be progress. I am involved in SNIA (Storage Networking Industry Association) and as of October 2013, I have been appointed as SNIA South Asia & SNIA Malaysia non-voting representation to SNIA Technical Council. I currently run a small system integration and consulting company focusing on storage and cloud solutions, with occasional consulting work on high performance computing (HPC).

9 Responses to The beginning of the end of FCoE

  1. Pingback: The beginning of the end for FCoE « Storage Gaga

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.