You are here: Home / Blessay / All The Ethernet Cooks

All the Ethernet Cooks

10th December 2010 by 8 Comments

One of the surprising elements of Ethernet is how many different standards bodies there are developing a diverse set of extensions to Ethernet. I’m beginning to wonder how far Ethernet can be pulled and stretched and yet still look like Ethernet.

Just Some of Ethernet Standards Bodies
Standards Body Description
ethernet-stds-bodies-1.jpg IETF are developing TRILL and previously VPWS, VPLS and other L2 Ethernet LAN extension technologies.
ethernet-stds-bodies-2.jpg The IEEE are the long time custodians of the 802.3 standard. Except for the bits that they no longer control. Obviously in control of things like DCB and all the 802.1 buzzwords that we throw around. The IEEE are the custodians of the Ethernet frame format, but they don’t control extension to the Ethernet protocol that other people might put together. For example FCoE, TRILL, and many more
ethernet-stds-bodies-3.jpg Focussing on taking the operational features of legacy protocols like ATM and Frame Relay and adding them onto the ethernet (thus justifying the purpose of ATM and Frame Relay and we should have been using it anyway).
ethernet-stds-bodies-4.jpg Never one to produce anything useful, they are developing synchronous ethernet (for goodness sake) in addition to a range of OAM protocols.
ethernet-stds-bodies-5.jpg Attempting to make Ethernet in the last mile instead of PPP. Things like DSL/FttX/Broadband related architecture and transport aspects (TR-101), BRAS/BNG-requirements, Ethernet Aggregation/TR-59 evolution, subscriber session handling.

Not to mention people that appear to be lobbyists for making sure the Ethernet standards ‘go your way’. For example, http://ethernetalliance.org/ has a vague kind of job that looks like a political lobby.

Let not forget the FibreChannel people attempting to turn Ethernet into something new as well via the ANSI X11 commitee http://www.t11.org/ who are hoping to stay relevant for a few more years with FCoE.

The EtherealMind View

So Ethernet might be the protocol that we are ‘converging’ on. As you might expect, Ethernet doesn’t actually suit all use cases e.g. in the carrier space Ethernet has no OAM capabilities for remote service monitoring of edge devices. It’s human nature to attempt to extend the protocol, possibly taking the technology in directions that are sub-optimal. A living example of this problem is Microsoft Windows and it’s years of extensions and patches – and it isn’t working so well.

I take the view that there is no longer just one version of ethernet as it gets pulled in many directions to suit different needs. I do wonder just how far Ethernet can go as Grand Unified Theory of networking. And it’s confusing to attempt to track all the different splinters.

For example, as I write this, TRILL (IETF) and SPB (IEEE) are developing standard for L2 ECMP and today it seems that the market will use TRILL in the Data Centre, and Service Providers/Carriers will use it in the WAN. Both of these technologies are, loosely, signalling layers that extend Ethernet’s capabilities. The frame format might be the same, but Ethernet is very different for these two technologies.

Postscript

What I find quietly amusing is that many of the features that were present in other technologies (like end-to-end status for Frame Relay PVCs) are being developed for Ethernet. I’m not sure if I should laugh or cry about that.

Filed Under: Blessay, Blog Tagged With: , ,
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • Dmitri Kalintsev

    Greg,

    Ethernet OAM has well and truly arrived. Have a look at the recent EANTC test report for a bit of an insight: http://www.eantc.de/showcases/cewc2010.html

    Regarding the SyncE – it is critical for mobile backhaul (3G/4G) operators to have accurate clock reference. SyncE is one of the ways to achieve this.

    I would like to disagree with the statement about ITU not ever producing anything useful. Maybe in the DC/enterprise space, not sure. Not so in the telco world.

    • http://etherealmind.com Greg Ferro

      There are many ways to have clock reference, but Ethernet should not be one of them. That’s like attaching rockets to a camel.

      In my view, the ITU is an organisation produces the ‘least best’ outcome for any technology. Slow, tedious, and prone to bickering, the list goes on and on. We need better standards bodies than the ITU.

  • Maxim Tuliuk

    Has any vendor already supported TRILL in its equipment? Not yet. When will they implement TRILL fully? No-one know. So VPLS has now a big advantage as a working technology.

    • http://etherealmind.com Greg Ferro

      Maxim

      It’s my understanding that all vendors will support TRILL in the data centre once the final standard is completed. At this time, Cisco is closest with their proprietary implementation of TRILL, but Brocade have some early technology that is on the same track. HP state they will have TRILL sometime – on past experience, expect them to be late and limited in features.

      • Maxim Tuliuk

        Greg, I insist on that neither Cisco or Brocade has no time-line about TRILL; and I’m not alone in this: LINX (peak traffic: 823Gbit/s) did research what technology they should use for the next version of its platform and chose VPLS: http://ripe61.ripe.net/presentations/112-RIPE61-LINX-architecture-review.pdf

        • http://etherealmind.com Greg Ferro

          Both vendors have publicly stated their support for the TRILL once the standards are complete. The items in the standards (ISIS TLVs) are fundamental and until approved no can can say they support TRILL.

          So, ” all vendors will support TRILL in the data centre once the final standard is completed.” is correct and true. No one can support TRILL until the the key component of the protocol is finalised.

          • Maxim Tuliuk

            Greg, I pointed out that now VPLS has a big advantage comparing to TRILL because:
            1) the standard hasn’t been published yet i.e. no-one can say WHEN firmware with TRILL support will be ready
            2) operators have already done huge investments in MPLS and deploying VPLS as a part of MPLS strategy is a logical step
            3) a good vendor must listen what customers ask, and operators ask for 1) 100G card 2) cheap 10Gb card 3) full set of IPv6 protocols and they don’t ask about support of “another protocol”

            I can’t say anything about enterprise so it’s possible that they are interested in TRILL

  • Jerry Hubbard

    This sounds like Ethernet is no longer a “Unix” tool for networking and is now a “Windows” multitool. I really like my Gerber, Leatherman, Swiss Army Knife, etc., but not one of them replaces the single purpose tools I have used for years.

    Yes, Ethernet may have been limited to the LAN in concept when the original specification was written, but this is fixing something that is not broken.