Lets start with a bit of background so you can understand where each of the acronyms comes from.
Ethernet Extensions
The Ethernet that we know and understand is defined by the IEEE 802 standard is all its glorious detail and many variations including wireless, MAN, LAN, WAN and so on. It has been been stretched and abused in any number of ways over the last twenty years and continues to find new ways to adapt to the new challenges. Ethernet is a Layer 2 frame technology, that is, it works at the Data Link Layer and is mostly perceived to be a carrier for IP packets.
Ethernet Quality of Service and its deficiency.
The Ethernet 802.1p QoS tagging is well understood today. By using the TOS field from the original definition, we can provide a hop-by-hop QoS mechanism across a switched infrastructure.
But for the emerging technologies for data centres, this QoS mechanism is not sufficient. In practical terms, there is no guarantee that an Ethernet frame can be dropped, or incur latency, or even that there is sufficient bandwidth using 802.1p, only that some sort of best effort
Storage transport and its “special requirements”
So Cisco (and it pretty much was only Cisco) decided that having two networks is a sales opportunity to make one network. In many data centres today, we have a network using FibreChannel and another network using IP/Ethernet. You can make a good marketing story around putting FibreChannel over that Ethernet network instead of having two networks. This is called “convergence”.
But Storage Networking is not designed and not able to have any significant loss or delay in the network. This is because FibreChannel standards never implemented decent protocols and chose to continue with decades-old SCSI signalling and storage logic. Good for immediate sales, bad for long term product vision.
Compare this with IP/Ethernet where there is robust support for latency, jitter and loss. This creates a head to head clash of requirements. Storage networks must have low latency, low loss, guaranteed bandwidth and low scalability. Data networks support variable latency, variable loss, variable bandwidth and high scalability.
Storage Networks
So Storage neworks used quite specific hardware that had very few ports to ensure bandwidth capacity, low latency and low loss silicon designs that do not block or drop frames.
Converging Data and Storage
If we want to build a Data Centre network that has extra features we need to implement a QoS and Bandwidth reservation signalling system that is similar in concept to RSVP for IP from a few years ago (notable because it was discarded because it was unworkable at large scale).
So the standards bodies have been getting some new initiatives. The IEEE Data Center Bridging group is working on the following standards:
* Priority-based flow control: IEEE 802.1Qbb
* Enhanced transmission selection: IEEE 802.1Qaz
* Congestion notification: IEEE 802.1Qau
* Data center bridging exchange protocol (DCBX): IEEE 802.1AB (LLDP). Proposed by Intel
There is one other standard that is important. L2 Multipathing (L2MP) (which I have discussed here) is going to be a vital part of making scalable data centre networks. There are two competing standards for L2MP shortest path bridging: IEEE 802.1aq and IETF TRILL.
So which is correct: DCB, CEE or DCE ?
So lets get to the core of this article. Which of these three acronyms is the best one to use when conversing about
DCE = Data Centre Ethernet = Cisco’s trademarked term for their implementation (trademarked on November 1st 2005)
CEE = Convergence Enhanced Ethernet = IBM’s trademarked term for their implementation (trademarked April 18th 2007, 18 months after Cisco trademarked Cisco Data Center Ethernet)
DCB = Data Centre Bridging = name used by the IEEE standards group.
So this leads to a few points:
Data Centre Bridging is the most correct term for the ‘in progress’ IEEE Ethernet standards that will allow FCoE to actually be useful and scalable. This is the term that you SHOULD be using. Note however, that for complete purity that the IEEE DCB working group doesn’t really include RBridges L2MP standards, but practically, everyone will put them into the same basket, including the IEEE Trill standard for L2MP.
DCE is not necessarily Cisco proprietary, it was supposed to be a marketing name for Cisco’s attempt at pre-standard ethernet and was trademarked to give the lawyers something to do. For example, Cisco had InterSwitch Links (ISL) for many years before IEEE 802.1Q trunking became the standard. In this context, DCE was meant to be a convenient handle for the marketing message before standards became available. There has been considerable backlash at Cisco for the term due to the belief that Cisco was attempting to control the standards (because that it was Brocade would do, given a chance) or to create a non-standard version of DCB and, as a result, they have largely stopped using the term.
CEE is term used by IBM for their marketing efforts and attempt to spin a viable marketing effort for their professional services. This term is probably the most popular today, but is equally proprietary and incorrect as using Cisco’s DCE.
What makes this even more puzzling is that IBM has no networking technology to sell as they resell other vendors, and the term has no meaning when IBM uses it.
Interchangeable ?
So, yes, all of terms are interchangeable, they encompass the same unfinished standards and have the same intent. However, the terms CEE and DCE are outright marketing speak for IBM and Cisco, respectively, to attempt to control to ‘conversation’. It allows the gross simplification of some very detailed and complex standards work to be “glumped” into a glib acronym that causes CIOs and CTOs to sign off faster and get sales going. Nothing wrong with that, except for the attenpt to co-opt the top position.
The correct term is…
Yes, the correct term is Data Centre Bridging with the acronym DCB. I would strongly recommend that you stick with this term that is truly part of the standards process and let IBM and Cisco use their proprietary terms all by themselves.
Loading ...
About Greg Ferro
Greg,
Really good article. Im writing something up re FCoE as interim technology at the moment and am as always struggling with which term to use. Im kind of siding with CEE. I see that Cisco are also starting to use CEE in their material. Seems to me the vendors are settling on CEE.
Also, I wasn’t aware that CEE was trademarked by IBM – I know they as well as other like BRCD etc use it. But I couldnt find it on their IBM trademarks website a few weeks ago when I last looked.
Yeah, most people don’t realise. I regard IBM with a lot more suspicion than I do Cisco so won’t be using the term CEE.
Note that other commenters have pointed out that Cisco is heading towards “IEEE DCB” in their marketing material.
Hm.. “DCB = Data Centre Briding =” Typo?
Marrying your data networking to your storage networking…
Fixed! Thanks.
hi Greg, Nigel:
Good article that really summarises it nicely. Let me provide some clarification to the above blog and comments on what we (Cisco) are using as the terms:
1. Cisco is using “IEEE DCB” as the vendor-neutral and industry-standard term to refer to the umbrella of:
* Priority-based Flow Control (PFC): IEEE 802.1Qbb provides a link level flow control mechanism that can be controlled independently for each Class of Service (CoS), as defined by 802.1p. The goal of this mechanism is to ensure zero loss under congestion in DCB networks.
* Enhanced Transmission Selection (ETS): IEEE 802.1Qaz provides a common management framework for assignment of bandwidth to 802.1p CoS-based traffic classes.
* Congestion Notification: IEEE 802.1Qau provides end to end congestion management for protocols that are capable of transmission rate limiting to avoid frame loss.It is expected to benefit protocols such as TCP that do have native congestion management as it reacts to congestion in a more timely manner.
* Data Center Bridging Exchange Protocol (DCBX): a discovery and capability exchange protocol that is used for conveying capabilities and configuration of the above features between neighbors to ensure consistent configuration across the network. This protocol is expected to leverage functionality provided by IEEE 802.1AB (LLDP).
… which are the basis for being able to support FCoE within the bounds of Ethernet while providing the same no-drop reliable in-order transport to which FC relies upon.
2. While we may have in the past, Cisco is not using the term “DCE” to refer to the above umbrella of standards. All of the above are industry standards (ratified, pending or close to being finalized) and not proprietary in any way shape or form. As such, it makes a lot more sense to use a vendor-neutral and industry-standard term to refer to them – i.e. “IEEE DCB”.
3. Cisco is not using “CEE” to refer to the above at all. Like DCE, CEE was a vendor-created term and doesn’t make a lot of sense to use moving forward with standardized protocols.
4. There may still be some Cisco documents, presentations, data sheets et al that refer to either “DCE” or “CEE”, however those are for the most part historic and out-of-date. Its a big effort to correct terminology in lots of places, where we find it we replace with “IEEE DCB”. We’ve been doing so for months, and likely will continue to be doing so for a few months to come yet.
Hope this clarifies.
cheers,
lincoln.
An additional discussion point here:
You raise an interesting point as to whether TRILL (RBridges) should be included under the “DCB” umbrella term or not.
From the perspective of converging LAN & SAN infrastructure, there are some very clear benefits that TRILL can provide to such a converged network. For one, it would mean no STP, for another TRILL allows multiple topologies to be built on the same underlying physical topology, thereby allowing “SAN A” and “SAN B” topologies to be built alongside a single “LAN” topology, solving the inevitable ghostbusters “don’t cross the streams” (http://en.wikiquote.org/wiki/Ghostbusters) problem that exists in merging LAN (single fabric) and SAN (always dual fabric) topologies.
But does this mean that one requires TRILL for FCoE?
No.
There are a variety of means of provisioning the independent “SAN A” / “SAN B” topologies today – on classical ethernet – without having to resort to hierarchical MAC addressing and multiple topologies like what you have with TRILL.
This can be achieved today using:
– hosts can be dual-attached active/active with virtual Port Channel (vPC) providing a single logical link for LAN traffic, with the CNA still seeing two indepedent physical links for SAN traffic
– the topologies can be segmented at the first-hop switch in the access layer, e.g. on Nexus 5000 we can take FCoE frames and send them out FC ports.
Clearly it gets a bit more challenging for a multi-hop FCoE network – i.e. taking Unified I/O beyond just the first switching layer in the access, but it will be possible to do without requiring TRILL/L2MP end-to-end.
cheers,
lincoln.
I’m sure you understand the difference between theory and practice. In practice, TRILL will be a mandatory requirements to reduce the cost of the network infrastructure. Given that 10GbE ports cost several thousand pounds in storage networks, you can’t afford to have sit idle as a backup. TRILL/RBridges offers us a way to make use of all that bandwidth.
Simple.
And it will all be lumped together under “IEEE DCB”.
hi Greg,
Indeed I do. I’ve work on the evolution of how we get from A to B every working day.
I agree that there is significant value (both capex and opex) from “using all paths active” that TRILL enables. However I’d categorize that as being “enabled in a revolutionary manner” since you need TRILL-capable switches now, there are a ton of changes to control-plane protocols (ISIS in the core, no STP root, multiple topologies), and there are some interesting permutations when it comes to interoperability with ‘legacy’ STP clouds or devices which don’t do TRILL.
As always the devil is in the details.
One can deploy FCoE today – and can do so in an active/active / “all paths active” manner – in an ‘evolutionary’ manner – even with STP in the mix. This is what Cisco enables today with virtual Port Channel (vPC) on Nexus platforms (and with VSS on Catalyst 6500) which enables the concept of a “mutl chassis etherchannel”. To neighboring devices this looks just like a standard 802.1ad (LACP) link aggregation bundle.
One can deploy vPC on the access switch edge today (e.g. Cisco Nexus 5000) with vPC to a host for active/active including FCoE operating over the top of that – and still preserve SAN-A / SAN-B – all with the existing classical ethernet frame format.
My point is, one can achieve “no blocked links” aka “all paths active” in an evolutionary manner – vPC – without having to necessarily do a whole network refresh, topology change, technology change or all new protocols. Not to say that there aren’t additional benefits associated with TRILL – there are – but one can evolve a network to that if so desired rather than go to it in one revolutionary step.
I actually gave a talk at a conference recently where I covered all of the above – FCoE, PFC, ETS, DCXBP, DCB, vPC, L2MP/TRILL – a whole alphabet soup of acronyms.
The slides are posted in a public place, see http://www.ausnog.net/files/ausnog-03/presentations/ausnog03-dale-ethernet_evolution.pdf
cheers,
lincoln.
FYI – IBM did file a trademark CEE on April 18, 2007 but abandoned it on October 22, 2008. Here is the record: http://tess2.uspto.gov/bin/showfield?f=doc&state=4001:lgjqmd.2.39
To be clear, you mentioned 802.1aq Shortest Path Bridging (SPB) once, but went on to define Trill as if it were part of the IEEE DCB work. Trill is NOT connected to the IEEE.
Since the IEEE owns the protocols to manage Ethernet as well as Ethernet itself, the IEEE is working on 802.1aq as the IS-IS based replacement for spanning tree that is fully backward compatible with all other 802.1 Ethernet standards. SPB is being defined in the IEEE along side all the other DCB technologies. The same people are involved in both and have joint meetings.
Also the big difference between SPB and Trill is that SPB defines the management of a native ethernet header instead of doing the Trill approach of defining a whole new header format that recreates hop by hop routing like IP, ignoring the native ethernet on each hop and further injecting MAC addresses into a protocol. Not to mention continuing shared trees and non-congruent unicast/multicast flows.
So by taking control of the native Ethernet layer and providing a Link State created Ethernet Switched Path (ESP) between endpoints it can be used to define paths for FCoE connections using TE capabilities and fast healing using standard link state technique and a few more fast convergence techniques defined in the spec.