is a significant advantage for the next-generation access networks to design the architecture on the premises of separation of the control-plane and user-plane functions. This separation would imply allocation of specific control-plane and user-plane functions between different nodes. As we stated earlier, the goal of SDN is to enable cloud and net- work engineers and administrators to respond quickly to changing business requirements via a centralized control platform. SDN encompasses multiple types of network technolo- gies designed to make the networks more flexible and agile to support the virtualized server and storage infrastructure of the modern data centers. The SDN was originally defined as an approach to designing, building, and managing networks that separates the network's control and forwarding planes, enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and net- work services. All SDN models have some version of an SDN controller, as well as south-bound APIs and north-bound APIs. As shown in Fig. 1.9, an SDN controller is interfaced with the application layer and the infrastructure layer via north-bound and south-bound APIs, respectively. As the intelligence of the network, SDN controllers pro- vide a centralized view of the overall network and enable network administrators to instruct the underlying systems (e.g., switches and routers) on how the forwarding plane should route/handle network traffic. SDN uses south-bound APIs to relay information to the switches and routers. OpenFlow, considered the first standard in SDN, was the original south-bound API and remains as one of the most commonly used protocols. Despite some belief considering OpenFlow and SDN to be the same, OpenFlow is merely one piece of the larger SDN framework. SDN uses north-bound APIs to communicate with the 30 Chapter 1 Application plane North-bound interface (NBI) RESTful, JSON Control plane SDN controller/network operating system SDN controllers (Open