x
Carrier SDN

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

Page 1 / 2   >   >>
brsutter2251 8/18/2013 | 6:41:00 PM
Re: Provisioning and billing challenges Ping,

 

Valid point, my thought is standardizing a controller might be an interim step until all standard APIs can be developed. 

 

 
sam masud 8/16/2013 | 10:54:19 AM
Re: Provisioning and billing challenges I thought the comment about open APIs interesting and intriguing. But here is where the confusion comes in, at least for me: if there are open APIs (north-south, east-west) in SDN, then does the industry really need to standardize on, say, a controller (e.g. OpenDaylight)? In other words, given a southbound API like OpenFlow, and assuming there is also a standard northbound API, where then is the need to standardize on a controller?
Carol Wilson 8/15/2013 | 4:25:42 PM
Re: Provisioning and billing challenges Thanks, Joe, interesting answer. 
brsutter2251 8/15/2013 | 4:21:30 PM
Re: Proud to Be Involved Thanks Joe! 

 
brsutter2251 8/15/2013 | 4:20:04 PM
Re: Provisioning and billing challenges Carol,

 

Thanks for the post, my thought here is future services need to be provisoned in minutes versus days and those services might not only be within one network providers control so end-to-end provisioing is key. 
brsutter2251 8/15/2013 | 3:57:06 PM
Re: Provisioning and billing challenges Joe,

Great points and the one that resonates with me the most is how critical the customer is in getting multi-vendors to work together.   

 
joe.cumello 8/15/2013 | 2:24:35 PM
Re: Provisioning and billing challenges I don't want to be the only voice here, but I will say it's not easy. Developing open northbound APIs for apps and/or southbound element adaptors to support third-party devices requires expert resources, time, and sometimes a firm push from the customer (when the third-party is competitive or slow moving). This last piece is something that's not often discussed in the multi-vendor, open dialogue. Many vendors are competitive to each other and it sometimes takes a strong push from the carrier customer to force cooperation once the SDN platform has been chosen. Another factor may be that much of the legacy equipment and software out there is vertically integrated, making openness hard to do -- with the added risk of opening themselves up to portfolio cannibalization.
Carol Wilson 8/15/2013 | 1:50:20 PM
Re: Provisioning and billing challenges Okay, so everyone SAYS they favor open interfaces - what's the challenge to making that happen? Are some folks just giving lip service to the idea? Is it really, really hard to do? Or does it just undermine the business case of key players?

Give me some specifics here, folks. 
joe.cumello 8/15/2013 | 1:48:20 PM
Re: Provisioning and billing challenges Carol, first of all, congratulations on the new site. I know quite a bit of hard work went into getting this launched.

Regarding end-to-end multi-vendor service provisioning, it can and is being done. Cyan is working with customers to provision and orchestrate services in multi-vendor environments today. As an example, our close relationship with the Ethernet NID community -- and the element adaptors we build to help provision and operate Ethernet services -- is greatly accelerating the time to adoption for SDN functionality in production networks.

The billing question is a tougher one, but open Northbound interfaces allow customers to write apps that can connect to their OSS/BSS. We do have customers writing apps today. 

The future success of carrier SDN and NFV is rooted in the SDN software's ability to work in multi-vendor and complex production networks. Cyan believes that openness on both the northbound and southbound sides of these platforms is the only way this is going to be achieved -- along with a tight partnership between the vendor community and the carrier IT organizations to coordinate established OSS procedures and applications with these platforms.

Joe
joe.cumello 8/15/2013 | 1:24:00 PM
Proud to Be Involved Brian, great article. Our companies have had a long-standing partnership and as Cyan's first software-only customer (to start), DukeNet has consistently pushed the envelope and challenged us to develop Blue Planet in ways that increase network and service automation, orchestration, and visualization. We truly believe that an open, multi-vendor SDN approach is critical in enabling customers to simplify and automate how existing and new services are provisioned and deployed. The purpose, of course, is to deliver a profitable service and a satisfying end-customer experience. We're proud to be engaged with DukeNet on this project.

Joe (and the whole Cyan team)
Page 1 / 2   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE