Software-Defined Cloud Networking: Hype or Reality?

I have been pleasantly surprised by the rapid adoption in data centers of cloud networking architectures in just the past two years. Cloud computing has stressed the ability of the network to scale in previously unimagined ways, challenging just about every traditional switch metric from the size of L2/L3 address tables, destination address flooding, increased broadcast and multicast traffic to an explosion of subnets and routing protocols. Compounding these challenges has been the shift in traffic patterns from client-server “north-south” traffic to far greater use of “east-west” server-server communications, resulting in a perfect storm in networking. The advent of high performance applications (e.g., Hadoop-based analytics), network-based virtualization across data center boundaries, and access to direct and network attached storage (iSCSI/NAS) have led to the creation of the new cloud network, an innovation that was pioneered by Arista three years ago.

Trends in Software Defined Networking:

The accelerated deployment of high performance cloud networks is revealing limitations in today’s control planes and loosely structured legacy topologies. A more predictable control structure is needed. In particular, two key trends are driving the rise in the need for cloud-control: network topology evolution and virtualization.
Structured Leaf-Spine Topologies. Cloud data centers typically are built on a tier of identical aggregation/spine switches (e.g., the Arista 7500) connecting to a large number of top-of-rack /leaf switches (e.g., the Arista 7048/7050/7100) in a full mesh topology. Cloud architectures are more economical to scale within a data center network because they are built and operated in a uniform manner.
Virtualization. Server virtualization vastly increases the number of addresses seen by the network. In addition, it increases the number of switches, as every server now includes a soft switch. Virtual Machine (VM) migration, server consolidation, and unified storage all increase the amount of network I/O required per server, driving the need for additional east-west bandwidth within the data center. By decoupling physical infrastructure from applications, virtualization discourages islands that only optimize one segment of the network for one particular application. Instead, it makes sense to provision the entire network to seamlessly handle any application anywhere on the network so that the economics of virtualization can be properly leveraged.
What is clear is that cloud networking needs an appropriate software foundation (such as Arista EOS) using well-defined and open controller APIs to communicate between the network and the controller for the control of cloud scale and explosion.

What about Open Networking Foundation, OpenStack and OpenFlow?

There was a lot of hype, promise and positioning on OpenFlow at Interop 2011 last month. OpenFlow is promising and is well regarded as the leading open implementation to date for providing software defined networks within the research community. OpenFlow 1.1 is in the standardization process and in theory offers more substantial flexibility than do most switch silicon pipelines. This means that any practical OpenFlow 1.1 implementation in the next few years will be based on specific use cases and the instructions the controller can load into the switch. Organizations such as the Open Networking Foundation (ONF) and OpenStack (sponsored by Rackspace) are championing the importance of standards-based interoperability as well. Arista welcomes these efforts and is contributing to the community and customer needs with real world use cases rather than feeding into the marketing frenzy alone.

Arista EOS supports Controller-Defined Cloud Networking:

Arista switch platforms running Arista EOS (Extensible Operating System) present an ideal environment to enable fine-grained traffic engineering utilizing a variety of forwarding actions. It was designed from the ground up to support extensible APIs for software-defined controllers. Each EOS function runs in its own restartable protected address space, much the way daemons run in Linux. In fact, a wide variety of Linux software can run directly on top of EOS, including general-purpose Linux software (such as tcpdump or fping) as well as controller-specific software such as the OpenFlow client reference implementation. In theory, nearly any controller scheme with a Linux-based client-side implementation can be ported to Arista EOS. We have also demonstrated that EOS supports running virtual machine images directly on the switch, enabling support of many non-Linux applications. Architecturally, Arista EOS implements a complete switching stack with extensibility API's that enable configuration of many of the standard layer 2/3 features based on instructions from the central controller. With Arista's EOS one can host the client portion of any controller-based system, communicating with the central controller and programming the switch's forwarding plane accordingly through the EOS-unique System Database (SysDB).

Controller-Defined Networking Examples: Arista CloudVision and VMTracer

Arista’s award-winning CloudVision™. is a classic use case of controller-based networking, offering open standards-based tools to monitor switches individually or as groups of switches within one single view. Clustering and management capabilities are virtually limitless as users and developers can integrate CloudVision™ into existing management infrastructures. Another prime example is VMware’s vSphere which enables central orchestration of virtual and physical network-wide configurations using Arista’s VM Tracer. This paradigm can be extended to other controllers as well. Many new controllers are emerging in the market from many companies and university organizations which offer promise for the next decade.
Furthermore, a rich set of cloud networking features such as sFlow for monitoring, zero-touch provisioning (ZTP) for automation of large numbers of racked servers and watermarks for congestion management using Latency Analyzer (LANZ) all make Arista EOS and switches an ideal foundation for controller-defined cloud networking.
Controller-defined Cloud Networking offers the potential to improve data center networks along several dimensions of control plane management, performance, and determinism for the next decade.
As always, I welcome your views at feedback@arista.com.
References:

• Cloud Networking White Paper
• Building Cloud Networks - CloudVision Technology Bulletin
• Arista 7500 Video by Andy Bechtolsheim
• EOS Central Website