Categories
Alan Weissberger Software Defined Network

2016 Open Networking Summit: Open Source Rules, But Are There Too Many Choices?

Introduction:

For its first few years, the Open Networking Summit (ONS) focused on pure SDN – strict separation of control and data planes, centralized SDN controller computing routes for hundreds of “packet forwarding engines” in its domain and OpenFlow as the southbound API/protocol used between control and data planes.  Overlay networks (a logical network mapped to a physical or “underlay” network) aka Network Virtualization were referred to as “SDN washing” by ONS Chairman Guru Parulkar, PhD who said the networking industry needed to start from scratch with all new equipment – in greenfield deployments or in sections/pockets of existing networks where SDN was to be deployed.  The idea was to drastically lower CAPEX and especially OPEX.  How times have changed!

2016 ONS Highlights & Take-Aways:

Over 1,300 delegates attended the March 14-17, 2016 Open Networking Summit at the Santa Clara Convention.  Attendance was up slightly from last year with a drop in exhibitors due to the Linux Foundation taking over the event only three months ago.  The conference was jammed packed with keynotes, panel sessions, and several demos on many topics.

The key themes of ONS 2016 were: disaggregation of networking equipment (hardware functions), virtualization of network functions, commodity hardware designed using merchant silicon, and open source software (from consortiums like OpenDaylight, ONOS, OPNFV, OpenStack, CloudStack, Open vSwitch, etc).  There was also a presentation of an “Open Linux” network operating system from Cumulus Networks that runs on top of industry standard networking hardware (usually white boxes or bare metal switches).

Each one of the above referenced open source consortiums has a large variety of open source software modules (source code) they are producing. Cloud service providers (e.g. Microsoft), network operators (AT&T, many others), and web hosting/Internet exchange companies (Equinix) are  adding their own software, some of it being released as open source code (e.g. Microsoft’s SONIC was released to the Open Compute Project this month).  AT&T said they have over 100 people doing Open Daylight software development and integration.

Dan Brown, Linux Foundation PR & Marketing Manager wrote in an email:

“I think the main takeaway is that the networking industry is moving rapidly towards an open source model, and there is a huge amount of disruption taking place, especially including disaggregation and softwarization.”

I couldn’t agree more!  But there is a plethora of choices for any entity (Data Center operator, cloud service provider, network operator, enterprise campus IT manager, etc) to pick from.  Obviously, the choice of open source software modules will depend on the applications and configuration.

Open Daylight from an AT&T Perspective:

Here are a few applications of Open Daylight (ODL) produced software modules that were said to be of interest to carrier/service providers like AT&T:

  • Resource assignment and inventory update
  • L3 Virtual Network Function (VNF) configuration
  • VoIP VNF configuration
  • IP flow redirection
  • MPLS traffic engineering
  • Update tunneling paths and bandwidth (for encapsulation protocols used in network virtualization)
  • Closed loop control (including real-time re-routes, block/scrub traffic)

AT&T’s SDN Controller platform was said to be built around Open Daylight (ODL) source code for L2 and L3 services.  AT&T is using ODL source code as a “Software Development Kit (SDK)” for event-driven and autonomous control in over 30 AT&T specific karaf feature bundles. Several AT&T speakers talked of YANG models and NETCONF tools positioned as “southbound interfaces and protocols.” They also mentioned “custom-built East/West software adapters to AT&Ts OSS” (and presumably between SDN controllers too).  Many of AT&T’s VNFs were said to use network virtualization components of ODL.

Author’s Note: NETCONF is the Network Configuration Protocol developed by the IETF for reading and writing network configurations.  YANG is the data modeling language associated with it.  NETCONF/YANG open source code is being developed by both ODL and ONOS.

AT&Ts Network on Demand (for Switched Ethernet WAN services) provides customer control through a web portal that offers immediate click-through ordering, changing and scaling bandwidth speeds in near real-time instead of hours or days, and software based virtual CPE (vCPE) that enables business customers to run multiple virtual functions on one hardware device.  We’ve been told that Network on Demand makes heavy use of a NETCONF based management plane for provisioning, configuration, and bandwidth/rate changes.  When I asked AT&T to explain how Network on Demand could be referred to as “SDN” because it doesn’t address the control or data planes, I received this response via email:

“We haven’t provided this level of technical detail (proprietary information of the product software).”

Conclusions:

Time and space do not permit a comprehensive summary of the excellent 2016 ONS.  Undoubtedly, the key conclusion is that open source software (running on both vendor designed networking equipment or white boxes/bare metal switches with an “open” networking operating system) is taking over the networking industry!

During his March 15th keynote speech, ONS regular John Donovan noted that AT&T has doubled their usage of open source software in the last year, going from 5% in 2014 to 10% at the end of 2015.  That number will continue to grow, but the carrier has not released projections for the percentage of open source code to be used in its network by the end of 2016 (despite some projections of as much as 50% open source code).

The dizzying number of protocols, software modules, and open source consortiums make it extremely difficult for a non expert to get a grip on the many flavors of “open networking,” which was intended to give users much more control of provisioning, configuration and real-time network behavior.

What has evolved is that each “open networking” service provider (cloud/ data center, Internet exchange, wireless and wireline (WAN) carrier, enterprise wide campus network, etc) is specifying open source software modules, developing their own code and/or asking vendors to do that for them.  Special purpose hardware (with new internal software) is used in most cases, but several operators (especially those of mega data centers) are using white boxes and bare metal switches running open source software.

The bottom line is that each service provider writes a network requirements spec and RFP for the services to be provided and protocols to be used (south-bound, north-bound, east-west, and every which way!).  The spec/RFP will include some combination of virtualized network functions, open source software, custom software, special purpose-built hardware (which requires internal software/firmware) from incumbent network equipment vendors, and perhaps white boxes/bare metal switches from new vendors.

The net result is that every “open network” will be different. It is highly unlikely that any piece of equipment that’s purpose-built for one service provider network will work on another service provider’s network.

If a service provider chooses to run the open source software over white boxes and/or bare metal switches, then commercial open source will likely be required (e.g. Brocade, Dell and Huawei have taken this path for the bare metal switches they’ve designed and built).  If not, there’ll be a huge opportunity for systems integrators large and small to port open source software code to different environments and add customized software specific to the service provider.  They will also have a huge task of making open source software work with existing management plane software, OSS/BSSs.

End Note: Please see comments (below) for additional references/urls. Also feel free to post a comment- no log-in is required and they can be anonymous if you don’t want to reveal your name.

 

 

 

Author Alan Weissberger

By Alan Weissberger

Alan Weissberger is a renowned researcher in the telecommunications field. Having consulted for telcos, equipment manufacturers, semiconductor companies, large end users, venture capitalists and market research firms, we are fortunate to have his critical eye examining new technologies.

3 replies on “2016 Open Networking Summit: Open Source Rules, But Are There Too Many Choices?”

Thanks Alan for providing an excellent summary of what I missed. You said it well about the dizzy number of “open” protocols and standards.

From my superficial viewpoint, the closest analogy that I can almost get my head around is WordPress as an open source platform. With its plug-ins architecture it allows for relatively easy customization of web sites, even by neophytes. Software developers, much like system integrators referenced above, can take it to the next level through custom code and customized plug-ins. Either way, the time to market is much faster and less cost for creating web site, which is the same goal as the aims of the open source networking folks

As an aside, I have been wondering for awhile if WordPress, with its soon-to-be released REST interface, could be the Northbound interface to an SDN controller. Not certain if there would be an application, but maybe if there were, it might be where WordPress would be the front-end for setting up the network provisioning.

Thanks for your comment, Ken. No standards/forum organization that I’m aware of has specified a Northbound interface (from the SDN Controller to the Applications Entity), although OpenStack is being strongly considered by some cloud service providers.
Just came across a Light Reading post titled “Open Source Is Killing Us.” http://tinyurl.com/zsjwcbl It amplifies my comments on a plethora of open source choices. Quote: “Consider open source SDN controllers, which include Open Daylight, ONOS, OpenContrail, Floodlight and Ryu. We counted nine open source SDN controllers in a December, 2014 overview. (See Who Does What: SDN Controllers.)”
At the Mar 14th ONS Marketing Tutorial I attended, there were 13 or 14 SDN controllers listed – none of which interoperates with any other (as expected since there’s no East-West interface standardized by ONF or anyone else).
Here’s another quote from an 2016 ONS blog post by Dan Conde:
“I do believe that open-source components are critical to modern infrastructure. Whether entire turn-key enterprise solutions can be built upon that is still to be determined. With open-source projects, there are so many different competing abstractions and layers released by different projects, it is difficult to ensure tight integration unless some party works to create a curated edition.”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.