FCoE Standards: Taking a Step Back

While it may seem like I’ve been taking a hiatus from blogging for a while, the truth is that I’ve been working on a number of writing projects related to FCoE. As I mentioned on a recent Infosmack podcast there have been a lot of developments coming out this month and, understandably, there are a lot of people who are trying to figure out what it all means. In the process, there are some people who are trying to talk about FCoE but are muddying the waters horribly.

The main misunderstanding revolves around FCoE standards, because by and large most people have no real clue how they work and what they mean. My goal is to help clear up some of that confusion and give a baseline understanding of standards as they apply to FCoE.

Disclosure(s)

At the bottom of this page you’ll see an official disclosure but let me say it up front, too. I am a Product Manager for FCoE for Cisco and, as of this writing, I have been in the position for a little over 3 weeks. My role is to help promote FCoE (and related products) in the Data Center on Cisco’s behalf.

This means two things.

First, it means that I am aware of the issues of credibility that it might bring to bear. I’m also acutely aware that vendor blogging can be fraught with problems. For those who might simply dismiss what I write for these reasons, well, I suppose that’s your prerogative, but I do tend to back up what I write with sources and strive for the highest accuracy. Nevertheless, I’m not writing on Cisco’s behalf here, nor am I espousing a Cisco point of view. Instead, I’m focusing on FCoE and standards as a technology problem, not a business analysis problem.

The second thing it means is that I now have access to a wealth of information and resources that I could never have had in my wildest dreams as an independent voice. During these brief three weeks I have come to understand that my own understanding of DCB, FCoE, and standards have been askew (okay, in some cases flat-out wrong).

For that reason I’m pretty lenient when articles are published with respect to standards that are erroneous, by and large. After all, the standards committees themselves don’t make it easily accessible to the general public to figure out what is going on, let alone their relationship to each other. So if I’m having trouble piecing this puzzle together and it’s my main focus, who am I to blame someone for not getting their facts straight?

The Big Picture – Who is Who

First and foremost, when it comes to FCoE you need to understand that there is no FCoE Standards Committee. So, when you see an interview, or a press release, that makes a claim that “the FCoE standards committee” does this, or says that, or plans on doing something else, you need to immediately understand that the content is suspect.

However, the two technologies in FCoE have standards bodies: the Fibre Channel (FC) side has T11, and the Ethernet side has IEEE.

T11 is the group that defines Fibre Channel technologies, and another group (called FCIA) markets them. For over ten years T11 has defined how to transport FC over other protocols, and with each version additional features are added. When it comes to FCoE itself, T11 is your group (more on this below).

IEEE is the group that determines Ethernet standards. They have a different naming convention than T11 (which is one reason some people get very confused as to what qualifies as a standard for FCoE and what doesn’t), but effectively they do the same basic thing: they determine what problems there are, and the best way to solve them. When it comes to the consolidation of multiple traffic types over Ethernet, IEEE is your group (again, more on this below).

.

There is no FCoE Standards Committee

.

What Standards Are, and Aren’t

This is the biggie. If you get nothing else from this article, get this part:

Standards are meant to be a solution to a problem.

Many people believe, erroneously, that you need to have standards in order to have technology. This simply isn’t true.

Standards do not address the question of what to do, they address the question of how to do it.

So in the case of FCoE, let’s say you want to put Fibre Channel frames and carry them over Ethernet. There are some technical issues that you need to take into consideration, and standards that relate to FCoE will tell you how to do it.

Is it the only way to solve that problem? No. Is it required? No. In fact many vendors will often sell pre-standardized products into the marketplace because standardization does not often require hardware upgrades (the obvious exception is if it happens to be a hardware standard!).

.

Standards do not address the question of what to do, they address the question of how to do it

.

This means that if a vendor releases a pre-standardized product and the standard changes the functionality, it’s often merely a software/firmware upgrade.

What this means is that standards are not requirements for either operation or interoperability.

FCoE and Standards, or Why It’s Not Required

As it turns out, when it comes to putting Fibre Channel frames onto Ethernet, you really need only a couple of things. You need to add a way for Fibre Channel to behave like Fibre Channel, even while being transported over Ethernet, and you need Ethernet to behave in a lossless fashion just like Fibre Channel.

What do you know? Both of those problems have been solved and finalized.

You can create lossless Ethernet with the PAUSE capability and, believe it or not, that was standardized in 1999.

You can place Fibre Channel frames onto other media (e.g., Ethernet), and if you want to do it in a standardized way, then the T11 group told you how to do it in 2009.

But wait, there’s more!

What if you want to run more than one type of traffic on a single wire? This is a problem, right? As it happens, it’s a problem that is being worked on by the IEEE Data Center Bridging Task Group.

When you realize that standards are meant to solve a problem it makes a lot of things easier. What if, for instance, you don’t have a particular problem that the standards are trying to address? Well, in that case you can simply ignore the irrelevant standard.

For instance, the working group for Fibre Channel that was responsible for FCoE was also working on a larger solution to put FC on multiple different technologies, not just Ethernet. This meant that FCoE wasn’t the only thing that came out of FC-BB-5 in June, 2009.

However, we don’t concern ourselves with problems we don’t have. If, like some people think, we were required to follow FC-BB-5 then we’d have to incorporate FC over TCP/IP, FC over GFPT, FC over MPLS into every FCoE switch.

Why? Because that’s what FC-BB-5 covers!

As you can see, just because something is standardized doesn’t mean that it must be implemented if you don’t have that problem.

The same thing follows for IEEE’s DCB standards. The DCB standards contain several additions and enhancements to Ethernet to allow extra features, including some of the ones we’ve all heard about (Priority Flow Control, Enhanced Transmission Selection, etc.). These are all solutions designed to address problems that people may want to solve. Each of the extensions defined by DCB solves a specific problem, and there are no cases of two solutions for the same problem.

.

If standards were “required,” FCoE switches would have to have FC-BB-5 features that they don’t need.

..

If, however, someone comes up with a better way to solve the problem, they are more than welcome to do it. If someone comes up with additional features that solve additional problems that the standards committees haven’t thought of yet, they can do that too. It won’t change the fact that FCoE can still be implemented reliably.

Standards and Versions

There’s an additional misunderstanding when it comes to standards and the versions that are perpetually in development.

Darren Thomas, head of Dell Storage recently gave an interview to Storagenewsletter.com, where he exacerbated this misunderstanding:

No dates yet, and to be clear, the FCoE standards committee has pushed out the date where you can do end-to-end FCoE by more than two years.

Well, we’ve already seen that there is no such thing as “the FCoE standards committee,” so it’s not clear what committee he’s referring to.

First, in Fibre Channel (and FCoE is Fibre Channel), it’s best to think of those topologies as “core-to-edge,” rather than “end-to-end,” but that’s best left for another post.

Second, even using Thomas’ terminology, you can do “end-to-end FCoE” right now. If, as a customer, you are looking for a standardized way to do it, then it was completed with FC-BB-5 in 2009.

It seems that Thomas is telling people to wait for the next version of the standards – in this case FC-BB-6 – but that implies a lack of understanding of how standards work.

Think of it like an operating system: each version of an operating system has a set of features and capabilities, but you don’t need to wait until the next version comes out in order to have a computer now.

The same is true for FCoE standards. If you are simply waiting for the next version to come out you’ll never buy a switch!

Mea Culpa

This is the part where I server up an extra large portion of my hat. I’d like some tabasco sauce, please. Maybe a nice Bordeaux.

Earlier I had mentioned that FCoE was not the equivalent of DCB. If I had stayed right there I would have been on safe ground. But instead, I had to say that FCoE was a subset of DCB, which as you can see from reading this standards article, is patently incorrect.

In case I got a little unclear, let me explain a bit better.

FCoE is a definition of how to put Fibre Channel onto Ethernet, which is defined by T11 (the Fibre Channel people). DCB is an Ethernet series of features that come from IEEE. As a result, FCoE is not dependent upon DCB to work, nor does DCB require FCoE to work.

FCoE has only one single requirement from Ethernet: be lossless, and this can be achieved without any DCB at all, by proper network design or by using another mechanism (PAUSE) defined by IEEE over 10 years ago. FCoE is independent from DCB, and this is why it has been standardized by T11.

If everything you want to deploy is FCoE, there is no need of DCB. If, however, you want to achieve I/O consolidation (e.g., carrying both FCoE and other Ethernet traffic over the same wires), then you’ll need to solve some additional problems – problems that the DCB standards are addressing.

In short, it’s all about network and deployment requirements, not about protocol requirements.

Putting It All Together

Look, I’ll be blunt. Standards are not the most fascinating topic of conversation, nor are they easy to grasp. Having been to the June T11 working group meetings I realized it was a non-trivial process to see how everything fits together.

It’s a lot like trying to figure out box scores in the newspaper without understanding the rules of baseball. Or watching cricket.

If you’re not already familiar with the interconnections of the game, and who the players are, you may often find yourself guessing as to what the important parts are to look for.

When it comes to FCoE, there are really only a few crucial things to know from a standards perspective:

• The problem of making Ethernet lossless was standardized in 1999.
• The problem of putting Fibre Channel frames on Ethernet was standardized in 2009
• Therefore, FCoE standards are done. Baked. Completed. Ready-to-Rock-and-Roll.
• Additional solutions to problems are nearing completion, and several of these solutions are already implemented in shipping products today.
• More conversations about how to solve problems are ongoing, so you can expect even more features to be available as time goes on

As you’ve read this far, I hope you’ve found this useful. I have been spending a lot of time lately trying to wrap my head around the standards process and have found myself on the business end of a slap upside the head – more than once!

I have no doubt that I’ll continue to find that some of my assumptions need revisiting, and I’ll probably have a few more moments where I’ll be forced to admit that I was… ahem… incorrect. When that happens, I’ll be the first to identify where those shortcomings are and do my best to be as accurate as possible.

In the meantime, though, with all the news reports that have come out in June 2010 with respect to FCoE from a large number of vendors, it’s important to stay grounded as to what the standards mean when the term is thrown about with careless abandon.

And now you know.

.

You can subscribe to this blog to get notifications of future articles in the column on the right. You can also follow me on Twitter: @jmichelmetz

“Official Disclaimer: Some of the individuals posting to this site, including the moderators, work for Cisco Systems, Inc. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not those of Cisco.”