tworking problems, it is worth identification that it is just a tool for solving network-management problems more easily. SDN simply gives developers the power to create new applications and find solutions to ancient problems. In this respect, the work is just beginning. If the past is any suggestion, the development of these new technologies will require novelty on multiple timescales, from long-term bold visions (such as active networking) to near-term innovative problem solving (such as the operationally focused work on separating the control and data planes). Second, the balance between visualization and practicality remains tenuous. The bold vision of SDN advocates a variety of control applications; yet OpenFlow's control over the data plane is confined to ancient match-action operations on packet-header fields. The initial design of OpenFlow was driven by the aspiration for rapid adoption, not first principles. Supporting a wide range of network services would require much more complicated ways of analyzing and manipulating traffic (e.g., deep-packet inspection, as well as compression, encryption, and transcoding of packets), using product servers (e.g., x86 machines) or programmable hardware (e.g., FPGAs, network processors, and GPUs), or both. Fascinatingly, the renewed interest in more complicated data-plane functionality, such as NFV, harkens back to the earlier work on active networking, bringing the story full circle. Maintaining SDN's bold vision requires more thinking outside the box about the best ways to program the network without being controlled by the restrictions of current technologies. Rather than simply designing SDN applications with the current OpenFlow protocols in mind, developers should think about what variety of control they want to have over the data plane, and balance that vision with a practical strategy for deployment. REFERENCES Advantages of Software Defined Networking. (2014). Retrieved from http://www. ingrammicroadvisor.com/data-center/7-advantages-of-software-defined-netwo