Mobility

Software Defined Networking: The Cisco approach

Software Defined Networking (SDN) is generating interest in the networking realm. Learn why it's important, what Cisco is doing about it, and what the competition has to say about that.

It’s a common trend among writers and filmmakers to offer up their particular take on a theme such as mistaken identity, opposite attraction or revenge. Similarly, the technology realm is populated with vendors offering their own blend of a common concept such as a Linux distribution, handheld tablets or networking trend.

Unlike fictional stories, where genuinely new plots are excruciatingly difficult to find, new advances in technology continually open new possibilities as well as markets for vendors who demonstrate evolutional agility (of course, one might argue that “new themes” such as cloud computing and thin clients are just recycled topics from the past).

One such example in the networking realm is software defined networking, or SDN. It’s a relatively young concept that was projected in 2012 by the market intelligence company IBC to become a multi-billion dollar industry in 2016.

What is Software Defined Networking?

Well, would you like the technical answer or the functional answer? Let’s start with the first option.

OpenNetworking.org provides a definition of SDN: “the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.” A good document on the OpenNetworking.org site explains the topic further by stating “in the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications. As a result, enterprises and carriers gain unprecedented programmability, automation, and network control, enabling them to build highly scalable, flexible networks that readily adapt to changing business needs.”

Say what? Let’s break it down further and get at that functional explanation. The purpose of SDN is to separate traditional network traffic (this can apply to wired or wireless) into three components: raw data, how the data is sent, and what purpose the data serves. This involves a focus on data, control, and application (aka management) functions or “planes” which map to the infrastructure, control and application layers in the following diagram:

matt1.jpg
 Photo: www.opennetworking.org
 

Those readers familiar with the OSI model (a staple from MCSE and Novell certification courses I took in my younger days) will recognize the separation of functions at play here.

OpenNetworking states the above diagram “depicts a logical view of the SDN architecture. Network intelligence is (logically) centralized in software-based SDN controllers, which maintain a global view of the network. As a result, the network appears to the applications and policy engines as a single, logical switch. With SDN, enterprises and carriers gain vendor-independent control over the entire network from a single logical point, which greatly simplifies the network design and operation. SDN also greatly simplifies the network devices themselves, since they no longer need to understand and process thousands of protocol standards but merely accept instructions from the SDN controllers.”

So, to recap:

Infrastructure layer (“Data plane”)

Network switches and routers and the data itself as well as the process of forwarding data to the appropriate destination.

Control layer (“Control plane”)

The intelligence in devices which works in true “middle-man” fashion, determining how traffic should flow based on the status of the infrastructure layer and the requirements specified by the application layer. The model here is centralized (either physical or logical) rather than distributed across various and possibly disparate devices.

Application layer (“Application plane”)

Network services, utilities and applications which interface with the control level to specify needs and requirements. These may be what is known as “network aware.”

The network hardware you’re probably familiar with performs much or all these functions; the goal of SDN is to offload the handling of traffic and the way it meets the needs of the applications involved. For instance, the control layer might reside on a server and the application layer as a software-based application programming interface (API). This means the hardware which handles the network traffic doesn’t need to direct it or deal with management, making the environment more flexible and adaptable.

A more complex diagram can be found in a follow-up piece by OpenNetworking.org titled “SDN Architecture Overview”:

matt2.jpg
 Photo: www.opennetworking.org
 

If you’re not a full-time network engineer (or maybe even if you are) the above image may be a bit overwhelming. Look, I realize networking can be a bit dry without subjective, contextual examples. Here’s a real-world analogy for SDN that hits close to home (for me, anyway).

Let’s say I go on a car trip with my wife and children. As is usually the case when I drive on a road trip, I’m just operating on autopilot, representing the data (our van) on its journey down the network (the highway). This includes the molecules of the vehicle, the occupants, the juice boxes and the stale goldfish traveling along. That would be the infrastructure layer.

My wife has her iPhone and sees that there’s a traffic jam up ahead, so she directs me to get off the main highway onto a secondary road. “Go 7 miles and then turn right onto Route 110,” she instructs. She serves as the actual intelligence on where we’re going and therefore is the control layer for our trip (this in no way is intended to represent any other area of our involvement, of course!).

In the back seat, our younger son politely asks for twelfth time when we’re going to be there (yes, kids really do this). After we reply “in a couple of hours” he asks us to buy him dinner. My wife checks her iPhone to see which restaurants are nearby and explains the detour I’ll need to take to get us there. This is the application layer, since it defines our purpose at the moment and the requirements being made of my wife, aka the control layer.

Why SDN?

So, we’ve established SDN can make the network more flexible and adaptable, but what else? Why is this such a big deal? Well, by taking this approach you can have a more diverse, scaled-out environment that can add benefit to your local datacenter traffic or when extending the network outside the organization.

Can you guess two exploding trends which have the potential to greatly benefit from SDN? If you answered “the cloud” and “virtualization” you win the Kewpie doll! With both of these functions comes the need for better traffic management to handle scalability, delivery of critical data, increased bandwidth requirements, and faster provisioning of network services. SDN is intended to fit that need through these possibilities:

The ability to apply higher level “bird’s eye” policies to shape and reorder network traffic based on users, devices and applications.

  • A cloud application might handle the direction of network traffic to ensure load balancing across servers or to deliver data via the fastest and most efficient routes.
  • Automation can help enhance the reliability and simplify the network framework by implementing a more consistent, predictable environment.
  • No longer are network resources limited to a device-by-device configuration with a weak link in the chain that just might be ready to snap.
  • Open-source SDN APIs can be used or written by networking staff to help further the capabilities.
  • Security is also touted as another advantage to SDN and certainly that’s another issue of tremendous importance today.

SDN is based upon open standards. OpenFlow is one such example and has been defined by the Open Networking Forum. It utilizes virtual device control and a standard instruction set. Policies can be applied to network traffic and APIs are available for use or can be programmed by users.

Since SDN standards are open, no one vendor holds the key to it, but this concept is being built into vendor devices as they enter the space. Since Cisco holds the market share lead in the networking space, let’s take a look at how they’ve begun getting their feet wet.

What is Cisco’s approach to SDN?

Cisco’s approach is both software and hardware based.

On the software side, Cisco states they are embracing the OpenFlow standard, though they feel it has some limitations in the areas of management/monitoring, data forwarding, data packet and service administration and the concept of distributed control. To clarify this last, “Direct access to decentralized device APIs opens a broad range of application possibilities that are not available in an OpenFlow centralized model. A hybrid approach, combining direct API access on a device to augment API access via a controller, may well be the optimal balance between centralized and decentralized control planes.”

With that in mind, Cisco developed the Cisco Open Network Environment (ONE) for network programmability which is intended to solve the limitations referenced above and “address challenges of WANs and data centers, as well as campus networks.” An entry on the Cisco blog states one of the strategies of ONE is to “build scalable multi-tenant cloud infrastructures with operational experience between physical and virtual.”

matt3.jpg
 Photo: blogs.cisco.com
 

ONE allows direct programmability of the Cisco environment. It comes with a toolkit called One Platform Kit (OnePK) which allows you to create automation policies, set up route instructions and build network services.

Despite the phrase “software defined networking,” Cisco feels software isn’t enough. It lacks scalability, manageability and reliability without the hardware infrastructure, in their view. So on the hardware side, a concept called Application Centric Infrastructure (ACI) is the name of their game and they’re playing it through a spinoff company called Insieme.

ACI is based on a new line of Nexus 9000 switches which run at high-density 10 Gb Ethernet (10GbE) or 40 Gb Ethernet (40GbE). It will be possible later in 2014 to retrofit ACI support onto existing Nexus 7000 switches, however, which will eliminate the need to upgrade physical hardware for customers currently using the Nexus 7000 series. Insieme switches use optical transceivers to permit the use of existing 10GbE cabling as customers upgrade to 40GbE Ethernet, which will help them avoid having to recable their environment during this process.

ACI includes an SDN controller called the Application Policy Infrastructure Controller (APIC). The APIC resides between the network and the applications and implements application policies to permit data center switches to act as a single network and provide the capability to manage thousands of ports. ACI can automatically provision network segments for specific applications and apply a range of policies and networking services to these (such as Quality of Service or QOS).

Cisco says that APIC will accept homegrown APIs and customers can obtain “open device packages” to allow existing network hardware not part of the ACI infrastructure to be governed by the APIC. Two of the APIs which ACI will support are XML and JSON for network management, for instance.

VMware and Nuage Networks provide similar functionality to ACI via software-only environments (Take note of this; it will be important later in this article!). They are strongly involved in the virtualization space. Cisco’s approach includes network virtualization, but the overall scope is based on the concept that applications are the most important focus of the network and these therefore should drive the purpose of the network.

Criticisms of Cisco’s SDN implementation

Cisco’s approach is not without some controversy, although it’s important to note that some of this controversy has been produced by Cisco competitors with a stake in the game.

Rivka Gewirtz Little of SearchSDN.techtarget.com reported in November that Nuage CEO Sunil Khandekar:

“[has a problem] with Cisco ACI [in] that it creates ‘pods’ of programmable networks but doesn't go beyond the internal data center to address the WAN or inter-cloud connectivity. Nuage uses IP networking to peer routers at the edge of a data center, essentially extending network overlays through a VPN. This stretches the control plane across multiple domains.

‘What we are talking about is not a single data center problem; we are talking about [connecting] multiple data centers,’ Khandekar said. ‘They haven't talked about how to connect data centers back to users over a VPN. There are a lot of things missing here.’

Creating these ‘islands’ of automation will make it difficult to integrate networks into a larger orchestration framework within a data center, and even more difficult to extend orchestration among multiple data centers, he said.”

Mike Banic, vice president of global marketing at HP Networking pointed out that the full benefits of Cisco ACI are only made available in an all-Cisco shop. Banic stated “Cisco should have embraced emerging industry standards that would allow controllers to work across multivendor environments.”

Not only is the Cisco outlook under scrutiny, but SDN itself has been subjected to skepticism along with it. Steve Mullaney, senior vice president and general manager of VMware’s Networking & Security Business Unit, stated in a January 13 interview withNetworkWorld.com that SDN was more of a “philosophy” rather than a “thing” and that a properly executed virtualization strategy would render it unnecessary to “have to touch the physical infrastructure.” In Mullaney’s view the SDN “vision will never happen” due to a lack of necessity, since a properly implemented virtual environment would eliminate it.

In comparing the VMWare approach to Cisco’s, Mullaney stated “How we go about it couldn’t be any more different. It’s the complete opposite. We believe in the software-defined data center. We believe in the power of virtualization to enable that. We believe in the power of decoupling software from the physical infrastructure. Cisco came out and said, “We believe in the hardware-defined data center. We believe in the power of ASICs. We believe in the power of coupling the software to the hardware. We believe in coupling the software not just to any hardware but to our hardware. And oh, by the way, it is also our new hardware so you will need to rip out your existing infrastructure and replace it.”

Insieme’s Frank D’Agostino, senior director of technical marketing and solutions engineering, presented a lengthy rebuttal to Mullaney’s statement in the comments section of the article. Among other things he stated the VMWare pricing model is “flawed,” that VMWare is equally guilty of proprietary lock-in, and ACI was a lot more open than Mullaney had given it credit for.

Here is a full rundown on thecompeting views towards SDN between VMWare and Cisco.

Mike Fatto of Networkcomputing.com stated in 2012 that the SDN concept would fade away in 2014 due to growing pains and it “will be reborn as network management.”

Taking control away from the network devices can lead to significant problems if the unexpected pops up (when does THAT ever happen in IT?) Of course, if the controller(s) have an issue, the whole arrangement can also belly-flop. There’s no ironclad guarantee against loss of service if the focal point is merely switched from one place to another without sufficient accompanied redundancy.

Conclusion

I’ve been searching for some time for details on the percentage of technology trends which thrive versus those which fail. It’s an elusive subject; some concepts fail and are then reborn later (the way Apple breathed new life into the stale tablet space is a perfect example) whereas others die out entirely (Netbooks are likely on their way out).

If SDN doesn’t gain traction it will likely become subsumed into something else. I don’t see that as likely, however. There’s a networking evolution (revolution?) going on right now which is turning the classic LAN/WAN environment into a bigger, more complex and needier sort of beast and so SDN will likely gain momentum as vendors stake their claims and the advantages are realized.

Cisco’s hardware/software approach is deemed by some as too top-heavy but by covering more bases may prove the resilient contender. Software-only vendors may prove otherwise if their products succeed, however, rendering hardware more of a “dumb driver operating on autopilot” (no comparison to yours truly).

Regardless of who comes out on top, it will be interesting to see how the various possibilities and vendors versions fare in the months and years ahead… and quite likely SDN will play a factor across many disciplines of IT so I recommend keeping an eye on the subject.

About

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.

0 comments