Lippis Report 173: Software Defined Networking The OpenFlow Way, Grabs Industry Attention
In Lippis Report 172, I mentioned three huge trends that are starting to interact with each other creating a perfect storm that is gripping the tech industry. One of those trends is the creation of a software ecosystem in the networking market, thanks to the Clean Slate program out of Stanford University that has spawned the Software Defined Network (SDN) initiative and open controller protocol called OpenFlow. I spent a week in the Valley talking to people at Stanford and many industry executives from Cisco, Juniper, Marvell, Big Switch, Nicira, Arista, IBM and others. In this Lippis Report Research Note, I share with you what I learned. OpenFlow-based SDN is being both hyped and in its current state, limited, but it does represent a new paradigm that has the industry abuzz, filled with possibilities.
Optimizing Mobility for the Enterprise
Centralized Controller Model
OpenFlow is a protocol, or API, that modifies forwarding tables in network switches. It sits between a switch and controller. The controller can run on a centralized computer/server that has an Über view of the network and its topology. When a packet enters a switch and the forwarding table does not contain a path for the packet, it’s passed to the controller. The controller then searches the packet’s destination address and defines a table entry with associated attributes to create a path through the network, which the packet and subsequent packets are to follow. The controller then sends a message to each switch in the path the packet will traverse via the switch’s OpenFlow API, which modifies the switch’s forwarding table. Every subsequent packet with the same destination address will then be forwarded based upon this table in cut-through mode. The first store-and-forward stage takes about 50ms; yes, a long time, but it can be significantly shortened. Subsequent packets being forwarded in cut-through mode travel at switch latency, which for 10GbE Top-of-Rack (ToR) switches is between 500ns and a few microseconds.
Now this search method is a bit controversial as some claim that all that the controller needs is a large TCAM to compute the table flow. Some worry that a Cartesian explosion may occur, corrupting the calculation, but this is an engineering problem with an engineering solution, perhaps via multi-staging the flow tables.
The Evolution of Controller-Based Wireless LANs By Cisco Systems
This centralized controller model can scale as has been proven in distributed computing models used by all the major cloud providers. An example at Stanford demonstrated that a network of 35,000 PCs with approximately 2,000 switches generated 15 to 20k flows/sec. A controller can support 2M flows/sec at half a 2007 PC processor capacity. Further, modern 48-port ToR switches can request 100s of flows/sec with controllers supporting 2M flows/sec, which means that a single controller can support 10s of thousands of ToR switches. In short, a centralized controller-based OpenFlow SDN can theoretically scale.
How an OpenFlow SDN Is Different Than Today’s Network Architecture
The above model departs significantly from today’s network architecture in a few key ways. First there is the concept of a centralized controller(s) versus a distributed packet forwarding architecture based upon topology discovery. There may be separate links for control and data plane communications, which would also be a significant departure from today’s single physical network that supports both control information and data forwarding. There is no layer 2 and 3 construct in an OpenFlow SDN, which has been the semantics of computer networking over the past twenty plus years.
A Low-Latency Solution for High- Frequency Trading from IBM and Mellanox
Software Defined Network Ecosystem
Further, on top of the controller is another API, yet to be fully defined, that enables application developers to write network applications without knowledge of the underlying network structure. In short, the API abstracts the network, allowing the programmer to focus on what she/he needs to accomplish versus how to configure the network to comply. The creation of a software ecosystem creates the possibility of a new network paradigm where low cost Asian switches populated with SDN software force an economic collapse of the existing network market. While this is highly unlikely, it does warrant careful observation and mitigation planning on the part of established vendors.
An OpenFlow SDN offers significant differences, which is why there is such excitement surrounding OpenFlow. The genius of the approach is the separation of data and control plain so that SOA-based application developers and researchers can layer applications onto the network, injecting innovation at speed via a software ecosystem. Further centralized controller-based networks such as the national cellular network plus dense compute management have proven to reduce operational cost and increase control in complex systems.
TRILL in the Data Center: Look Before You Leap Understanding Fundamental Issues with TRILL
There is an industry group called the Open Network Foundation, or ONF, that is promoting the use and interoperability of OpenFlow SDN enabled switches. The above OpenFlow SDN example is primarily an academic description as OpenFlow is well regarded as the leading open implementation to date for providing SDNs within the research community. But there will be many networking concerns introducing controllers that reside in the switch. Further, the definition of a controller is a bit vague as some define it as a network operating system, such as Cisco’s IOS or NX-OS, Juniper’s JUNOs, Arista’s EOS, etc., while others define it as a management entity, performing configuration changes. But before we dive into this, let me explain a few problems that an OpenFlow SDN may solve.
Innovation at Speed: The institutions that were created to assure interoperability and inject innovation into our industry have become too cumbersome and slow such that networking has fallen behind compute and storage advances. The way innovation is injected into networking today is that a proposal is made to a standards group, such as the IETF, IEEE, etc., and all interested parties compete for the best ideas or technical advantage. This process can take a few years just to modify a few bits in the header of a packet. Then, once the standard is completed, companies build to it, which can take another eighteen to twenty-four months. This approach is not serving the industry any longer, and there needs to a more rapid way to inject innovation. An OpenFlow SDN promises such an approach where applications can be added to the network rapidly, thanks to the abstraction of layer 2 and 3 forwarding.
Real-World IP Telephony: A Look at What Midsize and Large Companies Really Spend
Traffic Engineering: Fine-grained traffic engineering utilizing a variety of forwarding actions is an application that service providers and enterprises seek to optimize application performance.
Tagging vs. Table Manipulation: There is much agreement in the industry that the network has become too ridged in virtualized data centers, restricting the movement of VMs between racks, data centers, etc. Further, as appliances such as firewalls, load balancers, IPS, etc., have become virtualized, there needs to be a method to steer traffic to them to service an application. The industry has responded to this by proposing the placing of tags on packets to guide its path to the right VM, appliance. An OpenFlow SDN implementation could simply modify switch-forwarding tables to guide the application through a chain of appliances mitigating tagging and offering applications appliance servicing within highly virtualized infrastructures.
EVALUATING AVAYA & MICROSOFT UNIFIED COMMUNICATIONS OFFERINGS
The Real World
An OpenFlow SDN is new, and it’s unrealistic to think that it’s without challenges; here are some OpenFlow challenges.
Trust: The single largest issue an OpenFlow SDN has is trust. Will IT business leaders trust it within their networks, especially their data center? If a controller is sourced from a new company, how comfortable will the IT team be that it’s modifying switch-forwarding tables? How many controllers are needed for a particular load? What will the support model be? How complicated will it be to manage multiple controllers?
Interoperability: The current construct of OpenFlow requires knowledge of the switch’s hardware semantics of L2/L3/VLAN architecture; therefore, each controller implementation may be different and thus unclear how controller interoperability is achieved. Further, it’s unclear how applications written for one controller will work on another.
Arista Networks 7124SX and 7050S-64 Data Center Switch Test Results
Network Stability: This issue may be linked with trust, but it’s unclear why a third-party controller should search packets to define a path through the network topology. Rather, why not use existing network operating systems for what they are good at– topology discovery, etc.–so that IT business leaders are more comfortable running OpenFlow-based SDN applications on top of a stable network. In short, will OpenFlow controllers introduce instability?
Controller Placement: If we take the definition of a controller to include existing network operating systems, then there will be both distributed and centralized controllers within a network. From a design point of view, how does an IT architect approach distributed versus centralized controllers and what are the trade-offs?
It’s unfair to expect that a new approach to networking would have the above issues all sorted out before deployment. These are not barriers to entry but rather challenges that the OpenFlow SDN community will work on over the next one to two business cycles. Let me be clear…OpenFlow-based SDN is a very big deal and is being embraced by all vendors including established firms and start-ups. What is driving most companies is the promise of a software ecosystem to inject innovation and value into their network products.
Established firms will support OpenFlow SDN via OpenFlow client reference implementation within their switches but will add proprietary extensions that differentiate their OpenFlow version from others. Cisco, Juniper, Arista, et al, will differentiate based upon how much of their network operating system they expose. Established firms should have an advantage over smaller ones in attracting software developers as their installed base is much larger.
New companies such as Big Switch Networks and Nicira will focus on solving particular problems in the data center, service provider and enterprise network that existing layer 2/3 networks either don’t solve or don’t solve easily. Virtualization of both servers and desktop are two prime areas, and I expect a suite of SDN Virtualized Applications to emerge from these firms and others.
The service provider market is perhaps the biggest OpenFlow SDN winner as early experiments have shown that the existing three-tier service provider architecture of packet switching, optical core and edge may shrink over time to just two, thanks to traffic management applications.
OpenFlow SDN has successfully introduced the concept of controller-based networking and the controller market. OpenFlow 1.1 is in standardization process and once completed, will be the first defined open controller API to communicate between network and controller, offering greater control of cloud network resources and management. But perhaps the greatest contribution an OpenFlow SDN will offer is the potential to usher in a wave of fast-paced innovation not seen before in the networking industry.