Dan Pitt: How ONF is Accelerating the Open Software Defined Networking (SDN) Movement

Introduction:

With so many “SDN” announcements that use proprietary specifications or functionality (e.g. AT&T Netbond and Network on Demand; Cisco,Arista Networks, etc.) many panelists/observers at last week’s Open Networking Summit (ONS) said that “Open is the new Closed” or Open is the new word for Proprietary.”

To get to the straight skinny of whether open networking is really open (or closed/proprietary), this author interviewed long time colleague Dan Pitt, PhD, Executive Director of the Open Networking Foundation (ONF)  on the ONS show floor last Wed, June 17th.  The interview was totally unscripted, with no questions or issues discussed prior, no notes or audio-visual aides to prompt the interviewer.  It’s an extemporaneous Q & A covering many critical issues to make SDN truly open and avoid vendor lock-in.

The Interview:

Dan says that ONF is on a journey from “pdf to Python.”   ONF’s journey from PDF to Python indicates that ONF is moving beyond producing only documents (in PDF) to also producing working code – in whatever language. Python is only symbolic and was chosen for its alliterative relationship to PDF.

[Python is a programming language that’s being used to implement SDN controllers.  For example, Ryu is an open-sourced Network Operating System (NOS) that supports OpenFlow.  NTT is buying SDN controllers using Ryu.]

Dan explains what the ONF has done to facilitate Open SDN.  He highlights the Atrium open source project, which uses Quagga-BGP peering as the application, a control plane for the ONOS open source SDN project, and OpenFlow v1.3 as the Southbound API/protocol between the control plane and the data plane.   For the very first time, hardware interoperability between SDN Controller (ONOS running on a generic compute server) and five different vendor data plane switches (each using different switch silicon).  Each data plane vendor wrote their own I/O drivers which were compatible with ONOS.

More importantly, ONF developed a Flow Objectives Interface (see diagram below) which translates an abstract flow into one that the vendor’s I/O driver could interact with. Previously, each implementation of OpenFlow was dependent on the data plane switch hardware, which meant that there needed to be a different OpenFlow version for each data plane switch vendor, thereby negating interoperability.  In this author’s opinion, the Atrium (for open source control plane) and Flow Objectives Interface (for interoperability) projects are a REALLY BIG DEAL!

Alan asks Dan about the Northbound API (between Control Plane and Application Program) work in ONF.  Northbound APIs may be the most critical APIs in the SDN environment, since the value of SDN is tied to the innovative applications that communicate with the control plane through one or more Northbound APIs.   This is where the real “software defined/user programming” is realized and enabled to support a variety of different applications.  While Alan mentions only CloudStack as a candidate Northbound API, there are also OpenStack, VMware’s vCloudDirector, etc.   The goal is to abstract the inner-workings of the network, so that application developers can ‘hook’ into the network and make changes to accommodate the needs of the application without having to understand exactly what that means for the network.

Noting that a single SDN Controller can’t scale to calculate/re-calculate routes/paths for more than a few hundred data forwarding plane nodes, multiple SDN controllers (each covering an administrative or geographical domain) will be needed in large networks that implement SDN-OpenFlow.   Dan was asked to comment on a proposed East-West (or West-East) Interface that would specify the communications protocol between different SDN Controllers.  That could be realized by something akin to a private Network to Network Interface (P-NNI), by an intermediary hierarchical controller, or some form of SDN Controller federation.

After the interview, Dan provided some clarifying comments on the ONF East-West interface project which augment his brief remarks on that topic:

“ONF has a project on the east-west interface for connection between different administrative domains. We are not delving into the different options for hierarchies or federation of controllers in a single administrative domain, as there are a variety of valid approaches to that which at this time do not require our intervention. There is still much to learn and no indication that either committee standardization or common working code is needed by the industry.

Between administrative domains (or OpenFlow islands) various IP-based solutions have been employed, BGP being perhaps the most common one. NTT has also demonstrated the BGP-free edge, while the ONF/ESnet/AARNet demo of this spring reflects a different approach, now instantiated by Atrium. That option is also a BGP peering router, but built out of SDN and OpenFlow, which opens the door to some interesting gateway possibilities.

So while we and others are exploring these, and operators are starting to ask about east-west interfaces, we have been focusing most of our effort on making the SDN islands functional, manageable, and inter-operable. Without experience deploying reliable OpenFlow domains I don’t think the operators need to worry too much yet about new ways of linking them.”

The illustration below depicts the OpenFlow hardware interoperability demo Dan referred to in the interview.  Five different data plane switches were all shown to be interoperable with ONF’s control plane implementation of OpenFlow.  Previously, each control plane implementation of OpenFlow had to be customized to each specific data plane vendor’s hardware, due to differences in the switch silicon and other attributes.

Reference:

Highlights of 2015 Open Network Summit (ONS) & Key Take-Aways