CableLabs and OpenDaylight with Chris Donley & Thomas Kee

CableLabs SDN NFV Interview

With the new wave of open-source controllers replacing the old, there’s debate over which controller to develop new applications or protocols on. Certainly, the decision will come down to what the requirements and constraints are, and the concept of a Universal Controller ™ (remember, you read it here first) that can address all SDN needs is a myth. Which is why I’m particularly excited about this interview with Chris and Thomas of CableLabs, because they demonstrate how picking the right controller for their needs ensured success in their POC implementation. The CableLabs demonstration addresses quite a few issues that have been the topic of debate in the ecosystem, and I’m very impressed that instead of simply adding to the debate, Chris and his team just went ahead and did it–nothing like working code to drive home a point!

Through the interview, you’ll see that Chris and Thomas have a working implementation that demonstrates:

  • that it is possible to use protocols other than OpenFlow for SDN and that DOCSIS can participate within the SDN framework
  • the value of the Service Abstraction Layer (SAL) in the OpenDaylight architecture
  • the ease of adding a new Southbound protocol, PCMM, to the OpenDaylight controller
  • the viability of having non-Java networking developers participate in the OpenDaylight ecosystem (you’ll see that Thomas was very focused in his approach)

Anyhow, enough drivel from me, let’s get on with the interview!

What problems were you trying to solve with SDN?

Donley: We’ve been exploring SDN in cable networks since mid-2012, and identified the need for a protocol to control the DOCSIS® access network.  Through use case analysis, we determined that OpenFlow by itself wasn’t sufficient (and wasn’t supported in existing CMTSs), and started looking at other alternatives.  We believe that in the end, operators will use several different protocols within their networks under a unified controller architecture.  One protocol used in the cable industry for setting up DOCSIS service flows and applying QoS is Packet Cable MultiMedia (PCMM), which is based on COPS, and is widely supported on existing CMTS platforms.  We wanted to see if we could use SDN-ized PCMM in combination with OpenFlow to dynamically control a demo cable network and prove out the multi protocol architecture we’ve been developing within our Focus Team.

I also wanted to see how fast we could build something – one of the promises of SDN is to be able to rapidly develop and deploy new features, and I wanted to test the validity of that promise.

What kind of solution framework were you looking at? And what led you to pick the controller that you did?

Donley: We needed an SDN controller that allowed southbound protocol plugins. It needed to be capable of sending OpenFlow to our SDN switches and PCMM to a CMTS.  We also needed to be able to write a single application that controlled the entire network, rather than separate applications for separate controllers. The only controller we identified that could meet those requirements was OpenDaylight. The fact that it is open source was a plus.

Did you consider any other controller platforms?

Donley: We looked at a number of different SDN controllers, but other than OpenDaylight, none supported a modular southbound plugin architecture that could support PCMM. Without a service abstraction layer, we couldn’t integrate PCMM.

What was particularly compelling about the OpenDaylight controller? Did you have concerns before starting on the project?

Donley: OpenDaylight was the only controller we found that had a Service Abstraction Layer (SAL).  This allowed us to incorporate our PCMM plugin into the framework.

We had several concerns when we started:

  • Was the platform mature/stable enough to develop our proof-of-concept?
  • There was discussion in the blogs about ODL being a vendor effort to delay or subvert SDN development.  We weren’t sure how open the SAL was going to be, or how welcomed we would be to build on it.
  • When we started, documentation was limited, and we were concerned about how and where to start.
  • We also heard concerns expressed about the viability of the ODL project, and whether it would truly make it to market.

That said, this was a proof-of-concept, and we were willing to take risks.  We found the ODL community to be very welcoming, and received significant support and encouragement from its members.  As we got further into the development,  many of our concerns were alleviated, and we felt much more confident about ODL’s viability.

What was the goal of the proof of concept that you put together?

Donley: As part of our SDN evaluation, we wanted to demonstrate how to use SDN to control a DOCSIS network and raise the visibility of our research within the cable industry.  We also wanted to explore how additional protocols beyond OpenFlow could work in an SDN framework and continue our exploration of SDN controllers (we used Floodlight for our previous OF-only demo).

Thomas, what’s your development background? Had you worked with the OpenDaylight controller before?

Kee: I’ve been a network developer for many years, either directly developing or managing  teams to create  products and appliances for wireless routing, network high availability, network traffic management, and network security. My main programming language is C, and I also use scripting tools on embedded Linux.   Prior to this project I had no experience with the ODL framework and limited experience with Java.

How did you get started?

Kee: I downloaded the ODL source from OpenDaylight’s git server and worked with Mininet  to port an Openflow application using different controller to use the ODL northbound API.  This was done in conjunction with joining the email list, the IRC channel, and attending hackfests.   These were invaluable resources to quickly picking up information that was otherwise not documented yet.

What did you find most challenging about working with the ODP controller?

Kee: There are a number of tools to be familiar with that either can be helpful or prohibitive when trying to work fast.   It really all depends on the developer’s background.  In my case,  the list that I had to become familiar with was somewhat daunting (see below).  I was familiar with most of the tools but at the time when I started I had a bit of trouble incorporating some tools such Eclipse in my personal arsenal.

  • GIT
  • Java
  • OSGI model (or SAL)
  • Eclipse
  • Maven
  • Openflow protocol
  • JSON
  • Yang Modeling
  • ODL southbound protocol plugin architecture
  • COPS
  • PCMM
  • CMTS

In the end,  I was able to forge ahead with just Java, GIT, maven, and vi and/or EMACS  and just focused initially on developing the PCMM driver. By taking a focused approach, I was able to leverage what was already in place and deliver what was new–the driver.

Were there any surprises, either good or bad, as you worked on the project?

Kee: The existing examples were easy to work with when testing various components the project was going to utilize.  There is a simple skeleton of a southbound driver that could be used as a starting point.  Not so much a surprise as both the platform and our project were underdeveloped and API and interfaces in general were still very fluid and there were a lot of  build and dependency issues.   These issues would not be as significant when a stable build is released.  Also, when we began the Yang modeling tools were not yet quite in place and a lot of the manual development now might be generated with the information modeling workflow.

How long did it take you and what did you accomplish in the end?

Kee: Development time was about 5 to 6 weeks.   In the end, we had a PCMM driver with roughly over half the functionality require by the protocol, a COPS protocol library we adopted that could be reused for other network elements that spoke COPS, a Flow programmer translation, and finally a Python application that drove the flow management for the demonstration.

The demonstration itself tried to “show” network flow manipulation by controlling  DOCSIS video traffic flows from ODL and applying different flow PCMM metering parameters to creating a video image that was either degraded or high quality.

What was the end result?

Donley: It worked!  We demoed our PCMM plugin and video QoS application at SCTE’s CableTec Expo in October and our Sunnyvale office Open House in November.  I gave my team a very tight deadline, and they met it.  For us, this helped prove SDN’s viability in cable access networks, and showed that rapid development on SDN platforms is possible.

How has it been received by the cable operators?

Donley: Better than we expected.  This was an early Proof-of-Concept prototype, and we weren’t sure how it would work or be embraced.  After we had developed our plugin, one of our members told me that he was having an issue with PCMM, and thought that a combination of PCMM and OpenFlow would address his issue.  I talked to him about our plugin, and his eyes lit up. He told me that it solved his problem.  I’ve heard similar feedback from other MSOs and cable industry vendors.

Did it achieve yours and CableLabs goals?

Donley: It exceeded them.  We were looking for a simple SDN proof-of-concept, and discovered widespread interest in bringing this forward.  Since we first ran our demo, we’ve been approached by OpenDaylight asking us to contribute our plugin, and several of our members who would like to use it in their labs.  In addition, several vendors have asked to work with us on the plugin.

How do you envision this work continuing?

Donley: Certainly, we’ll continue to work with the OpenDaylight Project. We are also speaking with other vendors about sharing our code and jointly developing other Proofs-of-Concept. As an R&D lab, our objective is to seed the market with new technologies.  Ideally, we’d like other developers to work with us and extend the plugin beyond our initial prototype.

Thank you, Chris and Thomas, for your time!

Check out more Interviews on SDNCentral:

Leave a Reply