It was very satisfying to see ONS grow from a small gathering at Stanford to be the premier summit for SDN. Hats off to Guru Parulkar and his team for a world class event. The event featured top class speakers and content. If you missed the event, you can watch the sessions online at ONS web site.

What really struck me was the spirited debate about the definition of SDN itself. Specifically, the debate whether an overlay based network virtualization solutions is SDN or not. One would think an SDN event would know what the definition of SDN is. It turns out defining SDN is not so elementary…

So what is SDN? And is an overlay based network virtualization solution SDN?

A commonly held belief is that OpenFlow or in general a protocol to program the switching elements from a logically centralized entity is an essential part of SDN. While the ability to program the flows in the network (OpenFlow) or access forwarding tables of switching elements lays the foundation for powerful concept of application driven network, it is not a necessary condition to create and deploy SDN.

…In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized and the underlying infrastructure is abstracted from the applications…

If you search for the definition of SDN on the Internet you will find many.

The common traits that I see in all the definitions are:

Separation of Control plane and Data plane

Logical centralization of the control plane manifested as the SDN controller

Abstraction of underlying network

API based access to the network

Ability to provide network connectivity service also known as network service chaining

So let’s look at an overlay network virtualization solution and see if it passes the “SDN test” that is, if an overlay solution meets the criterion described above. I will use IBM SDN VE solution as an example for carrying out the “SDN test”, because I want to give you a concrete example. Following figure shows the components of IBM SDN VE solution.

Connectivity Server is the Control plane for the virtual network. It is a logically centralized entity which is responsible for determining forwarding decisions and network policy enforcement in the virtual network.

Overlay enabled vSwitch is the data plane of the virtual network. It is responsible for data traffic from source end station to destination end station.

Management Console is the management plane. Users can create and manage virtual networks through the management console.

Overlays gateways are used to connect to non-virtualized end stations and connecting to physical networks

Let’s take a look at each of the common traits of various SDN definitions and how an overlay virtual network stacks up to it.

Separation of Control plane and Data plane

In an overlay virtual network solution the control plane is separated from the data plane. For example in the figure above Connectivity server is the control plane and vSwitches are the data plane.

Logical centralization of the Control plane

As shown in the diagram above the Control plane entity Connectivity Server is logically centralized. From an implementation perspective the Connectivity Server is federated and distributed.

Abstraction of underlying network

All overlay network virtualization solutions inherently abstract the underlying physical network. Data Center/Cloud orchestration tools and applications are provided a logical view of the network which hides the underlying physical network infrastructure. One could argue that the virtualization abstraction provided by overlay virtual networks is the most important aspect on which rest of the benefits of overlay solutions builds up.

API based access to the network

It is typical of any overlay network virtualization solutions to provide APIs which the orchestration tools and applications can use to programmatically access the network.

Ability to provide network connectivity service also known as network service chaining

Based on the publicly available information about other overlay solutions, it looks like most if not all solutions have or will have network service connectivity feature.For example IBM SDN VE is a network virtualization platform which has the ability to create network service connectivity templates so that the users can specify a set of network services such as firewall, load balancing network any two end points.

So there you have it, as shown above, an overlay network virtualization solution is SDN.

Overlay based network virtualization is SDN which from an abstraction point of view is above OpenFlow based SDN. As we have seen above an overlay network virtualization solution meets all the definitions of SDN but the entire solution is virtualized and is agnostic of the physical infrastructure. An OpenFlow based SDN creates a physical network that separates the control plane from the data plane of the physical network. So an overlay network virtualization SDN can run on top of non-SDN IP networks and/or on top of OpenFlow based SDN network.

Now let’s take a look at the components of an overlay network virtualization based SDN solution vis-à-vis an OpenFlow based SDN solution from the perspective of an open standards based implementation.

Physical network infrastructure

Overlay network virtualization solutions are physical network agnostic. This is a big strength of such solutions. Typically an overlay based network virtualization solution requires just IP level (Layer 3) connectivity between physical end stations. Overlay network virtualization approach lets you build robust physical network infrastructure based on tested and mature network technologies and shift the provisioning and deployment to the virtual networks. It is fair to say that the basic IP connectivity using L2/L3 data center switches is open standards (IETF) based. There is a robust level of interoperability between traditional L2/L3 switches from various vendors.

An OpenFlow based SDN network at the physical network level deploys OpenFlow enabled switches which follow open standards developed by ONF.

So from a physical network infrastructure perspective both overlay network SDN and OpenFlow based SDN both use open standards based network elements.

Programmatic interface to the network services – Northbound API

Currently there are no standardized Northbound APIs. Every SDN product has its own set of Northbound APIs. The closest there is to a de-facto industry standard is the Quantum API of Openstack platform. Almost all SDN implementations have Quantum API support. So any given SDN implementation, whether overlay based or OpenFlow based, is no more or less standards based than another.The general consensus is that it is best to let Northbound APIs evolve from specific use cases and customer requirements. Newly formed OpenDayLight open source consortium would be a logical place to develop use case led industry de-facto Northbound APIs.

Standardization of various Control plane functions

Currently there are no standards for control plane functions either in overlay network virtualization based SDN or OpenFlow based SDN. For example in case of overlay based SDN, end station address learning and dissemination, network policy specification etc. is not standardized. In case of an OpenFlow based SDN, for example network topology discovery, network topology representation etc. are not standardized.

One can have a healthy debate about what needs to be standardized in an SDN environment but the point is that except for the standardization of the physical network infrastructure in both overlay based SDN and OpenFlow based SDN nothing else is standardized at this point of time.

One should note that IBM intends to provide open source version of IBN SDN VE to OpenDaylight Project. This will provide an enterprise level open source option for overlay network virtualization SDN.

The advantage of overlay network SDN solution is it provides inherent abstraction of the underlying physical network infrastructure. It allows you to build your physical network infrastructure for robust connectivity (wire once) and shifts the provision, deployment and use of L2-L7 networking to overlay virtual networks. The underlying physical network is not aware of the overlay traffic flowing through it. This poses operational challenges for the network admins since they would not be able to monitor and trouble shoot overlay traffic. New generation of merchant switching chips have overlay network awareness which provides visibility of overlay traffic in the physical network. So you can expect switch vendors to provide visibility of overlay traffic in the physical network.

The advantage of an OpenFlow network SDN solution is that the SDN Controller has fine grained control over the physical infrastructure. Since OpenFlow is a wire protocol, it operates at a low level and provides no abstraction of the network which is what is needed for a useful SDN implementation. The network abstraction is provided by the SDN Controller which is implementation specific.

Is there a way for Overlay based SDN and OpenFlow based SDN to coexist? You bet!

Overlay virtual network is a great solution for IP networks. An overlay solution addresses the limitations of existing IP networks and provides solutions that customers are looking for: fast, dynamic provisioning of L2-L7 network, simplification and automation of network provisioning and deployment, large scale multi-tenancy, programmatic access to the network resources and network connectivity service.

It is reasonable to expect that moving forward many organizations will have a mix of traditional IP networks and OpenFlow based networks.

Since overlay virtual networks are agnostic to the physical infrastructure, they can provide network virtualization services for OpenFlow networks too. In addition the overlay virtual network will be able to exploit the underlying OpenFlow network for specific needs of an application in terms of physical network SLAs such as guaranteed bandwidth, deterministic latency etc.

So here is how I see customers can have a winning strategy with SDN for IP networks and OpenFlow networks:

Deploy Overlay network solutions on top of IP networks and OpenFlow networks. This provides common network abstraction and virtualization model across different physical network fabric.

Since OpenFlow based SDN provides physical network programmability and control, use that to:

Provide better network visibility and SLAs for the overlay network running on top of the OpenFlow network

Deploy new applications and services which exploit the underlying OpenFlow networks as per their needs

The above can be achieved via a unified SDN platform that is capable of virtualizing an IP network and OpenFlow network through common overlay technology and is capable of exploiting OpenFlow network to provide new applications and services. An example is shown below: