Design Article
Controlling network flow with the OpenFlow protocol
Daniel Proch, Netronome
1/30/2012 1:51 PM EST
A new twist on network flow processing gives network administrators programmatic control of network flows to strategically place traffic where resources exist. Here’s why you may be building the open-source specification OpenFlow (or similar protocol) into routers, switches, and other devices to realize the benefits of Software-Defined Networks.
The idea of Software-Defined Networking--and OpenFlow specifically--has garnered significant interest, curiosity, as well as skepticism recently among developers of network switches, routers, and servers, and the companies that build them.
Software-Defined Networking (SDN) is a concept that emerged out the research community and a specific implementation is being driven by the Open Networking Foundation (www.opennetworking.org). SDN is a networking architecture designed to create higher-level abstractions on top of which can be built the hardware/software infrastructure needed to support the many new cloud-computing applications.
An example of SDN is described in the OpenFlow specification, a new networking protocol that emerged out of the university research environment. OpenFlow provides access to the forwarding plane of a network switch or router over the network and allows software running on a separate server to determine what path the network packets will take through the network of switches.
Some factions in the industry believe OpenFlow is the next big thing in computer networking and that it will revolutionize the way data centers and carrier networks are built and maintained in the new era of cloud computing. They believe that SDN is the final and missing link between the virtualized network infrastructure and virtualized computing resources and that it will make cloud computing and massive data centers more efficient and less costly to operate. Others purport that OpenFlow is just the newest fad and will fade away while existing networking technologies and methods continue to be prevalent.
Will OpenFlow live up to the excitement or is it another flash in the pan?
Background
Virtualized network infrastructure has been around for years. Notable technologies, like Ethernet VLANs, IPsec and SSL virtual private networks (VPNs), and Layer 3 VPNs via MPLS or virtual routing, are all examples of tried-and-true technologies for virtualizing networks. These techniques allow a single set of physical resources to be shared among a diverse group of users, providing isolation, performance guarantees, and security. Each of these benefits can also apply to virtualized application hosting platforms. Mechanisms to virtualize servers are now commonplace, and server virtualization is being heralded as the key to the convergence of networking and computing in the data center.
These virtualized networks are still fundamentally based on the combination of Ethernet at the data plane and TCP/IP for higher-layer addressing and application processing. Other data-plane technologies like Token Ring, FDDI, and ATM, while still in existence in legacy mode, are certainly dwindling rapidly in number of ports in existence. In addition, the days of other non-IP Layer 3 networking protocols like Novell's IPX and Apple's Appletalk have come and gone. These technologies are no longer used and are largely forgotten.
Management and control of these virtualized Ethernet/IP networks has remained largely unchanged for many years. These networks are operated with a completely distributed control plane where, in most cases, each device is running one or more instances of a Layer 2 and Layer 3 control plane. In the case of bridged Ethernet networks, each Ethernet switch contains a forwarding table that maps MAC (Media Access Control) addresses to physical or virtual interfaces.
These MAC addresses are learned, based on determining address locations in the network, in turn based on traffic flow and caching that information in a Layer 2 forwarding table. Control protocols such as Spanning Tree (STP) and derivatives including Rapid Spanning Tree (RSTP) and Multiple Spanning Tree (MSTP) are tried and tested protocols to ensure a loop-free topology for this switched infrastructure.
For routed networks, there exists an entire set of protocols that determine the optimal path that data should follow in order to travel across multiple networks from source to destination. These include options like Routing Information Protocol (RIP), Open Shortest Path First (OSPF), and the Border Gateway Protocol (BGP), among other examples.
In most cases, a combination of these switched and routed approaches exists simultaneously to control the forwarding behavior of traffic through a network. Regardless of the protocol specifics, usually traffic is forwarded solely on the basis of its ultimate destination, with each intermediate switch or router looking at the destination MAC address and/or destination IP address in the Ethernet and IP headers. All packets destined to the same device are relegated to use the same path through the infrastructure.
Although these methods have fueled the incredible growth in the size and scope of computing networks, they also have inefficiencies that carriers and enterprise networks would like to control.
By virtue of being solely based on destination forwarding, all traffic to a particular host or server ultimately traverses the same network path. This does not provide network architects the amount of control they require over how flows move through their networks. Additionally, considering the explosive use of virtualized servers, network configurations must provide the capability to be changed instantaneously in response to changes in the server topology.
Traditional switching and routing protocols take seconds if not minutes to reconverge, which is orders of magnitudes longer than can be tolerated. Today's networks need to be smarter, faster, and more flexible. What carriers and data-center network designers want is the ultimate control of how flows are routed through the network as well as the treatment that those flows receive, while not being held hostage to how IP routing protocols or spanning tree decides how traffic moves through the network.
The idea of Software-Defined Networking--and OpenFlow specifically--has garnered significant interest, curiosity, as well as skepticism recently among developers of network switches, routers, and servers, and the companies that build them.
Software-Defined Networking (SDN) is a concept that emerged out the research community and a specific implementation is being driven by the Open Networking Foundation (www.opennetworking.org). SDN is a networking architecture designed to create higher-level abstractions on top of which can be built the hardware/software infrastructure needed to support the many new cloud-computing applications.
An example of SDN is described in the OpenFlow specification, a new networking protocol that emerged out of the university research environment. OpenFlow provides access to the forwarding plane of a network switch or router over the network and allows software running on a separate server to determine what path the network packets will take through the network of switches.
Some factions in the industry believe OpenFlow is the next big thing in computer networking and that it will revolutionize the way data centers and carrier networks are built and maintained in the new era of cloud computing. They believe that SDN is the final and missing link between the virtualized network infrastructure and virtualized computing resources and that it will make cloud computing and massive data centers more efficient and less costly to operate. Others purport that OpenFlow is just the newest fad and will fade away while existing networking technologies and methods continue to be prevalent.
Will OpenFlow live up to the excitement or is it another flash in the pan?
Background
Virtualized network infrastructure has been around for years. Notable technologies, like Ethernet VLANs, IPsec and SSL virtual private networks (VPNs), and Layer 3 VPNs via MPLS or virtual routing, are all examples of tried-and-true technologies for virtualizing networks. These techniques allow a single set of physical resources to be shared among a diverse group of users, providing isolation, performance guarantees, and security. Each of these benefits can also apply to virtualized application hosting platforms. Mechanisms to virtualize servers are now commonplace, and server virtualization is being heralded as the key to the convergence of networking and computing in the data center.
These virtualized networks are still fundamentally based on the combination of Ethernet at the data plane and TCP/IP for higher-layer addressing and application processing. Other data-plane technologies like Token Ring, FDDI, and ATM, while still in existence in legacy mode, are certainly dwindling rapidly in number of ports in existence. In addition, the days of other non-IP Layer 3 networking protocols like Novell's IPX and Apple's Appletalk have come and gone. These technologies are no longer used and are largely forgotten.
Management and control of these virtualized Ethernet/IP networks has remained largely unchanged for many years. These networks are operated with a completely distributed control plane where, in most cases, each device is running one or more instances of a Layer 2 and Layer 3 control plane. In the case of bridged Ethernet networks, each Ethernet switch contains a forwarding table that maps MAC (Media Access Control) addresses to physical or virtual interfaces.
These MAC addresses are learned, based on determining address locations in the network, in turn based on traffic flow and caching that information in a Layer 2 forwarding table. Control protocols such as Spanning Tree (STP) and derivatives including Rapid Spanning Tree (RSTP) and Multiple Spanning Tree (MSTP) are tried and tested protocols to ensure a loop-free topology for this switched infrastructure.
For routed networks, there exists an entire set of protocols that determine the optimal path that data should follow in order to travel across multiple networks from source to destination. These include options like Routing Information Protocol (RIP), Open Shortest Path First (OSPF), and the Border Gateway Protocol (BGP), among other examples.
In most cases, a combination of these switched and routed approaches exists simultaneously to control the forwarding behavior of traffic through a network. Regardless of the protocol specifics, usually traffic is forwarded solely on the basis of its ultimate destination, with each intermediate switch or router looking at the destination MAC address and/or destination IP address in the Ethernet and IP headers. All packets destined to the same device are relegated to use the same path through the infrastructure.
Although these methods have fueled the incredible growth in the size and scope of computing networks, they also have inefficiencies that carriers and enterprise networks would like to control.
By virtue of being solely based on destination forwarding, all traffic to a particular host or server ultimately traverses the same network path. This does not provide network architects the amount of control they require over how flows move through their networks. Additionally, considering the explosive use of virtualized servers, network configurations must provide the capability to be changed instantaneously in response to changes in the server topology.
Traditional switching and routing protocols take seconds if not minutes to reconverge, which is orders of magnitudes longer than can be tolerated. Today's networks need to be smarter, faster, and more flexible. What carriers and data-center network designers want is the ultimate control of how flows are routed through the network as well as the treatment that those flows receive, while not being held hostage to how IP routing protocols or spanning tree decides how traffic moves through the network.
|
|
|
|
|
Navigate to related information
Luis Sanchez
1/31/2012 5:26 PM EST
This is a very good article talking about the academic opportunities for learning and developing new approaches for network flow algorithms.
Considering the universities that are involved with this it means this is a good bet to be involved with.
Sign in to Reply
Netteligent
2/2/2012 5:24 PM EST
OpenFlow and Software Defined Networking exhibit tremendous promise. I hope the open source consortium make it easier and transparent for small companies and individual like us to get involve, participate, and contribute to its future success.
Sign in to Reply
28B943FE-0332-4511-8656-1B1E90B0F22A
2/6/2012 1:54 PM EST
While I cant comment on the consortium itself, the whole promise of SDN is to open up the network to new uses and applications. Networking equipment is vertically integrated at the control and data planes. Conversely,
open, multi-layer hardware and software stacks encourage innovation and rapidly can drive down costs
Servers are a perfect example of how an open ecosystem lowers costs and drives innovation. SDN can bring about the change that will allow the small and large to have equal opportunity in the networking space.
Sign in to Reply
LarryM99
2/7/2012 1:11 PM EST
Many of the possibilities for network control described for OpenFlow and even for existing technologies open up questions about the motives behind that control. Cable providers and other ISPs are increasingly getting into providing content, and it is very easy to see them tilting the table towards their content and against competitors (i.e. Netflix). It is also questionable that centralized control over all flows works better than a robust distributed control system. Even if you argue that centralized control is necessary to tame rogue data (i.e. P2P) there is still dependence on per-packet inspection. Most of these marking schemes can be spoofed relatively easily. Bottom line, there is still a lot of work to be done in this area.
Larry M.
Sign in to Reply
Bogdan Golab
2/13/2012 6:42 AM EST
I am not sure if vendors like Cisco, Juniper, etc are really interested in OpenFlow implementation. Notice, their routers & switches would perform very simple tasks - no sophisticated routing/switching any more. Only simple "match-action" aproach. The "intelligence" is moved to the external manager. New features would be implemented externally to router/switches. So their devices would easelly replaced by any vendor boxes supporting OpenFlow.
Sign in to Reply