There are so many flavors of “SDN” you can’t keep track of them. The term “SDN” has come to ONLY mean “software control of a network.” That could be anything and is a far cry from the original definition which included strict separation of the Control and Data planes, a “centralized controller” that computes paths for many packet forwarding engines (Data plane implementations) and a standardized API (Open Flow v1.3) as the “southbound API” between the Control and Data Planes.
What Guru Parulker of Stanford University called “SDN Washing” (non pure forms of SDN) have come to dominate the industry. There are network overlay models with multiple instances of Control planes, network virtualization (overlay of a logical network over a physical network) using VMware technology or VxLAN tags, and extensions of proprietary, closed network equipment to accomodate some degree of user control over the network configuration and paths.
I don’t think AT&Ts SDN WAN uses Open Flow or even a centralized SDN controller to compute paths/routes for multiple data forwarding “engines.” Instead, they use a proprietary, dynamic routing protocol as described in this article: http://viodi.com/2014/09/18/atts-sdn-wan-as-the-network-to-access-deliver-cloud-services/
you will see end to end “orchestrated API control” with no explanation of what that is. But that’s presumably how network administrators “program” AT&Ts SDN WAN. Of course, those and other APIs are proprietary to AT&T and their vendors/suppliers/cloud service provider partners, etc.
VxLAN is a virtual networking solution to support a flexible, large-scale multi-tenant environment over a shared common infrastructure. It is designed to provide the same Ethernet Layer 2 network services as VLAN does today, but with greater extensibility and flexibility. It’s supported by Cisco, VMWare, Arista Networks, Broadcom, Juniper, Citrix, Cumulus Networks, Red Hat, and others. Here are a few references:
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/vidoe_fundamentals_vxlan.html
http://www.vmware.com/files/pdf/techpaper/VMware-VXLAN-Deployment-Guide.pdf
http://www.broadcom.com/collateral/wp/VXLAN-WP101-R.pdf
http://en.wikipedia.org/wiki/Virtual_Extensible_LAN
VXLAN was officially documented by the IETF in RFC 7348.
There will be several vendors which might interoperate using the VxLAN virtual network overlay model But that networking gear won’t work on a pure SDN Open Flow network as defined by the ONF!
From this and many other examples, it seems SDN is “open” only to the extent of the SDN network provider (telco, DC operator, campus/ enterprise network) and its suppliers/vendors. As such, I expect network equipment vendors to pick a few versions of SDN they’ll support.
What Standards are Required for SDN:
IMHO, Open networking imples multi-vendor interoperability, which requires standards for functionality, protocols, APIs, and interfaces that are in the public domain. I believe the following standards are needed for SDN:
1. API/protocol between the Control Plane entity and the Data Plane entity (Open Flow v1.3????)
2. API/protocol between the Control Plane entity and the Management/Orchestration/Automation entity. It’s sometimes referred to as the “Northbound API” or “Management plane API”
3. Specification of exactly what functions the Management/Orchestration/Automation software entity performs, e.g. functional requirements. See discussion below.
4. API/protocol between the Control Plane entity and higher layer entities, e.g. Load Balancers, Application Delivery Controllers, Firewalls, other virtual appliances. ONF calls that the “Northbound API”
5. API/protocol between one “centralized” Control plane entity and another. ONF refers to that as “East-West API,” but no work has been done on it last time I checked. When I asked Dan Pitt, what does one SDN controller use to communicate with another when the route/path is between two or more domains, he replied “use BGP for now.”
6. SDN specific OAM and network management.
Role of OpenStack:
An orchestration/management/automation software entity is required with an API to either the SDN Control Plane entity (“Northbound or Management API”) or to the NFV “virtual appliances.”
At the 2014 SVIEF annual conference, Chris Kemp, founder of Nebula and the OpenStack Foundation told me that Open Stack http://www.openstack.org/ is the best solution for orchestration & management software with specific APIs. But it’s years away (for being used in production networks) and not yet specified by any telecom standards body (e..g. ETSI, ITU, ANSI, ATIS, etc).
OpenStack’s
Neutron API can be used to integrate the provisioning and management of these network resources into the orchestration of the overall IT infrastructure. Neutron’s
open networking capabilities handle a wide range of tasks, including the management of both networks and IP addresses. Users can create their own networks, control traffic and connect servers using Neutron, while administrators can apply ONF’s
OpenFlow and similar technologies to deliver software-defined networking, multi-tenancy and high levels of scalability.
Within the Open Stack Foundation, there’s a project called Open vSwitch http://docs.openstack.org/havana/install-guide/install/apt/content/concepts-neutron.openvswitch.html which is quite promising for open SDN designs.
Open vSwitch includes OpenFlow (specified by the ONF), which enables one to define networking flow rules. Certain configurations use these rules to transfer packets between VLANs. For example, Open vSwitch supports the VxLAN overlay model.
There’s also OpenStack Networking API v2.0 (neutron) Reference
which can be used for authentication, request/response, bulk create, etc. These are described at:
The companies involved in SDN need to specify which Open Stack projects, specifications and APIs are needed for management and orchestration of networking functions. But what SDO will do that? ONF, ITU-T, ATIS?
Stay tuned for a follow up article on this topic, with the help of Mr. Kemp of Nebula!
