When you think about the massive affects that the Ethernet standards have had on system design, the overall impact is no less than staggering—and I do not use that term lightly. Thirty years ago, when Ethernet was new, networking was both provincial and fragmented. The only machines deemed worthy of “internetworking” were mainframes and minicomputers. The big-iron houses like IBM and the minicomputer vendors such as Digital Equipment Corp (DEC) and Hewlett-Packard all had proprietary networking standards. For example, IBM had SNA and DEC had DECnet. Then in 1980 the IEEE started a working group—802—to standardize a network based on the Ethernet protocols that Bob Metcalfe, David Boggs, Chuck Thacker, and Butler Lampson developed at Xerox PARC along the lines of Metcalfe’s PhD project (ALOHAnet). To see the original Ethernet hardware paraphernalia including its thick and unwieldy yellow coaxial backbone cable, its vampire-tap MAUs (media access units), and its special coaxial-cable coring tool, you might be excused for not predicting that Ethernet would take over the planet. But it did through ruthless evolution and continuous cost cutting, which reduced the cost of connection to less than a dollar. And as a result, every computer manufactured these days has either a wired or wireless Ethernet port or multiple ports of various Ethernet flavors.
The interoperability of today’s Ethernet-enabled devices is staggering. To see an iPad in a Starbucks coffee shop surfing Web servers in far-flung places such as Eastern Europe, India, Asia, or even North America through a casual WiFi connection is stunning—yet it is so commonplace that the feat rarely reaches our conscious minds these days. It just happens. Conjoined with that ease of connectivity however is a dark cloud: wasted energy to keep those billions of Ethernet connections alive even when they’re not carrying data. The energy numbers boggle the mind. In a recent Webinar, John Swanson from Synopsys listed a few jolting power-consumption figures. In the US alone, Ethernet ports attached to servers, network storage devices, routers, switches, and other networking equipment burn about 0.5 terawatts per year! Ethernet ports on computers, printers, edge switches, and other local devices installed in commercial, research, and educational institutions burn another 1.5 terawatts per year! Home-based ports burn about 2 terawatts per year! In all, that’s about 5 terawatts or $400 million worth of electricity per year just to keep the bits moving along all of the Ethernet ports in the US alone. And you know that all of those ports aren’t active all the time, yet most of them burn power 24/7. No wonder that the IEEE is now addressing the issue of wasted networking power through several new standards designed to make Ethernet use more efficient.
The key low-power standard under development is called the 802.1-az specification and it employs LLDPDU (link layer discovery protocol data units) to allow a switch and a device to negotiate sleep and quiet times when the Ethernet ports can actually be powered down. Implementations based on the 802.1-az specification will require new hardware and software but these new ports are backward compatible with the old, power-wasting kind of Ethernet port. If there’s no negotiation, there’s no sleep time and the ports will operate normally. However, when negotiation between two 802.1-az ports does take place, both ends of an Ethernet connection can time out and can power down their respective Ethernet MACs and PHYs, which will result in substantial power savings.
Currently, version D3.2 of the working group specification is circulating. More important perhaps, Ethernet controllers with 802.1-az port compatibility are already available as are some early PHY chips. The MAC part of the 802.1-az specification has not changed in a while according to Synopsys’ Swanson and only PHY changes are expected in the future.
Data applications for Ethernet can benefit greatly from the power reductions made possible by the 802.1-az specification but throughput- and latency-sensitive applications such as audio and video over Ethernet need additional support, which I’ll cover in the next blog post.
