A View of SDN From the DukeNet Sandbox
I spend a lot of time in the sandbox.
It's not the sandbox that you remember playing in as a kid, building castles. Instead, my sandbox is located on the ground floor of the DukeNet headquarters building in Charlotte, N.C. We have switched out the sand and castle-building tools in favor of servers and networking equipment.
The DukeNet sandbox is a very busy place, evaluating technologies like IPv6, virtualization and cloud. But for the last year, our focus has been on software-defined networking (SDN).
I'm playing with SDN to determine its impact on my transport and data networks. DukeNet views SDN as a promising architecture that will have a significant, long-term impact on networks. This is why it is imperative for us to understand the platforms, benefits, capabilities and risks of SDN.
Two current use-cases DukeNet is exploring are:
- SDN in our telemetry network to optimize collection of our service-assurance information and to provide easier access for more granular traffic-flow monitoring and analysis.
- SDN orchestration of a multi-vendor network to provision MEF services.
Right now I'm tinkering with the longer-term goal of how to make provisioning simpler for my customers -- single-touch, even. In a perfect world, users will be able to log into a portal and modify any and all of the attributes associated with their service. This can be something as simple as upgrading bandwidth from 10Mbit/s to 100Mbit/s for an hour while a company streams its quarterly earnings. Or something complex such as distributing Virtual Machines between various cloud providers depending on the user's requirements and then modifying the bandwidth and quality-of-service to whatever is desired.
It's got to be that simple and flexible to keep up with the "I want what I want, when I want it" customer. Yet today, this is still a struggle for the network provider. No one currently has the real-time analytics from the network or the dynamic user information that we need. That's what we expect SDN will deliver.
As I look forward to what SDN will enable, I see the accelerated ability to provision services, not only on my network, but on other ISP networks. This type of end-to-end provisioning of a service is very exciting to think about, but also introduces some concerns around things such as service quality and security outside of our network -- quality assurance will remain critical.
As our DukeNet Lab (aka the sandbox) build-out continues, we will further test SDN use-cases, as well as integrate new SDN hardware and software vendors. There is also some discussion about directly connecting our sandbox into other sandboxes to enhance our testing and development capabilities. DukeNet will be able to make smarter choices about its future network infrastructure and introduce robust new premium services based on the playbook we're writing right now from the work we're doing in the sandbox.
In my view, SDN is currently moving in the right direction. But as it evolves, as an industry we need to ensure it remains open. Northbound, Southbound and East-West APIs need to be based on open standards. The market is maturing quickly, and there is a lot of activity across multiple industry forums and working groups. That's what keeps it exciting.
We also recognize the huge amount of work that remains to be done, particularly on the billing side of the house, where billing for Ethernet Virtual Circuits is still a complicated process today. When we start provisioning elastic services that have constantly changing attributes, we'll be looking at a whole new billing mentality.
But that's for another day. Back to the sandbox…
— Brian Sutterfield, Director of Technology/Principal Technologist, DukeNet Communications