I’ve been digging deeper into the SDN architectures over the last few days and there may be a pattern starting to emerge.
I’m currently figuring that there are four broad classes of SDN technology that you can fairly neatly classify the current products from vendors. I’m classifying SDN Solutions into three categories of Micro, Centi and Kilo as well as classifying physical devices for SDN systems into three classes of Breve, Medius and Magnus.
Yeah, OK, I’m not good at names.
It seems that there are new options, platforms and products for network hardware nearly every week. I’ve taken to classifying products on a mental scale from minimal to maximal functions. For example, OpenCompute is promoting switch hardware that has the near minimum features and functions in the design. On the other end of the scale are companies like Pluribus Networks who are delivering network switches as applications.
So I tend to classify products into Breve, Medius and Magnus to reflect their relative feature and functions.
But for SDN, the classification is hardware is less important to the positioning of the SDN applications and controllers that will drive them.
When it comes to considering SDN solutions, there are truly significant differences between the architectural choices being made by companies. What is becoming clearer to me is the profound difference between the OpenFlow/SDN and SDN/Networking technologies and how this impacts customers. Some of the solutions are barely even ‘networking’ and much more like development projects.
I’m currently mapping four categories of SDN which I’ve named Nano, Micro, Centi and Kilo to recognise the extent that solutions require operational changes to networking as well increasingly complex features and functions. I’ll explain the categories first, then map them into highlight the positioning.
Nano-SDN is what we have today. There are people who believe that using existing technologies based on scripting languages like Python & perl etc with some Expect/TCL and SNMP Managers is SDN. OK, call it “Nano-SDN” on “Centi” class network devices. (more on this in a minute). For VMware folks, it is relatively common for servers admins to regard the ESX vSwitch as SDN. This is the baseline.
Micro-SDN is the SDN most visibly promoted by VMware NSX. Networking features and functions are moved into an overlay networking or with OpenFlow to control the flow forwarding path. Network hardware that is designed for this SDN category is ‘breve’ class with micro-features, low-cost and limited functionality. Features of this category are
- Reducing physical networking to a minimum means that CapEx for Breve Class hardware is reduced compared to Medius Class and releases funding for software licenses.
- Software overlays are flexible, and can interate quickly compared to hardware but has perceived performance problems.
- Overlay Networking can use with existing networks (Medius Class) thus reducing sales objection.
Broadly described as SDN that uses Medius Class networking equipment that is in your network today. Existing hardware has moderate features and functions that can be used via abstraction for a radically different application/controller/network interface when compared to OpenFlow/SDN. The device uses its own intelligence and resources to act in concert with the network.
This model means that the SDN controller is not tightly coupled to the physical network and can integrate with wider range of network elements such as WiFi, WAN and physical networks. This require limited change to existing networks practices and, to some extent, existing assets
Simple examples are Anuta and ActionPacket who are orchestrating existing products today while the most recognised is Cisco ACI via the APIC controller and onePK API that looks positioning to eventually control everything in the IT Infrastructure – network, storage, compute, campus, wifi, firewalls … the whole thing. I also put Juniper Contrail and Nuage Networks into this category.
It should also be noted that Centi-SDN maximises revenue for the hardware vendors through perpetuation of existing product designs and software. There is also a case that Medius Class hardware allows for greater SDN scale by distributing policy to devices instead of configuration as OpenFlow does. This scaling comes at the cost of controller software complexity but offers a unique method to embracing the entire network portfolio.
I only realised that this was a unique class yesterday when speaking with Pluribus Networks. It is a complex concept but their approach turns the entire network into an application. The network (and every device) itself is an application/controller/device. These devices are Magnus Class since they have many more software capabilities.
The EtherealMind View
It is useful to create taxonomies that build understanding of product in the framework of the technology and marketplace especially when considering which product meets the requirements of your company. There are now significant differences between SDN strategies and these will have impact on long term plans for enterprises and services providers.
This post is high level view of more detailed analysis that helps me to understand the difference between the technology, architecture and vendor implementations. It could change at any time since I’m still gaining insight into technology and vendor positioning. Evan at this early stage, it give a solid frame of reference to discuss SDN with customers to understand the nature of possible options.
Would welcome comments and other points of view. Hit me up in the comments below.
Advice and Consulting
If you found this useful, you might want to engage me to provide advice and consulting to your company. I can provide assistance on an hourly or daily basis to help you with your own projects. I also work financial firms who are looking for insight and advice on market & vendors. Contact in the first instance via my contact page or by emailing directly.