 separation between data plane and control plane implementations is simplified when one or both of them are implemented in software running on top of standard hardware. The term SDN has come to mean different things based on one's perspective as illustrated in Figure 3.5. The term SDN was coined in 2009 based on work being done in academia. The focus was on separating the control plane from the forwarding plane for Ethernet switches to centralize forward- ing decisions in a controller. The goal was to allow for more agility and flexibility on forwarding rules, while actually simplifying the forwarding devices without the need for complicated distrib- uted routing protocols. OpenFlow (Foundation) emerged as a new protocol to support the commu- nication between a central controller and forwarding devices. The first production use case for these concepts was large data centers. Sophisticated orchestra- tion emerged to support the deployment and mobility of VMs, primarily supporting IT applications. The data center network, however, lacked the agility to support this environment. If one moved a workload from one server to another, the network VLANs/IP addressing had to be manually Data Center SSDN Centralized Controller SDN OpenAPIs SDN "Abstracted" Control Plane SDN Automated Configuration SDN OpenFlow SDN Centralized Controller SDN Layer 2 Overlays Academia HW Vendor SDN NFV/COTS SDN OpenAPIs SDN Separate of Hardware/Software/Control SDN Automated Configuration SDN Multi-Layered Abstraction/Control "Abstracted" Control Plane SDN Automated Configuration Tight Integration between Hardware/ SDN OpenAPIs, Northbound and Southbound Software/Control Carrier FIGURE 3.5 SDN views. Building the Network of the Future configured to support the workload in its new locations. This typically meant reconfiguring all the switches in the path. To overcome this on an existing network, new overlay technologies emerged to support virtual networks over the top of the existing network fabric. These technologies have included LISP (Cisco