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?
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.