Alan Weissberger Cloud Computing Networking Optical Networking Software Defined Network

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


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.



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


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 “Dan Pitt: How ONF is Accelerating the Open Software Defined Networking (SDN) Movement”

Excellent job on the interview and write-up, Alan. Thanks to you and your continued and detailed reporting on this topic, SDN is starting to make sense to me.

You are right that that the ONF’s announcement about Atrium and Flow Objectives Interface are big deals. These are the type of developments that are necessary to make SDN open.

Ken, Thanks for your kind words. ONF’s announcement are certainly a step in the right direction for multi-vendor interoperability of “pure SDN.”
However, more is needed as noted in the interview with Dan: some guidance on Northbound interface (Open Stack-Neutron?), East-West SDN Controller interface or federation/mediation sublayer, management plane functionality and API to Control Plane, more specifics on Optical Transport control & OAM, etc
Also, note from the interview that ONF will not be pursuing any other SDN reference architectures. In particular, the Overlay/Network Virtualization model that many SDN vendors prefer.

In the past, carriers/network operators waited for solid CCITT/ITU-T recommendations (AKA standards) before they deployed ANY new network infrastructure (e.g. X.25, ISDN, FR, ATM, SDH, OTN, Carrier Ethernet, etc). That’s not happening with either SDN or NFV—- There are ITU-T standards road maps, but no substantive work or even progress on either SDN or NFV. The reference architectures haven’t even been specified yet in the SDN Roadmap which you can download for free at:

Hence, one wonders what version of SD WAN will be deployed in VOLUME! Will each carrier set their own “SDN/NFV” specs as AT&T has already done with Netbond and Network on Demand? Note AT&T says it will or has deployed SDN and NFV in Domain 2.0, but hasn’t disclosed how and where!

Leave a Reply

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