Software-Defined Networking - A view from the top
February 11, 2015
Out of the loosely understood concepts of several years ago, Software-Defined Networking (SDN) has evolved into a framework that will usher in the nex...
What’s Cisco’s SDN strategy?
REED: When we look at SDN at Cisco, we see it as a key enabler to simplifying and automating a network. I look at SDN doing that in a few ways. One is the ability to treat the network as a system. If you think about today’s networks that are made up of all of these components, the beauty of SDN is the use of a controller in the environment that allows you to look at the network as a whole. That dramatically simplifies things for IT organizations and applications – basically anything that’s interacting with the network either because they’re trying to manage the network or because they need resources from the network. That’s a common theme around SDN.
One thing that’s specific to Cisco is our focus around using policy as a way to interface with that network as a system. And when I talk about policy, really what I’m talking about is moving from the “how” network interfacing of today, where specific configurations on devices for features like QoS, access control, etc., are enabled by talking in the language of the interface on a specific box. What Cisco’s doing with our strategy around Application Centric Infrastructure (ACI) is moving that interface to a “what” interface (Figure 1). So you just tell the network what you want – “I want to prioritize application A over applications B and C,” or “I want to allow all of the folks in the engineering department to have access to these resources” – and the ACI controller takes that intent and basically translates it into the changes that need to happen across the network infrastructure to make it possible. It’s hugely important because it really changes the nature of how all of the things that rely upon the network potentially interface with the network, and really simplifies and automates it.
 |
One analogy I like to use is thinking about how we used to take care of cars 30 years ago – you’d pop open the hood and really tune low-level components of the car like the timing belt, etc. Now when you think about how modern cars have evolved, I can just go in and flip the sport mode switch on my transmission and the car behaves differently. That’s the “what” in that I want the car to behave in a specific manner instead of having to go under the hood and change all the underlying pieces. You just interface with the car very simply as a system, and you’re off and running. So it’s really key to how we think about the network evolving, and what it enables is third-party applications being able to interface with the network much more simply because instead of having to know all the specific details of what’s going on, they can just tell the network what they want and then the network provides that.
In terms of the controller, are Cisco SDN controllers based on OpenFlow, homegrown, or something else?
REED: I’ll use myself as an example to start. I was working in the campus and branch environment, and though the switches that we and other vendors provide support OpenFlow, a lot of those boxes were built years ago. Just the way that switches work, and particularly how the networking ASICs on those boxes work, they can do OpenFlow but it’s not the most efficient way to make changes on the network.
The way that OpenFlow works is basically a rule set where you match against a set of rules, and if you have a match you perform an action. That’s essentially how the protocol works on the controller function and the data pipeline. In networking, ASICs have been very highly tuned to enable switching with the most speed, the lowest power consumption, and the least amount of cost. These ASICs are pre-programmed to do certain things as part of the pipeline, so they don’t naturally enable this generic match and action requirement of OpenFlow. If you look at a lot of the OpenFlow implementations on the switches that customers have been purchasing, they’ve all been done in CPU software, and there’s a real scale limitation to doing things at the software CPU layer versus in the network ASIC itself. So when you look at most of my customer’s environments, OpenFlow capabilities would dramatically limit the performance of their network infrastructure.
What Cisco did was look at how we could enable ACI – the principles of a policy-based network as a system – while taking advantage of the interfaces that those products have today to allow them to run at full line rate. It’s not super sexy. We use CLI, we use SNMP, we use almost any interface, and that’s one of the beauties of our strategy. In a lot of senses we’re pretty agnostic in terms of what the protocol is between the controller and the device. We want to enable the use case and the value that ACI can provide, and we don’t want to necessarily require that customers have to change out their networking infrastructure, particularly in the branch and campus environment. How we can deliver policy-based networking to an environment in a way that they can take advantage of the purchases they’ve already made.
We’ve got a lot of different capabilities in terms of the protocols we work with, but with that said, we’re also working on new protocols. An exciting example there is one called OpFlex. We talked about these policy-driven networks, and the idea behind OpFlex is that it’s basically a policy protocol between the controller and the switch (Figure 2). So, without OpFlex, the controller needs to essentially determine the policy to prioritize an application, and then figure out what it needs to do from a configuration perspective on each of the appropriate devices on the network to deliver against that policy. What OpFlex does is actually allow us to talk policy language to the devices, making the controllers work a lot less and the devices do more of the policy implementation locally.
 |
In general the protocol process is still relatively early in the maturity cycle, so I think you’ll see a lot of interesting developments on the protocol side that Cisco and other vendors are participating in.
When do you see SDN technology really hitting critical mass, and does Cisco plan to evolve with that progression?
REED: We’re close. We already have north of 200 customers that have deployed ACI, and I think that in this calendar year that number is going to increase dramatically. By the end of this calendar year you’ll see critical mass adoption of what we’re doing with respect to ACI, so it’s coming and it’s coming quickly, and we’re getting really great feedback.
In terms of how that’s changing Cisco, one of the key things that we focused on with ACI has been driven by the fact that SDN was such an abstract concept to customers. The, “I kind of understand what you’re talking about, but what does that give me?” So what we’re doing is looking at how to apply SDN and ACI to specific use cases.
Let me give an example. We have a capability in our routing infrastructure to do more intelligent path selection. So if you’re in a branch environment, the idea is to use cheaper broadband Internet links to connect branches because what we’re able to do with our technology is, even though they may be less reliable, take a couple of those links based on policies set with ACI and intelligently determine what link to send the appropriate traffic over. With secure encryption on top of that, I can provide a very robust, high bandwidth, potentially lower cost branch connectivity solution, and we call this Intelligent WAN (IWAN), which provides software defined routing services (Figure 3). We’ve had the building blocks for IWAN in our infrastructure for quite a while, but what we’re doing with ACI is enabling the adoption of IWAN, as part of our SD WAN strategy, much more easily. Customers can come in and set these application-level policies at the controller level, and then the controller takes those policies and enables IWAN across the branch routing infrastructure. So what you’ll see is more and more of our development resources working to integrate what we’re doing with SDN and ACI with the underlying functionality in the network infrastructure to be able to go out and provide these broader level business capabilities.
 |
The beauty of this is that as a standalone capability, SDN is interesting, but it’s more, “I can deliver much better application performance to users in the branch than I did before,” or “I can automate the remediation of a security vulnerability because with just a couple of REST API calls my Sourcefire security solution can quarantine a user that has malware or is acting suspiciously.” There are all of these interesting use cases that, once you get to policy-based networking, become much easier than they’ve been in the past. In the next five years you’ll see a whole set of things that Cisco does, but also other third parties like Citrix and Lancope, that can take advantage of the network and policy-based abstraction to get the network to do more and more creative and useful things for businesses.
Do you see SDN threatening Cisco’s dominance in network equipment, and does it force the sale of commoditized hardware?
REED: No, and here’s why. I actually think that SDN will play into the end-to-end capabilities that Cisco brings. If you think about having the network behave in the manner I described, so much of it cuts all the way across the network. All the way from the user like myself, connected wirelessly in a branch or campus environment, all the way through the network to the application that’s sitting in the datacenter or the cloud that I’m getting access to. Those are the types of use cases that I’m seeing customers ask for, and Cisco, because of the breadth of our capabilities in the market is uniquely positioned to enable that end-to-end capability. That’s one.
The second one is that I was one of the founders of our SDN strategy in the campus and branch environment, and what drove me to look at SDN was that the complexity of networks was making it harder for customers to take advantage of the functionality and capabilities in network hardware. So, I’ll go back to my car analogy. If you have an underpowered engine, it’s only going to go so fast. Really what I see with ACI is the fact that it’s allowing customers to take advantage of the capabilities in underlying infrastructure, and because customers can now take advantage of the underlying infrastructure it will become, in many ways, increasingly important in segments of our solution.
Another example I’ll give is when you talk about protocols evolving, it’s still early days but we released a network ASIC a couple of years ago that has a flexible parser and flexible data pipeline. The bottom line is that ASIC can support protocols that didn’t even exist when we shipped it. That’s such a terrific toolset to have with SDN and ACI because if a customer deploys one of those boxes and a great new protocol comes along a year from now, they can support it without having to go buy a new piece of hardware. So there’s a lot of opportunity for ACI to continue to drive the relevance of capabilities on the network infrastructure itself. Almost every new product or development activity we’re working on ties into ACI and how we enable it via the controllers. That’s part and parcel to how you’ll see Cisco build its products over the next few years.
Cisco Systems, Inc.
