Network data plane technology has improved dramatically over the years with linespeeds, port densities and performance/price all increasing rapidly. However, network control plane mechanisms have advanced at a much slower pace. For example, it takes several years to fully design, and even longer to widely deploy, new routing algorithms, such as Transparent Interconnection of Lots of Links (TRILL) (as described in the Internet Engineering Task Force's Request for Comments 5556 entitled “Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement” dated May 2009 by Touch, J., and Perlman, R.). In recent years, as new intradomain requirements have arisen (e.g., greater scale, increased security, migration of VMs), the inadequacies of our current network control mechanisms have become especially problematic. In response, there is a growing movement, driven by both industry and academia, towards a new network control paradigm called Software-Defined Networking (SDN).
In the SDN paradigm, a network-wide control platform, running on one or more servers in the network, oversees a set of simple switches. The control platform handles state distribution (i.e., collecting information from the switches, distributing the appropriate control state to them, and coordinating the state among the various platform servers) and provides a programmatic interface upon which a wide variety of management applications can be built. For clarification, the term “management application” refers to the control logic needed to implement management features such as routing and access control.
A new network management feature often requires its own distributed protocol, which involves first solving a hard, low-level design problem and then later overcoming the difficulty of deploying this design on switches. With the SDN paradigm, control logic can be written on top of the control platform's higher-level API in order to implement new control functionalities, allowing the control platform to take care of the detail implementation of the distribution mechanism.
In essence, the SDN provides that basic primitives for state distribution should be implemented once in the control platform rather than separately for individual control tasks, and should use well-known and general-purpose techniques from the distributed systems literature rather than the more specialized algorithms found in routing protocols and other network control mechanisms. The SDN paradigm allows network operators to use a single control platform to implement a range of management functions (e.g., routing, traffic engineering, access control, VM migration) over a spectrum of control granularities (from individual flows to large traffic aggregates) in a variety of contexts (e.g., enterprises, datacenters, WANs).
Because the control platform simplifies the duties of both switches (which are controlled by the platform) and the control logic (which is implemented on top of the platform) while allowing great generality of function, the control platform is the crucial enabler of the SDN paradigm. The most important challenges in building a production-quality control platform are generality, scalability, reliability, simplicity, and control-plane performance. First, the control platform's API must allow management applications to deliver a wide range of functionality in a variety of contexts. Second, because network sizes (particularly in the datacenter) are growing rapidly, any scaling limitations should be due to the inherent problems of state management, not the implementation of the control platform. Third, the control platform must handle equipment (and other) failures gracefully. Fourth, the control platform should also simplify the task of building management applications. Fifth, the control platform should not introduce significant additional control plane latencies or otherwise impede management applications (note that data path latencies are unaffected by SDN). However, the requirement here is for adequate control-plane performance, not optimal performance. Therefore, when faced with a tradeoff between generality and control-plane performance, one tries to optimize the former while satisfying the latter.
Despite the high-level interest in SDN, no existing products have been able to satisfy all of these requirements.
In the past, some have proposed an approach toward shielding protocol design from low-level details. Examples of such approach include the 4D project (as described in pages 41-54 of Special Interest Group on Data Communication's (SIGCOMM) Computer Communication Review (CCR) 35, 5 (2005) entitled “A Clean Slate 4D Approach to Network Control and Management” by Greenberg, A., Hjalmtysson, G., Maltz, D. A., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan, J., and Zhang, H.), Routing Control Platform (RCP) (as described in the proceedings of the April 2005 Network System Design and Implementation Symposium entitled “Design and Implementation of a Routing Control Platform” by Caesar, M., Caldwell, D., Feamster, N., Rexford, J., Shaikh, A., and Van Der Merwe, K.), Secure Architecture for the Networked Enterprise (SANE) (as described in the proceedings of the August 2006 Usenix Security Symposium entitled “SANE: A Protection Architecture for Enterprise Networks” by Casado, M., Garfinkel, T., Akella, A., Freedman, M. J., Boneh, D., McKeown, N., and Shenker, S.), Ethane (as described in the proceedings of the August 2007 SIGCOMM conference entitled “Ethane: Taking Control of the Enterprise” by Casado, M., Freedman, M. J., Pettit, J., Luo, J., McKeown, N., and Shenker, S.), Network Operating Systems (NOX) (as described in U.S. Published Patent Publication 2009/0138577), and others. However, none of these examples, except for NOX, could be considered a control platform offering a general-purpose API.
USPTO Backgrounds
USPTO Backgrounds