Lippis Report 185: Why Software-Defined Networking and Virtualized Networking Are Inexplicably Linked
Computer networking vendors have been increasing the speed and port density of their Ethernet switches while reducing power draw and price per port. But while Ethernet switching hardware marches on linearly, thanks to 10, 40 and 100GbE, networking software is taking a different historical path as the pace of compute and network technology evolution has diverged, with networking lagging. Highly virtualized server deployment has broken traditional networking approaches on multiple levels, for example. In response, the industry is now developing a “virtualized infrastructure” or “stack” to add network flexibility. To close the technology gap, Software-Defined Networking (SDN) is promoted as the new “organizing principle” to deliver network software and service value. While it will be, likely, years before SDN’s organizing principles take hold, I propose that these two industry activities are inexplicably linked and phased; here’s why…
Catalyst 6500 Sup2T 802.1ae MACSec Throughput Performance
There are multiple definitions of SDN. Making it even harder to pin down SDN, the definitions are evolving too. But this is common in a new breakout space for the computer networking industry that’s evolving fast. For this Lippis Report Research Note, we take the SDN definition that is based upon splitting the data plane or the forwarding hardware of an Ethernet switch from its control plane or the logic that controls how packets flow from ingress to egress. This split of data and control planes opens up an innovation injection point into networking that has not been previously available.
During 2011, a market has opened up for controllers. Currently Big Switch Networks, Nicira Networks and NEC are offering standalone centralized controllers. But limited controllers are also available in open source software, OpenStack and VMware’s vSphere/vCloud too. In addition Cisco’s IOS, Juniper’s Junos, Arista’s EOS, etc., are distributed controllers that may interoperate with centralized controllers in the future. In fact, Arista’s EOS already supports OpenFlow, OpenStack and vSphere/vCloud.
Brocade VDX™ 6730-32 Data Center Switch
The link between the separated data and control plane is an open interface called OpenFlow. Now some end their SDN definition here, but this is just the beginning as the real promise of SDN are the applications that will reside upon the controller to address a wide range of networking issues and opportunities. In fact researchers at Princeton and Cornell are developing the Frenetic programming language that provides high-level network abstraction that gives programmers direct control over the network, allowing them to specify what they want the network to do without worrying about how to implement it.
One can imagine a wide range of applications residing upon a controller such as WAN optimization, traffic engineering optimization, load balancing, security services, etc. In essence, the control plan allows network services that are currently deployed as appliances to be virtualized appliances/applications much like applications that reside on top of a VM. It gets even more interesting, as a centralized control plane can be easily split in to many little control planes, each of which sees its own slice of the data plane topology. In traditional networking where control and data planes are one and the same and in each box, it is much harder to merge control planes and split data planes. It’s possible, but harder to keep complexity and stability in check over the long term. Splitting control plans can have huge value in public cloud multi-tenant or private cloud multi-team networking.
Which Network Services Need To Be Available In Modern Networks?
SDN and OpenFlow are at the early stages of its industry matriculation. But one thing is clear: SDN is an organizing principle whereas network software is developed by both network vendors and third parties, and network services are virtualized. SDN thus represents a new industry order and structure as to how value is added to networks. But I digress. The real issue today is solving network inflexibility in the face of highly virtualized data centers.
Enter the “Virtualized Stack” or Virtualized Infrastructure”
Virtualized server deployment has been propelled en masse, thanks to increased data center efficiency, by delivering the same or greater application workload with a reduced number of servers. While this is good, many IT business leaders are now realizing huge consequences to highly virtualized data centers that span from IP address change management to application management.
Building A Smart Virtual Network Infrastructure With IBM
At the IP address level, networking has become extremely rigid within virtualized environments, slowing down process, limiting moves and changes as well as elongating the time to spin up an application that resides within a VM. Necessary network services to support the virtual cloud infrastructure, such as IP address assignment and management, are still performed largely with manual tools and processes, such as spreadsheets shuffled between various departments or operational groups, which can result in days of delay for something as simple as assigning an IP address to a VM. Contrast that with the virtual server administrator. Virtual instances of servers and machines can be dynamically provisioned, migrated and shut down by a virtual server administrator in minutes.
Moving up the stack, challenges are rooted in application management plus Layer 4-7 services such as WAN optimization, Application Delivery Controllers and security, especially in environments that include multiple hypervisors, a wide variety of workload types and shifting virtual machines.
Network Procurement: The Journey from CAPEX through TCO to Business Value
For example, the new challenges of enterprise application management in virtualized data centers include: what type of and location of network intelligence is required when multiple hypervisors and various workloads exist and shift? Also how do operations groups maintain consistent security policy across both virtualized and non-virtualized environments consistently? And how do operations groups monitor and maintain application flow visibility?
Cisco, for example, is addressing these issues via its Virtualization Stack and is now organizing its products around this initiative. Three components define Cisco’s virtualization stack, those being: 1) virtual networking, 2) virtual security and application networking services and 3) orchestration and provisioning. An important part of Cisco’s strategy is the virtualization of appliances such as its VSG or Virtual Security Gateway, the ASA 1000v, the support of VXLAN, the Nexus 1000v, etc.
Dormitory Wireless Is a Snap
Brocade, F5, Citrix
But F5, Citrix and Brocade are all virtualizing their appliances, moving away from physical single application appliances to an integrated virtualized suite. One can imagine that these virtualized applications will some time reside upon an SDN controller as their next stage of evolution. In addition each application delivery vendor has a way for programmers to control application network behavior. For example, Brocade recently launched OpenScript, a Perl-based scripting language used to modify the content of and control delivery of packets at Layer 4 through Layer 7 on its ServerIron ADX products. These scripting languages could be standardized and reside within an SDN controller.
A good example of what the virtualized Layer 4-7 future may hold is that of a start-up firm called Embrane.
Embrane has virtualized server load balancing, firewalls and VPN termination and placed them upon a distributed software platform called heleos. Heleos runs on x86 servers and any hypervisor. It leverages a distributed virtual architecture that decouples network services functionality from the underlying physical infrastructure and hypervisor technology that it says provides high scalability, flexibility and performance.
A Comprehensive Testing of Cisco Systems Catalyst 6500 Sup2T
IBM & NEC
IBM and NEC offer the best example of a commercial SDN offering with OpenFlow. NEC’s pFlow OpenFlow controller that resides within an IBM server manipulates IBM System Networking G8264 OpenFlow switch’s flow table. The link between the two is OpenFlow 1.0.0. The NEC pFlow controls traffic, discovers topology, gathers stats and other functions while the G8264 forwards traffic based upon these flow commands.
What’s impressive about the IBM/NEC SDN solution is that it has customers such as: Tervela validated the IBM and NEC OpenFlow solution ensures predictable performance of Big Data for complex and demanding business environments. Selerity’s IBM and NEC’s OpenFlow solution improved real-time
decision-making for global financial markets. Stanford’s IT Department chose IBM and NEC’s OpenFlow solution to deliver network capacity on-demand to its academic community. What’s important about these use cases is that IBM is communicating SDN via OpenFlow’s value in business terms, which will only increase as industry adoption accelerates.
In essence the SDN market has started, and as its technology underpinnings solidify, many of today’s network services will fall under the SDN umbrella. In fact, nearly all network vendors are launching SDN programs as a new way to communicate existing product value and their evolution into a SDN. Just like the Appian Way where all roads lead to Rome, all network services may very well lead to an SDN.