In his book, Innovator’s Dilemma, Harvard Professor, Clayton Christensen discusses disruptive innovation. Though he wrote this book almost 20 years ago, some lessons are timeless.
His thesis is companies focus too much on their current customers’ needs. They only think about the current way of doing business; their bias is on using current designs and technologies. In so doing, he talks about how companies miss opportunities for disruptive change.
His classic example is Nucor Steel, creator of the “mini-mill.” The mini mill was a new type of steel mill. It was cheaper to build and faster to make. It was smaller than the large, existing steel producers. Nucor, at first, could only produce rebar, which is the lowest margin, smallest market for steel products. So, he didn’t gain much notice right away. Over time, Nucor improved the mini-mill technology. And it worked its way up to high quality, sheet steel used in the auto industry. That’s a much bigger market with higher margins. Nucor did this at a much lower cost than the large providers could. These providers were the victims of disruptive change.
Christensen has similar examples in the hard drive industry and in the open source area. In open source, he speaks about improvement in proprietary software and in open source relative to the needs of the industry. Once open source reaches a critical point of satisfying important needs, a virtuous cycle starts. Specifically, as more people are attracted to the open source community, more people are available to code new important areas. This momentum attracts even more people to the community.
This virtuous cycle has been—and still is—happening in the software defined networking (SDN) space.
In SDN, 4 factors brought disruptive change:
- Open Source Software – OpenStack, Open Daylight, OPNFV, Open Networking Operating System, Open VSwitch and OpenFlow
- Hardware Improvements – over the last 10 years, the packet performance of standard server CPUs has improved almost 2 orders of magnitude. This lets service provider scale routing on standard servers.
- Network Architectures – From 2005-2006, folks at AT&T Labs and in academia wrote a series of papers about separating the control plane from the data plane in routers. This work ended in IRSCP (Intelligent routing Signaling Control Point). We’ve used that technology in our network for almost a decade. It also forms the technical basis for Netbond. Netbond lets our customers tie their internal networks to third party clouds. AT&T’s Network on Demand is another SDN network architecture example. It gives customers simple, flexible personal control over their networking needs.
- Industry Trends – We have had over 150,000% growth in data traffic on our mobile network since 2007. At 60%, video is now the largest traffic segment on our network and virtual reality applications are on the horizon. We carry over 114 PB of traffic each day. These trends dictate the need for a change in the way we build our network.
So, these 4 technology and industry factors motivate our adoption of SDN. They drive a fresh, new approach to network design. It’s based on separating hardware and software layers, virtualizing network functions on standard cloud servers and quick and flexible response to network traffic growth.
We committed early to SDN. Just as mini-mills revolutionized steel production, we knew that SDN would grow out of the LAN and data centers, and have an impact in the wide area network. We could “lead, follow or get out the way.” We chose to lead.
We have over 5% of our network operating on SDN now serving over 14 million mobile subscribers. We’re active in the open source areas that I mentioned earlier. We sponsor academic research in this area. We have a number of industry engagements as well. Lastly, we have committed a number of internal resources to our network cloud and network cloud automation software platform.
ECOMP is our network cloud software automation effort. That stands for Enhanced Control, Orchestration, Management and Policy. We’ve been using this software platform for over a year. It’s over 8 million lines of code — and growing. Our goal is to create a software platform that allows real-time, policy-driven automation of network functions. And that the platform performs these functions at scale, in vendor and in a VNF neutral way.
We released a whitepaper on ECOMP. We’re encouraging folks to read about our efforts and to provide feedback. We hope that others express interest in our direction and in building a community to drive it forward.
We want your feedback. Take a look and let us know your thoughts.
- Read the whitepaper: att.com/ecomp
- Share feedback: ecomp-feedback@research.att.com