The Software-defined Data Center (SDD), SDN, Network Virtualization…

This week I was at Interop 2012, the premier event for networking folks – in his keynote, VMware CTO, Dr. Steve Herrod introduced the notion of Software-defined data centers (SDD). To summarize some of Steve’s comments – “Specialized software will replace specialized hardware throughout the data center… SDDs will redefine infrastructure for the next generation of applications… We need to move beyond VMs to virtualizing the rest of the data center, including storage, networking & security – this new container is the Virtual Data Center (VDC)… Organizations could operate virtual data centers in which all the infrastructure services are delivered as software and the control of the data center is entirely driven by software.”

While VMs can be provisioned in minutes, provisioning the rest of the data center (storage, networking, security, etc.) takes days – the SDD vision, with the VDC container holds the promise of bringing this down to minutes, unleashing a whole new level of agility in the data center.

The SDD concept builds upon the Software Defined Networking (SDN) movement, which is the latest area to gain the attention of the IT industry, including researchers, investors, vendors, enterprises and cloud providers. Between the recent Open Networking Summit and Interop, we are seeing an extreme makeover within the networking industry – we haven’t seen so much excitement around networking in a long time.

Networking (and security) architectures have just not kept pace with the agility, efficiency and elasticity requirements of modern data centers. This is where SDNs (and Software-defined Security – SDSec) hold promise. The Open Networking Foundation (ONF) has done a tremendous job in rallying the industry behind the need for SDNs, and jumpstarting the movement to a new era of networking.

The Open Networking Summit was a celebration of the momentum in the space, and rightfully so. By far, the hit of the show was Google’s public disclosure of their dramatic use of OpenFlow to control their backbone traffic; Google effectively replaced routers with some Marvel chips, an ATCA chassis, and traffic engineering in place of routing, all using open source. Remarkable!

However, in the midst of all the excitement, one topic stood out – we as a collective whole, are not clear on what SDN really means – is SDN the same as OpenFlow? Is SDN a reference architecture? Is SDN a marketecture? Is it prescriptive? Here is a summary from Nick Lippis: What I Learned at the Open Networking Summit about Software-Defined Networking

At the ONS closing panel of ONF members hosted by Dr. Guru Parulkar, Executive Director of ONF, we talked about two possible views on SDN:

On the left is the classic view of SDN and OpenFlow. The OpenFlow Controller controls OpenFlow devices, and exposes tenant-specific slices to applications above. This enables research slices, Google Traffic Engineering, and other innovative applications. To a large extent, OpenFlow is used to replace the existing control plane in networking gear, as long as such gear have OpenFlow agent support.

On the right is a more pragmatic view of the SDN stack. Instead of using the OpenFlow protocol to control OpenFlow devices, we enable network virtualization by provisioning on-demand overlays on top of existing networking gear and fabrics. VMware has teamed up with several networking, NIC, ToR, switch, and silicon vendors to create high performance VXLANs. These are controlled by the network virtualization controller, which makes logical networks available to higher level applications such as vCloud Director.

In this model, network virtualization follows the footsteps of server virtualization:

  1. Abstraction: We abstract switches, switch ports and NICs (vSwitch, vPort, vNic)
  2. Pooling: We pool together switches (VDS), switch ports (VXLAN), thus creating the notion of an elastic Ethernet, than VMs can join/leave on an as-needed basis
  3. Slicing: We can assign isolated VXLANs to different tenants, or lines of business, or app owners. Each VXLAN has a tenant id (VNI).
  4. Finally, virtual data centers (VDCs) can consume these logical networks (VXLANs), on demand to interconnect compute, storage, etc.

In this model, we do not try to influence the specific path a flow will take through the network. Rather, we rely on ECMP to spread the flows across the fabric, leveraging as many of the paths as possible. Also, in addition to layer 2 network virtualization, we have begun to repeat the same abstraction/pooling/slicing/consumption paradigm for L3-7 network services like firewalls, load balancers, IPAM, VPNs, all logically inserted into the virtual plane.

Note that, as OpenFlow makes its way into fabric gear, we could go one step further, and pin VXLAN flows, if needed, leveraging the OpenFlow protocol.

The key in this architecture is to allow innovation to simultaneously proceed, above the SDN layer (Network Services), within the Controller, and beneath the overlay.

I don’t believe the left and the right views are in conflict with each other. But having a reference architecture with identified interfaces, especially the “north-bound SDN APIs”, will be key to unleashing the power of SDNs…

These are the early days of the next generation of networking, as SDNs take shape. Regardless, Software-defined Data Centers, including SDN and SDSec, and the evolution from VM containers to VDC containers, is on its way to becoming a reality – it is just too compelling!