s. The CC is a typical cloud controller (e.g., OpenStack) augmented with support for flow networks (i.e., flow network extensions added to the neutron). The moderator translates the list of services and their connectivity into information about VMs, vSwitches, and links that the CC can understand. The CC receives the customer's net- work architecture and policy specifications, akin to a fine-grained SLA. It translates the SLA into a list of requirements in terms of dedicated VMs, storage, different types of network appliances and business applications, and dedicated links between those. Next, it maps a constructed virtual topology onto the network abstraction provided by the SC (SDN controller). Based on SC feedback, the CC proceeds to create and configure the customer infrastructure (i.e., instantiate VMs, virtual switches). The CC informs the SC of the placement of specific network entities, such as virtual switches. The SDN controller (SC) is responsible for managing and pro- visioning the enterprise network topology, by mapping network requirements to the selected set of physical and virtual network resources (including customer's CPE). Such configuration is done using a combination of different southbound plug-ins, such as OpenFlow, OVSDB, or NetConf. The SC is an SDN controller with a developed application for vCPE service chaining. Some of the extensions require changes to the external interfaces of the SDN controller. The main extensions for vCPE include service chaining, connectivity monitoring, location optimization, and network con- figuration. Service chaining provided the APIs for orchestrator to create service chaining rules per enterprise. Location optimization and connectivity monitoring provide APIs to detect network congestion and connectivity failures. This information is necessary to enforce network SLAs. Network configuration provides the orchestrator the possibility to engineer service chaining networks 5 SDN and NFV in 5G in many different ways. The SC will also inform the CC of optimal loc