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.

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/wp-content/uploads/ausnog-03/presentations/ausnog03-dale-ethernet_evolution.pdf

cheers,

lincoln.

Note that other commenters have pointed out that Cisco is heading towards “IEEE DCB” in their marketing material.

Simple.

And it will all be lumped together under “IEEE DCB”.

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.

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.

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.