The most common question I get from those I brief about OpenStack's new network service is "How does Quantum relate to software defined networking?"
Especially confusing to many is the difference between these kinds of cloud networking services and the increasingly discussed OpenFlow open-networking protocol.
In part 1 of this series, I described what is becoming an increasingly ubiquitous model for cloud computing networks, namely the use of simple abstractions delivered by network systems of varying sophistication. In part 2, I then described OpenStack's Quantum network service stack and how it reflected that model.
Software defined networking (SDN) is an increasingly popular--but extremely nascent--model for network control, based on the idea that network traffic flow can be made programmable at scale, thus enabling new dynamic models for traffic management. Because it can create "virtual" networks in the form of custom traffic flows, it can be confusing to see how SDN and cloud network abstractions like Quantum's are related.
To help clarify the difference, I'd like to use one particular example of "software defined networking," which was discussed in depth this week at the PacketPushers/TechFieldDay OpenFlow Symposium. Initially developed for computer science research (and--rumor has it--national intelligence networks), OpenFlow is an "open" protocol to control the traffic flows of multiple switches from a centralized controller.
The whitepaper (PDF) on OpenFlow's Web site provides the following description of the protocol:
"OpenFlow provides an open protocol to program the flow-table in different switches and routers. A network administrator can partition traffic into production and research flows. Researchers can control their own flows--by choosing the routes their packets follow and the processing they receive. In this way, researchers can try new routing protocols, security models, addressing schemes, and even alternatives to IP. On the same network, the production traffic is isolated and processed in the same way as today."
(Credit: OpenFlow.org)
That last sentence is interesting. If a switch (or router) supports OpenFlow, it doesn't mean that every packet sent through the device has to be processed through the protocol. Standard "built-in" algorithms can be used for the majority of traffic, and specific destination addresses (or other packet characteristics) can be used to determine the subset that should be handled via OpenFlow.
What can OpenFlow be used for? Well, Ethan Banks of the Packet Pushers blog has a great post outlining the "state of the union" for OpenFlow. Today, it is very much a research project, but commercial networking companies (including both established vendors and startups) are interested in the possibility that it will allow innovation where innovation wasn't possible before.
But finding the "killer apps" for OpenFlow is proving elusive at this early, early stage. Chris Hoff, security architect at Juniper, thinks it is information security. However, the quote of the day may have come from Peter Christy, co-founder of the Internet Research Group, in this article:
"I completely embrace the disruptive potential but I'm still puzzled on how it will impact the enterprise. The enterprise is the biggest part of the networking market. Building a reliable SDN controller is a challenging task. Customers don't value reproducing the same thing with a new technology. There have been few OF/SDN 'killer' apps so far. SDN is not ready for the enterprise market yet."
That said, how does OpenFlow relate to Quantum? It's simple, really. Quantum is an application-level abstraction of networking that relies on plug-in implementations to map the abstraction(s) to reality. OpenFlow-based networking systems are one possible mechanism to be used by a plug-in to deliver a Quantum abstraction.
OpenFlow itself does not provide a network abstraction; that takes software that implements the protocol. Quantum itself does not talk to switches directly; that takes additional software (in the form of a plug-in). Those software components may be one and the same, or a Quantum plug-in might talk to an OpenFlow-based controller software via an API (like the Open vSwitch API).
I know this gets a little complicated if you don't understand networking concepts very well, but the point is that you shouldn't ever need to deal with this stuff, unless you are a network engineer. Quantum hides the complexity of the network from the application developer's perspective. The same is true of Amazon's VPC, as well various emerging products from networking companies.
However, powerful new ways of viewing network management are being introduced to allow for an explosion of innovation in how those "simple" network representations are delivered. In the end, that will create a truly game-changing marketplace for cloud services in the years to come.
That, when all is said and done, may be the network's role in cloud computing.
No comments:
Post a Comment