Archived Content

The following content is from an older version of this website, and may not display correctly.

CIOs of modern-day data centers are concerned about elasticity, agility, end-to-end guarantees in the face of client-device mobility as well as workload mobility, and a scale-out infrastructure that can support these attributes. This driver for elasticity and agility is realized in the network via the promise of network virtualization.

With the introduction of network virtualization, complete data center virtualization was achieved. Products like the VMware NSX enabled data center administrators to dynamically provision networking with the same elasticity and agility, as they could provision their virtualized servers and storage, and hence adapt quickly to their changing business needs. Moreover, a network hypervisor would decouple all the complexities of the physical hardware, reducing opex and enabling cross-data-center workload migrations, effectively eliminating the physical and geographical boundaries of a data center network.

Network virtualization is therefore primarily about a reduction in opex, due to a reduction in provisioning times for workloads deployed in the data center. Now, provisioning is just the first step in the deployment of a business application, such as a typical three-tiered web-middleware-database enterprise application. Provisioning is the intent.

Whether the physical network can support that business application's networking service-level agreement (SLA) is completely dependent on the capabilities (topology, bandwidth, queues, other traffic patterns, etc.) of the underlying physical network.

Put it this way: Imagine picking up the phone and finding that there is no dial tone.

(I know, I know, picking up the phone is not really the provisioning step, and there is a lot more that happens before one gets a dial tone, and the dial tone doesn't guarantee that the destination is available. But such a long, wordy sentence wouldn't make for a catchy blog title, would it? And the dial tone analogy largely captures the spirit of the problem.)

Some vendors are promising exactly this utopia to their customers: Buy our software-only solution, and you will not have to worry about your "calls" (data center traffic) completing. Hence, network virtualization, of the overlay network kind, is the only drug you need.

Now, we are big fans of network virtualization, and of overlays, but we do believe that the virtual needs to tie in with the physical -- the provisioning (intent) needs to tie in deeply with the delivery (run-time), and the service-level agreement (SLA) definitions need to be directly mapped to available network capability -- to extract maximum benefit out of your network.

So what are some of these tie-ins that might be needed for assurance that what is being provisioned is what will be delivered? Gateways (to bridge between the overlay and non-overlay parts of the data center); a connectivity service to enable application patterns for business application deployments; visibility of the virtual in the physical layer; and path computations and traffic spread based on tenants and application traffic are some such examples.

What should be evident from this discussion is that for any SDN enablement to be successful in the data center, the SDN controller needs to simultaneously control and manage both the virtual and physical tiers.

The OpenDaylight Project (ODP) provides such a framework and the basis for such a deployment. The OpenDaylight controller is modular and plug-in based, enabling a mixed environment of virtual, physical and cross-data center networking, with an abstraction layer that can be used to optimize between these tiers. Not everything exists in ODP today, ready to be deployed, but a large portion of the promise is expected to ship in Q4 of this year, and the architecture definitely supports this vision.

We may finally be able to provide that dial tone.