Lippis Report 187: Software-Defined Networking Needs a Bigger Definition

There are multiple definitions of Software-Defined Networking or SDN. But this is common in a new breakout space for the computer networking industry that’s evolving fast. The most common SDN definition 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. But this definition alone is too limited and needs to be expanded. In this Lippis Report Research Note, we offer the industry a broader SDN definition and view.

Cisco Systems Catalyst 6500 Sup2T VSS Throughput Performance

Visit the Link

First, the SDN definition that is based upon OpenFlow is important but too narrow. OpenFlow offers a standard-based Application Programming Interface or API that links an Ethernet switch and a controller. This offers a model in which layer 2 Ethernet switches are low-cost merchant silicon based devices where flows are directed by a centralized controller(s). While this is innovative and different, in reality it’s not that interesting. There needs to be much more to SDN and that can be found in what resides on top and along side of SDN controller(s) and associated benefits, both in terms of network design and operational models that it affords.

The Emergence Of A Virtualization Stack For Cloud Ready Data Centers

Visit the Link

From an architecture point of view, what resides on top and along side of the controller(s) is another API or set of APIs that promise to virtualize networking like VMware did for servers. With a yet-to-be-defined API on top of the controller, a software ecosystem needs to flourish.

Cisco Simplifies Network Virtualization via Easy Virtual Network

Listen to the Podcast

SDN Software Ecosystem

Applications such as traffic management, device configuration, network analytics and control, public-private cloud connectivity and security, firewalls, load balancing, etc., are examples of applications that could and should spring up in the virtualization domain, thanks to SDN. Much work is being done now to automate the network layer and virtualization stack into the virtualization domain via SDN applications that may or may not ride on top of an SDN controller(s). The centralization of network provisioning of layer 2 and 3 devices, firewalls, load balancers, VM stacks, etc., will be a huge SDN advantage as it lowers the number of operations staff required to manage a large network. Look toward management of physical switches in the management domain of virtualization engines.

IBM On A Smart Network Fabric

Listen to the Podcast

SDN Enabled Cloud Bursting

Enabling burst capability where a corporation can move workload between public and private clouds will be an SDN function. While there is layer 2 functionality available in some controllers today, to enable cloud bursting, this will move to layer 3 over time. But most importantly, SDN controllers are solving the security problem of workload mobility between public and private clouds today, which offers a huge network design and business agility advantage over existing approaches.

Which Network Services Need To Be Available In Modern Networks?

Listen to the Podcast

SDN Virtualized Network Services

While many firms, such as F5, Brocade, Cisco, Citrix, et al, offer virtualized network appliances, delivering such services within an SDN will offer huge server efficiency. For example, in highly virtualized data centers, memory restriction strands CPU capacity. Network appliances, such as firewalls and load balancers, typically consume little memory but much CPU processing capacity. Commodity servers inside of racks tend to be only 40% CPU utilized, thanks to lack of memory to run more applications upon those servers. These servers are, in essence, stranded, but a low memory, high CPU network application, such load balancing or firewalling, can utilize that un-used resource, increasing data center efficiency. SDN offers this efficiency and it’s a huge win. In an SDN environment, there will be a controller somewhere in the network, and if this runs in the virtualplex as an application then all of this server efficiency just comes to the IT architect, in essence, for free.

Easy Virtual Network—Simplifying Layer 3 Network Virtualization

Get the White Paper

Open SDN

The SDN market is evolving in an inclusive open fashion. The OpenFlow interface is open by definition. In addition, components of SDN controllers are being distributed to the open source community, such as Big Switch Network’s FloodLight. Also, FlowScale, a load balancer, RouteFlow which provides virtualized IP routing services over OpenFlow hardware, Open vSwitch and other projects including layer 2 provisioning, VM Migration, etc., are creating an open SDN environment.

Software Defined Cloud Networking

Get the White Paper

Mobile Market Shows the Way

The mobile market may show the way of how SDN will progress. The national mobile infrastructure is well automated to the point where a single network engineer can mange some 8,000 nodes. Most, if not all, large enterprises and cloud providers would welcome such efficiency. In addition, the mobile market, thanks to Apple’s iPhone and iPad plus Google’s android, has shown how a vibrant software ecosystem can add tremendous value and user choice. An SDN software ecosystem would offer IT business leaders with applications that change the nuts and bolts of networking suited to highly-virtualized environments plus solve some of the industries largest problems and opportunities, especially around cloud bursting and workload mobility. If SDN is able to automate network provisioning in enterprise and cloud computing facilities much like mobile networks today would fundamentally change the network operational model.

Your World Has Changed Is It time to Think about Unified Communications?

Get the White Paper

A Broader SDN View

The definition of SDN needs to be sufficiently broad enough to communicate the above value. To achieve that, SDN will move well beyond an OpenFlow-based definition to an application and capability definition. SDN promises to commoditize network hardware and provide a standard-based application development platform taking much of the features and functionality that exist inside custom proprietary software and driving it into an open SDN space.

A Massive 40GbE Test Report on the Extreme Networks BlackDiamond® X8Data Center Switch

Get the White Paper

But perhaps even more important is how SDN is implemented. In short, SDN promises to be deployed on under-utilized servers that IT organizations already own and operate. SDN promises to completely revolutionize the way in which we do networking. Trends in virtualization and cloud sourcing are only going to get stronger over time. Stranded CPU capacity in virtual engines is a significant previously unavailable resource to tap into and utilize. Running SDN controllers and applications in that domain is, in essence, free to IT organizations.

Think of it this way: IT business leaders will be taking this huge expensive IT infrastructure they currently own and operate to run SDN software and controllers in capacity that they weren’t capable of using anyway. That is a huge win. Add commoditized network hardware to the equation plus network application/service innovation to the mix, and you have a network environment for the new age of cloud computing. This is the promise of SDN and why it’s so important to every corporation, cloud provider and networking vendor.

3 Debates over Lippis Report 187: Software-Defined Networking Needs a Bigger Definition

  1. » Archives » Confusion over OpenFlow and SDN? said:

    […] recognized network industry experts are taking what appear to be opposing viewpoints. Nick Lippis, writes that Software-Defined Networking needs a bigger definition, while Tom Nolle says “The new space […]

  2. PDXmob» Blog Archive » Computer Science Colloquium said:

    […] [1] [2]… […]

  3. PDXmob» Blog Archive » Computer Science Colloquium: Software Defined Networking and OpenFlow said:

    […] [1] [2]… […]