26 July 2012 2 Posted by Paul Burns
With news of a single acquisition, much of the IT industry has suddenly been awakened to the possibilities created by network virtualization. While network virtualization is indeed a game changer – particularly for cloud networks – it is important to discuss it within the context of a broader trend called software defined networking (SDN). As you will see by reading this blog, network virtualization is simply one application of SDN.
On July 23, 2012, VMware “announced it has signed a definitive agreement to acquire Nicira, Inc., a pioneer in software-defined networking (SDN).” Nicira is known for its strengths in network virtualization while VMware is known for its strengths in server virtualization, particularly within enterprise data centers.
But what exactly is network virtualization? And for that matter, what is SDN? The obvious comparison used with network virtualization is server virtualization. These two forms of virtualization indeed have some similarities. For example, both network and server virtualization offer abstraction layers which can be used to partition and/or pool underlying physical resources. However, based on conversations I’ve had with enterprise IT professionals and others, it is much more difficult for most people to visualize network virtualization.
Comments and questions like these are common:
- Aren’t networks inherently virtualized? Yes, sort of. Traffic from multiple hosts certainly travels over the same switches and routers. Furthermore, even decades old network equipment provides many ways of isolating various types of traffic. But these approaches aren’t enough for today’s cloud networks.
- Aren’t virtual LANs (VLAN) network virtualization? Yes, they provide one example. However, they suffer from a number of limitations including how many VLANs can be supported within a given network and whether and how they can extend across various network topologies. Cloud networks need far greater scale and control than can be provided through VLANs.
- Aren’t virtual switches network virtualization? Yes, they represent another form of network virtualization commonly found in virtual server and cloud environments. Interestingly, they can get a bit tangled up (in terms of understanding them) with server virtualization. For instance, virtual switches often behave like a hypervisor and are sometimes part of a hypervisor. Virtual switches allow LAN switching capabilities to live within a server rather than only within physical switches on the network. This allows, for example, traffic from one VM to be sent to another VM on the same physical server without traveling off the server to a physical switch and back. Once again, this approach to network virtualization doesn’t solve all the problems in a cloud network.
Let’s move to another type of network virtualization – one supported by SDN. This is the type of network virtualization you are bound to hear more about over the coming months and years. Whether you are a cloud service provider or an enterprise IT organization, SDN-driven network virtualization is coming your way.
Software Defined Networking
Big Switch Networks is a leader in SDN and their view of SDN is not only intuitive and easy to visualize, it also sets the stage for much bigger thinking in the evolution of cloud networking. Now I’m not suggesting the folks at Big Switch Networks are the only ones to talk about SDN in this way. However, they were the first ones to share this perspective with me a year or so back.
They also provided this nifty diagram:
One of the first things to note in the diagram is the separation of the control and data tiers. However, that point is much better understood in the context of more traditional approaches to networking. So let’s take a quick side trip through that.
Traditional Networking: Combined Control and Data Tiers
If you are a certified network engineer or architect, perhaps you’ll take exception with some of the simplifications I’ll make. Still, I think this will clarify things for the vast majority.
In most current networks, switches and routers are responsible for activities in both the control and data tiers. When an IP packet is received on a given switch port or LAN interface, a primary job of the switch or router is to send the packet along to its “next” (possibly final) destination. By looking at the destination IP address, network routing tables, and so on, a decision can be made as to which switch port or LAN interface the packet should be sent next. This “decision making” is a big part of the control tier.
Another big part of the control plane involves getting the information needed for those decisions on to the switches and routers themselves. Routers use protocols such as OSPF and RIP to exchange routing information. Switches often use a variety of proprietary as well as de-facto approaches to determining where to send packets (e.g. listening to traffic and discovering the location of servers with particular IP addresses and LAN addresses so that forwarding information can be deduced). However, back when these approaches were developed – some of them decades ago – server virtualization was far from popular (mostly just mainframe oriented) and network configurations and topologies were far more static. So, these networks have a hard time keeping up with the speed of change in cloud networks.
Additionally, network equipment – and in some cases the protocols themselves (IP, RIP, OSPF…) – forces limitations on topologies as well as which paths packets can take to reach a given destination. Cloud customers want far greater control and flexibility over which IP addresses they can use, how they can design their cloud network topologies, how they connect their data center networks to the cloud network, and so on. Unfortunately, cloud providers must generally pick a single physical network topology and live with it. While they try to make it flexible enough for all customers they are limited by protocols and network equipment that was designed for an earlier era.
Enough said on the control plane capabilities for traditional networks.
The data plane is much easier to explain. Think of the data plane as having the basic responsibility of sending packets through a specified switch port or LAN interface. This is a fairly simple job that takes place after the control plane decisions have been made.
SDN – Pulling it all Together
With the perspective of traditional networks in mind, let’s get back to the SDN diagram.
SDN splits the control and data tiers. The relatively simple (sometimes called dumb) data tier is left to the switches and routers, both physical and virtual. Now, rather than using traditional routing protocols and built-in algorithms to forward packets, they simply “do as they are told.” With the data plane now doing exactly what it is told, it becomes far more flexible and easy to control. That is just what is needed for cloud networks.
OK, so who tells the elements in the data plane what to do? Basically, it is the control tier which has been pulled out of every individual switch and router and then centralized. One cool thing about the control plane is that, unlike many traditional routing protocols, it can take a comprehensive and holistic view of the entire network. Routing decisions don’t simply have to answer “how do I get to the next hop?” They can take an end-to-end perspective (and more). The control plane can also take a complete view of individual tenant networks. Simply put, the control tier can be used to create any number of virtual networks with any type of behavior that can be supported by the underlying physical connectivity.
And how do the switches and routers get the information they need? Protocols like OpenFlow (shown in diagram) are used in order to very quickly and reliably keep the switches and routers up to date with their forwarding instructions (and another other control or decision making information). This takes much of the responsibility – and most of the limitations – out of the hands of “the network.” The network becomes dumb and the expensive switches and routers can lose much of their value. This is why some of the articles you have read suggested that Nicira is a threat to Cisco, Juniper and others. (Of course there is more to say here and there will certainly be hybrid SDN and traditional networks. The games have just begun…)
Now there is one last tier to consider for understanding the title of this blog: Network Virtualization and Beyond: How SDN will forever Change the Cloud Network
Network Virtualization is Just an SDN Application
By putting an API on top of the control tier, applications can be written to control the underlying network (or virtual networks within it). This is software defined networking. You write the software that tells the entire network how to behave!
If you want to “virtualize” a cloud network, giving nearly complete control of private virtual networks to individual tenants, you can write an app for that. In fact you can write many different apps for that. Virtualized networks are not limited to the existing notion of VLANs or any other fixed construct. They can have member, traffic flows and behaviors that are all determined by the programmer.
Alternatively, cloud service providers could open up limited API capabilities to their tenants. This would allow tenants to programmatically control their own private virtual networks without impacting the behavior of other tenants.
SDN opens up nearly limitless possibilities. Network owners could write an SDN security app. For example, they could ask any set of switches or routers to forward packets with a given profile to another application for further analysis. Or they could write an SDN application for QoS. The list goes on…
Simply put, the emergence of software defined networking ensures that cloud networks will never be the same.
[As a teaser for what to watch for in this space, please consider the “open” question. Companies like Big Switch Networks are pushing for open APIs, open source and open protocols such as OpenFlow. There will certainly be others who insist on more closed and proprietary approaches. There will also be a battle between hardware and software network components. And there will certainly be challenges to physical network incumbents such as Cisco, Dell, HP, Juniper and others. And watch for players like Citrix – already a force in virtual networking with NetScaler VPX Application Delivery Controllers – to increase its efforts in software-based networking. The cloud network is going to get a lot more exciting!]
]]>
Table of Contents
Reader comments
What will happen to
Posted by Naveen
What will happen to Conventional Network admin jobs?
And troubleshooting an entirely software defined flexible Network, if something goes wrong?
And each vendor will bring his or her own SDN leading to VDN–Vendor Defined Network…
ALl thats inside the cloud….for clouds to connect to each other u still need WAN links and routers..
AND WHAT IF CISCO STEPS into this new concept..which it will do in due course…
Also How do you draw and represent a SDN Network diagram?
How do you vizualize a path take by packets across a SDN network?
Not all companies will adapt to Cloud comptuing which has been in the market for over 5 yrs.
How do you check and control which end point is sending too much traffic?
SDN Questions
Posted by neovis5
Hi Naveen – these are excellent questions. Thanks for posting them!
While I can’t claim to have answers to all of them, they are great examples of questions that come up with disruptive technologies. For example, as SDN becomes more widely adopted I fully expect some things to break. Some problems will be resolved, others will not. As long as the net value is still high compared to the alternatives, then SDN will survive. Personally, I expect it to thrive.
Now, on to some of your specific questions… Troubleshooting will be different. Existing tools will have to become SDN aware and modified to find and fix new kinds of problems.
As far as VDN or vendor defined networks… we have that now. The switch market is packed full of proprietary devices and fabrics. Using open approaches and protocols like OpenFlow can help here. Still, I agree that that VDN will likely be a challenge no matter what underlying technologies are used.
SDN does not have to be confined to a cloud environment or even to a data center environment. Though I agree you will need the WAN links and routers.
Agree that Cisco will do more with this over time. I think that will be a good thing overall. We don’t need a major player in the network equipment world trying to keep the industry in the physical world.
Great question on drawing and representing SDN networks in a diagram! It can certainly turn things inside out in terms of how we have traditionally thought about and drawn networks. I imagine there will be visualization tools that provide different view… One view or one diagram will not be enough.
I agree that not all companies will adopt cloud computing. Though if you define it broadly (IaaS, PaaS, SaaS) then nearly all will! I think the jury is still out on what percentage of enterprise IT will be in a public cloud. I think that has been over-hyped with many people saying the enterprise data center will disappear in 5 or 10 years. No way! I don’t think it will ever disappear.
Regarding end points sending to much traffic… generally speaking, once you decide to take action on certain traffic (from a particular node, app, etc.), you push out rules through the control plane to all SDN devices that are impacted. You’ll still have monitoring tools available to detect and troubleshoot issues like that.
Again – great questions. SDN will have ripple effects throughout the data center!
Paul
Recent blog posts
- Cloud Environments for Big Data — a Neovise Cloud Perspectives Podcast
- Succeeding as a Cloud Service Provider — a Neovise Cloud Perspectives Podcast
- Scalable Storage without a High-Speed Network — a Neovise Cloud Perspectives Podcast
- Neovise Research: Welcome to the Multi-Cloud World
- The Battle for Service Provider Clouds
- Cloud Predictions and Trends for 2013
- Low Margins for AWS: Not Driven by Economies of Scale
- Public Cloud for the Enterprise: A Podcast with Andi Mann, VP CA Technologies
- OpenStack Update: A Podcast with Boris Renski, Co-founder and CMO of Mirantis
- Cloud Connect Chicago, ProfitBricks Podcast with Bob Rizika, U.S. CEO and Achim Weiss, CEO Germany