Annals of Telecommunications

, Volume 73, Issue 3–4, pp 169–192 | Cite as

A survey on the communication and network enablers for cloud-based services: state of the art, challenges, and opportunities

  • George Patrick Xavier
  • Burak Kantarci


The wide adoption of the cloud computing concept has resulted in major impacts in both fixed and mobile communication networks leading to cutting-edge research to provide appropriate network architecture and protocols, along with resource management mechanisms. Cloud computing research has been witnessing the interplay between the system and communication aspects in order to offer powerful inter-networking and interoperability between the systems and networks. This paper reviews recent works focusing on architectural design issues, virtualization solutions, and challenges in cloud communications and networking. We mainly discuss the architectural challenges and solutions in today’s leading cloud communication technologies starting with network virtualization, software-defined networking (SDN), network function virtualization (NFV), and SDN-enabled NFV solutions. Furthermore, considering the benefits of cloud computing for mobile communications, we overview the cloud-RAN architecture for radio access networks, along with its support for various existing and future wireless communication technologies including future 5G wireless networks. We study each cloud communication technology by focusing on the existing works from the standpoint of objectives, challenges, and solutions. Furthermore, for all cloud communication concepts, we present a thorough discussion on the open issues and opportunities.


Cloud communications Cloud networking Network virtualization Software-defined networking Network function virtualization Cloud radio access networks 5G 

1 Introduction

During the last decade, significant improvements have occurred in the area of cloud computing. Cloud computing is a type of hosted service that uses the Internet to offer the information technology service to customers. The major benefits of the cloud-based technology solutions include scalability, resilience, flexibility, efficiency, and outsourcing of non-core activities while ensuring security and robustness of cloud services remains as challenges [114]. Cloud networking has appeared as a cloud-inspired solution to make network resources available to the organizations over the Internet so that the organizations can reduce recurring and non-recurring costs to maintain a network infrastructure. Furthermore, by opting-in a cloud networking solution, scaling out/down elastically becomes possible whenever required [98].

Cloud computing has introduced a major impact to both fixed and mobile communication networks, and led to several challenges and requirements to provide standardized network architecture and protocols [20]. We categorize the issues in cloud networking under three themes, namely architectural design issues, network virtualization issues, and issues related to software defined networking.

Cloud architectural issues come under the category of infrastructure as a service (IaaS), which raises the problem of designing basic cloud infrastructures along with security issues related to guarantee system robustness, resilience, privacy/data protection, and availability issues. Indeed, the main challenge in the architectural design is to ensure that services remain uninterrupted and without degradation in the service quality [47].

Network virtualization basically denotes decoupling of the roles of the traditional Internet service provider (ISPs) into the following independent entities: (1) infrastructure providers (InPs) that are responsible for the management of the physical infrastructure. (2) Service providers (SP) that aggregate resources from multiple infrastructure providers and create virtual networks to offer end-to-end services [61]. For wide adoption of network function virtualization, standard interfaces between SPs and InPs along with signaling and bootstrapping have to be implemented. Furthermore, resource and topology discovery requires the InPs to have the full topological view of the network in terms of interconnection between the existing physical nodes and the capacities of these nodes and links whereas the SPs should be able to discover the presence and topology of other co-existing virtual networks enabling these virtual networks to collaborate and communicate with each other to provide a more complex service. In addition to these, network virtualization also bares challenges related to admission control and usage policy, mobility management, and security/privacy [31].

Software-defined networking (SDN) stands for the decoupling of the data plane and control plane for the sake of flexible programmability of the network through a centralized controller [117]. While SDN transforms the conventional networking paradigm, several challenges are faced in the implementation of SDN despite its effective and efficient use in cloud computing. Some of these challenges include controller placement, scalability, performance, security, interoperability, reliability, increasing demands, and implementation.

Prior to this study, several survey articles have tackled different aspects of cloud computing and communications. In [30], the authors present a survey on particularly SDN, discussing its architecture and recent developments along with the research challenges and issues that need to be addressed for future development of SDN. In [87], the authors mainly focus on the energy efficiency of the infrastructure by discussing the energy efficiency correlation between many ICT domains. Furthermore, existing research and development in these domains that support cloud computing are reviewed. In addition to these, in [66], the authors discuss various energy efficiency techniques to overcome the high energy consumption challenges. Furthermore, in the same study, software-based optimization techniques are presented to achieve minimum energy consumption. The study in [140] focuses on the decentralization of computing functionality out of the data centers and the need for a new architecture in the cloud infrastructure for data intensive computing and other requirements. In [142], a survey study focusing on stability, agility, latency, and multi-tenancy aspects of data center networks. Resource management in clouds has also been tackled in a survey study [62].

Apart from prior surveys, in this paper, we provide a thorough review of the state of the art for the communication and networking enablers that can help to expand the adoption of cloud services. While surveying these enablers, we particularly focus on the architectural design issues, network virtualization and software-defined-based solutions. Furthermore, we also present cloud radio access (C-RAN) solutions and their integration with the 5G networks. Based on the state of the art and requirements for all of these technologies, we identify open issues and challenges under each subject.

The rest of the paper is organized as follows. In Section 2, we present the design issues in cloud communications. Section 3 reviews the network virtualization concept and its connection to the cloud computing concept. Section 4 presents the SDN and NFV concepts separately, and moves into integrated SDN-NFV solutions along with the opportunities and challenges when the two concepts are combined. Section 5 approaches the problem from a wired/wireless integration standpoint by investigating the role of C-RAN in the 5G era from various perspectives. Finally, in Section 6, we provide a high level summary of the reviewed solutions, and give future directions.

2 Design issues in cloud networking

In this section, we present a brief review on cloud computing service architecture, along with the design issues and challenges. We particularly present cloud deployment models and the security issues faced by cloud architectures. Furthermore, we also present the communication modes in cloud networking in comparison with traditional communication modes. This is followed by a brief discussion on cloud networking challenges with inter-data center and intra-data center networks. We also present some of the practical aspects and issues faced in cloud networking.

2.1 Service architectures

A service provider in a cloud computing environment is a two-tier entity that consists of InPs and the SPs. The InPs are responsible for managing the cloud platforms, resource provisioning, and pay-per-use billing whereas the SPs rent the resources provided by one or more InPs. In its simplest form, the cloud architecture can be considered as a four-layer model with the following layers: hardware layer, infrastructure layer, platform layer, and application layer. Cloud services operate on these layers, and they can be grouped under the following three categories: IaaS, platform as a service (PaaS), and software as a service (SaaS) [56, 158].

In IaaS, the infrastructural resources such as virtual machines are provisioned on demand. PaaS offers a platform for the users to develop and run their own applications by accessing programming tools, libraries, services, and tools that are compatible and supported by the infrastructure of the SP. In SaaS, users are subscribed to applications running on the cloud. Access to SaaS applications requires thin client interfaces or a program interface.

Several platforms are available to evaluate design and planning models of cloud infrastructures and to overcome. CloudSim is a Java-based cloud simulator that enables simulation of a cloud system consisting of large data centers [23]. The necessary features of cloud computing model can be achieved by CloudSim. The simulator allows the developer to replicate the external and internal deployment of services. It allows modeling of the storage and provisioning of resources among virtual machines along with application services and brokerage. Recently, new functionalities to simulate containerized clouds have also been introduced to the CloudSim simulator [110]. The GreenCloud is mainly used as an energy aware and packet-level simulator for cloud computing infrastructures by introducing detailed energy consumption information [71]. GreenCloud is implemented over the NS2 network simulator by introducing infrastructural components such as servers, switches, links, and workload. The authors in [11] present a performance study on cloud computing simulators and identify the benefit of the GreenCloud simulator as the availability of application deadline specification to start and stop an application. Moreover, providing packet-level energy consumption information and the support for many power saving algorithms have been pointed out as further benefits of the GreenCloud simulator [11]. OpenStack is a widely recognized open source cloud platform that allows developers to deploy public and private IaaS cloud scenarios in a scalable and efficient manner. OpenStack is built on a three-node structure to deploy a cloud, namely the compute, controller, and network nodes [59].

2.2 Cloud deployment models

There are three deployment models in the cloud, namely private clouds, public clouds, and hybrid clouds. A private cloud is dedicated for the use of a single organization. The private cloud can be built or managed either by the organization in its corporate data center or by external providers in their cloud data centers. Private cloud services offer high availability, high reliability, security, and rapid control over performance.

Private clouds are ideal for organizations that have dynamic computing needs and work with highly sensitive information. The users have the ability to perform multi-tenancy, self-service, scalability, and on demand resource made available for computing [158]. Despite these benefits, high operational costs and—if the data center is to be on premise—high capital expenditures for equipment, application deployment, resources staffing, and security are the drawbacks of private cloud deployment. Thus, the benefit of no up-front cost and pay as you go service costs do not exactly exist in a private cloud deployment since a dedicated data center deployment will be required. Consequently, prolonged service outages are also likely to happen [56, 158].

In the public cloud deployment model, SPs own the infrastructure and provide their resources as service to multiple consumers. Public clouds offer reduced capital expenditures because of not requiring initial investment on the infrastructure, high scalability, and on demand availability of resources. On the other hand, public clouds lack fine grained control over data, security, and network settings [47].

Hybrid clouds offer a combination of the public cloud and the private cloud services with the aim of addressing the limitation of each approach by splitting the service infrastructure between private and public clouds. Hybrid clouds offer flexibility, controllability, and security over the application data in comparison to public clouds [56, 158].

2.3 Practical cloud networking aspects and issues

In this section, we present some of the practical issues seen in cloud networking, some of which still remain challenges to the providers.

2.3.1 Elastic load balancers and virtual private cloud

Elastic load balancer (ELB) is primarily used to balance the distribution of incoming traffic from the users over the active instances. Automatic distribution of incoming traffic helps to offer high availability. Furthermore, it also provides security as it works along with the virtual private cloud (VPC) to provide integrated certificate management and secure socket layer (SSL) decryption. Availability guarantee under ELB is provided by handling any failure or surge in the network traffic through autoscaling. For instance, AWS ELB runs continuous monitoring of the incoming traffic metrics and works in coordination with Amazon CloudWatch [1]. Despite the load balancing functionality introduced by ELB in the network, there exist several practical challenges. For instance, due to the unavailability of private IP, a conventional security group can not be created with an ELB. A proposed solution to cope with this challenge is to use an HAProxy software load balancer that has a private IP address and hence can be used with the security group [128].

2.3.2 Virtual IP addresses

Virtual IP address or VIP was initially proposed as a remedy to the loss of communication in the case of an adapter failure that leads to disruption in packet transmission. Load balancers are configured with virtual IP addresses, and arriving requests towards a VIP destination are routed to the appropriate domain in layer 2. The physical IP addresses are configured for each VIP on the load balancer. In the case of a failure of a load balancer, another load balancer takes over to ensure service continuity [3, 48, 101].

2.3.3 Virtual private clouds (VPCs)

There are various challenges experienced with the adoption of cloud services for enterprise-level use. Typical challenges occur when linking applications to virtual machines outside the cloud to the applications on virtual machines within the cloud. Major issues arise from the viewpoint of the flexibility of resource allocation and security. Virtual private cloud (VPC) concept is considered to be a possible solution to overcome these challenges. VPC acts as a private cloud infrastructure within a public cloud setting, thus providing enterprises with the secure set of cloud computing resources that are connected to their own infrastructure via VPNs. VPCs can be used to create a large pool of resources that can be accessed by multiple sites at the same time. By a VPC, the enterprise users are granted access to any range of IP addresses without any conflicts with other public cloud users. Moreover, a VPC provides secure connection and eliminates the need for setting up firewalls on the cloud and the enterprise site. A major concern here is that SPs remotely specify the security settings and are not completely aware if it is implemented completely [158]. Hence, the SPs have to ensure that for each VPC, the LAN is properly segmented and different cloud enterprise users are isolated [148].

2.3.4 Inter-data center and intra-data center networks

Inter-data center networking aims to interconnect geographically distributed servers over high speed links with high availability and resilience. Major concern is to identify the optimal placement of data centers and dimensioning the network. The authors in [48] propose using location independent addressing and having servers be a part of any server pool. The authors in [78] propose to transfer the data by splitting and forwarding along multiple destination paths with intermediate data centers in order to use the left over bandwidth in inter-data center network during the off-peak periods. This method is well-suited for performing backups and migration of non-real time data. In order to achieve energy efficient communication in inter-data center networks, the authors in [65] propose anycast/manycast-based provisioning strategies for upstream traffic towards data centers over IP-over-WDM backbone. The authors in [116], discuss the architecture and network design to achieve resilience and low cost energy consumption in inter-data center communication over elastic optical network backbone. To achieve resiliency in communication between end users and geographically distributed data centers, the authors propose manycast/multicast communication protocols. In these works, when inter-datacenter links are provisioned over IP-over-WDM links, requests are routed over virtual links that are to be mapped onto physical paths. A virtual link consists of a set of physical light-paths that enable communication over a wavelength channel.

As for the intra-data center networking, the study in [77] presents available optical technologies to interconnect huge number of identical servers and switches. This allows us to take advantage of the distributed compute power from parallel CPU in the warehouse scale-data centers. The application layer software can efficiently use the distributed compute power by assigning parallel jobs to any server irrespective of location and communication overhead. In order to achieve this aims, a flattened network with high bandwidth among the servers that are interconnected must be provided. Various topologies can enable intra-datacenter networking. These include cluster computing architectures like torus, hypercube, fat-tree [57], and flattened butterfly [68]. It is stated that the limitation of the number of ports on the cluster switches will eventually limit the number of servers that can be interconnected in a cluster. It is also worth mentioning that the rich bandwidth availability in an intra-data center network enables efficient energy consumption [77].

2.4 Cloud computing security

Security is a major concern in order to implement a protected and robust system by aiming at data confidentiality, privacy, integrity, and availability. The bigger the cloud computing market expands the more susceptible it gets to attacks of various forms. It is not possible for the cloud vendors to protect all the users’ sensitive data even with firewall and other security features setup in their environment. It is also necessary to choose a reliable SP before setting up a cloud environment because all the organizations’ sensitive data will be stored in a third party cloud SPs’ location [56, 114, 158].

The authors in [158] present the issues concerning data security, where the SP depends on the infrastructure provider for data security. This is similar to the case under VPC where the confidentiality and audit-ability of the data in the cloud is provided by the infrastructure provider [74]. Furthermore, a trusted platform module (TPM) to achieve trust at the hardware layer is also considered while the use of virtual machine monitors are proposed to secure the virtualization platform [122]. While migration and encryption attacks target the infrastructure layer, the attacks seen in the platform layer include man-in-the-middle, XML, and injection attacks [63]. Solutions proposed to overcome these attacks are mutual authentication, authorization, and web services security standards. To address software layer vulnerabilities, clients depend on the SPs [136]. Solutions to ensure software level security include strong encryption techniques and fine-grained authorization control. Last but not least, DNS and Sniffer attacks are typical threats in the network layer, and mitigation efforts include using domain name system security extensions and sniffer program in the NIC [158].

3 Network virtualization

Prior to this section, communication modes in cloud systems, as well as virtual topology design and challenges have been briefly introduced. In this section, we present detailed review of network virtualization benefits and challenges.

The concept of virtualization descents from the virtual memory concept, which led to the concepts of storage and desktop virtualization, and finally to the virtualization of networks through virtual private networks (VPN), enabling secure access to private networks and VLANs, which allow multiple users to access the network with isolation and no interference from other users. Virtualization plays an important role in providing isolation, shared resources, aggregation, dynamic reallocation, and ease of management [72]. With the advent of cloud computing and virtualization of computing resources, network virtualization decouples the roles of the conventional ISP into infrastructure provisioning and service provisioning.

Figure 1a, b illustrates a minimalist view of a virtualized physical network from [25]. As seen in the figures, network virtualization is supported by the networking environment if it allows coexistence of multiple heterogeneous virtual networks on the same physical substrate. The collection of a virtual nodes and links form the virtual network environment as a subset of the underlying physical network. As pointed out by the researchers in this field, network virtualization is identified as the final component to achieve a fully virtualized environment through interconnection of virtual machines, virtualized storage, and other virtual resources [32].
Fig. 1

An overview of network virtualization. a A minimalist illustration of network virtualization with two virtual networks over a physical network substrate [25]. (This diagram was recreated based on the original reference by using MS power point) b A basic illustration of the elements of network virtualization. Carapinha et al. [25]. (This diagram was recreated based on the original reference by using

One of the key benefits of network virtualization is scalable management of resources. For instance, moving a virtual machine (VM) from one subnet to another changes its IP address resulting in complicated routing. Since IP addresses are known to be locators and system identifiers when a VM moves its layer 3 identifier changes, thus when the VM is moved with in the same subnet (i.e., L2 domain) it is less complex than moving between different subnets.

Network virtualization also enables network programmability without being restricted to the IP and the network architecture. The existence of multi-administrative domains is hidden by network virtualization where multi-provider scenarios become possible. Furthermore, virtualization of networks also enables the deployment of various different types of applications and protocols over the shared physical network infrastructure. As stated in [25], some of the crucial requirements that a virtualized network needs to satisfy are a carrier-class reliability, guaranteed scalability, enforcement of isolation between the virtual networks. As recent research addresses the challenges regarding control, management and provisioning of virtualized networks, network virtualization has become a promising tool that minimizes the cost of ownership, allows reselling of the infrastructure to third parties and provision of the network infrastructure as a managed service [14, 32].

4 SDN and NFV

In this section, we briefly describe the SDN architecture along with a discussion on its advantages. We also provide a survey of the challenges and proposed solutions with respect to security, design, heavy demands, resilience, and scalability.

SDN concept denotes decoupling of the control and data planes in a network in order to improve the flexibility of network management and enhance the programmability of the network, as well as its reliability and flexibility [12, 86]. Network function virtualization (NFV) decouples the software implementation of network functions from the underlying hardware [39]. While SDN and NFV are not necessarily implemented together, they can cooperate and complement each other.

4.1 SDN

In the conventional networking paradigm, data transmission relies heavily on routers and switches where the data and control planes are built in these equipments. The data plane is responsible for handling the routing of data packets whereas the control plane consists of hardware and software components to create and maintain the routing tables at each node. The control plane further undertakes the quality of service (QoS), error handling, and exceptions. SDN decouples the control and data planes by introducing an application programming interface (API) between the two, thus virtualizing the switches so that they operate independent of any physical hardware and can be used accordingly by higher level applications to pull data or reconfigure the network resources using any connected device in the network [69]. As seen in Fig. 2, the SDN architecture primarily consists of three layers [75, 129]:
  1. 1.

    The application layer is the topmost layer of the SDN architecture and is responsiblefor software-driven business and security applications such as network visualization, intrusion detection systems (IDS), intrusion prevention systems (IPS), firewall, and mobility management. Also known as the network management center, the application layer communicates with the underlying control layer through the application-control plane interface called as Northbound application interface.

  2. 2.

    A control plane is a centralized component equipped with the intelligence to manage the traffic flow, take routing, flow forwarding, and packet dropping decisions through software. The control plane operates as a mediator between the application and data plane layers. When multiple controllers are deployed in a distributed environment, east-bound and west-bound interfaces are used for inter-controller communications as seen in Fig. 2. Communication between the controller and data plane layers utilizes the south-bound API.

  3. 3.

    A data plane represents the packet forwarding hardware that consists of routers, switches, and access points that are programmable to support the standard interfaces. The primary function of the data plane layer is to forward the packets to the destination in the network [117].

Fig. 2

Software-defined network building blocks and an architectural comparison of the conventional networking and software-defined networking [58]. (This diagram was recreated based on the original reference by using

4.2 Challenges in SDN

As we present in this subsection, controller placement, scalability, performance, security, interoperability, and reliability are the key challenges in SDN.

As stated in [129], in conventional networking, in case of a network equipment failure, connections can be restored through backup nodes and links in order to ensure low outage time. In the SDN architecture, since network management is handled by a single controller, the network is vulnerable to unavailability due to single point of failure at the central controller. To improve network reliability, the controller needs to be designed with the capability of enabling multi-path or fast traffic re-routing to the links that are active in case of a link or path failure. This also calls for the need for architectural changes including new alternate controllers to support the main controller in case of failure.

The scalability of the SDN controller stems from the lack of having standard API for the planes, and the SDN controller’s being the bottleneck, especially when the number of switches and nodes are increased.

Performance of SDN is evaluated in terms of flow-setup time and the flows per-second the controller can switch. The two modes of flow-setup, namely the proactive and reactive modes, have their own flow limitations and initiation overheads. These can be overcome by focusing on the causes of delay in flow-setup time and the I/O performance of the controller. Well known optimization techniques such as I/O batching, and maestro approach, IBT (input batching threshold) and PRT (pending raw packet threshold) can help improve the performance.

4.2.1 Switch design challenges

As a result of decoupling the data and control planes, an SDN switch operates on a set of rules that are presented by the SDN controller. OpenFlow is the most known and widely adopted flow-based switch design to introduce flow-level control to the traditional Ethernet switch [91]. However, as the performance of an SDN switch directly impacts the overall performance of the network, designing efficient SDN switches remains several challenges. The authors in [35] identify control and global visibility coupling as the overhead of OpenFlow in terms of switch implementation. To this end, a new switch design mechanism, DevoFlow [35], has been proposed by decoupling global visibility and control with the ultimate goal of reducing the number of interactions between the switch and the controller, as well as the number of ternary content-addressable memory (TCAM) entries.

Most recently, several researchers have studied the challenges in the SDN switch implementation [55, 58, 86, 103, 117] as summarized and compared in Table 1.
Table 1

Comparison of recent studies / reviews on challenges, solutions and open issues in SDN





Open issues

Rawat and Reddy [117]

Switch design

Increase in power consumption

High capacity processors

Low-power security mechanisms, high visibility, and scalability

Shamugam et al. [129]

Controller design, scalability, performance

Failures in controller (controller design), standard API, controller bottleneck (scalability), flow initiation/limitation

Efficiently utilize controller functions, input/output batching and maestro approach

Newer architectures must support an alternate controller

Masoudi and Ghaffari [86]

Switch design, scalability, controller platform, security

Heterogeneous implementation, flow table capacity, performance (switch design); high availability, interoperability, modularity and flexibility (controller); scalability of planes

DevoFlow [35], TCAMs, powerful CPUs into switches, ROAN, pyretic, East/West bound interfaces, ElastiCon; automated failure recovery, static rule on switch; PremOF [146] and FortNox [113]

Consistent fault tolerant data store, security, and dependability

Nunes et al. [103]

Switch design, controller platform

Excessive processing power

DIFANE [156], DevoFlow [35] (switch design); FLARE [2] (controller)

Heterogeneous networks and information centric networking

Kreutz et al. [58]

Switch design, controller platform, scalability, resilience

Excessive processing power (switch design); high availability and interoperability (controller); data/control plane scalability; link failure detection, fast reaction decisions, fault tolerance failure data plane, high availability of control plane

NOSIX [157], TCAM compression, shadow MACs (switch design); IRIS IO engine [105] (controller); LOCAL, CONGEST [107] (availability); DevoFlow [35], maestro [22], NOX-MT [138], Kandoo, DIFANE [156] (scalability). Google B4 [61], SlickFlow [115], INFLEX [10] (resilience)

Fault-tolerant SDN, migration path to SDN, extending SDN toward carrier transport networks, network-as-a-service cloud computing paradigm, suitable interface between ROAN layers.

Hu et al. [55]

Switch design

No specifications on handling feedback data, high traffic burden slows down data forwarding

Self-learning in the controllers via traffic pattern analysis

High intelligence in flow table/rules control

Hakiri et al. [50]

Scalability, security

Flow setup latency, Load-balancing, over-provisioning (Scalability); DDoS, malware attacks, spam, phishing

Security assertion markup language, intrusion prevention system (IPS), OF-RHM, security policy in L4 to L7

Network-wide view in controllers, automated mapping between planes, formal modeling and model checking for trustworthiness.

Li et al. [79]

Security switch, channel, controller

Scanning, spoofing, hijacking, DoS

Address validation, authentication, IDS, encryption, COFFEE [123], FleXam [133]

Securing flows, access control and policy enforcement

Ali et al. [8]


Forged traffic flows, DoS, switch hijacking

Enforce rate bounds for control plane, AVANT-GUARD [132], PermOF

Increase in-network capabilities for security functionality.

Scott-Hayward et al. [126]


Unauthorized access, data leakage, data modification, compromised application, DoS

FortNOX [113], ROSEMARY [131], LegoSDN [28]; AVANT-GUARD, VAVE [153], CPRecovery [42], (DoS); PremOF, AuthFlow [41], SE-Floodight [112]

Data leakage, data modification, secure recovery from failures

Flow tables store flow matching rules within network devices; hence, providing switches with large and efficient flow tables becomes a challenge [9]. Further challenges that are identified in the conventional OpenFlow switches are the performance of these switches in terms of fast versus slow path, the latency versus throughput trade-off of the control channel, and the hardware versus software design challenges.

As presented in the table, from the standpoint of computing, research investigates the maximum throughput that can be achieved by the OpenFlow switches with the high capacity processor that they require to work efficiently. Furthermore, as seen in the table, NOSIX is one of the proposed solutions, a portable API that separates the application requirements from the switch heterogeneity [157]. Most of the existing approaches suggest utilizing TCAMs [21] for holding flow tables; these are small in capacity and cost. Moreover, compression techniques to reduce the number of entires in flow tables are being researched. Espresso heuristic [121] is another solution that is proposed to reduce the forwarding information base whereas shadow MACs [4] use label switching to overcome inconsistent updates and rule space exhaustion [58]. In addition, various hardware combination of novel SDN switches in order to optimize the performance and capabilities, such as SRAM, RIDRAM, DRAM, GPU, FPGA, NPs, and CPUs work with TCAMs. El Ferkouss et al. [37, 83, 94, 102, 111, 120]. In the surveyed studies, one can also see methods proposed by Rain Man firmware an alternative to the TCAM-based design that includes need for new hardware architectures for future SDN switching devices to enable scalable forwarding planes [86]. The research in [103] proposes the solution DIFANE [156] which reduces number of requests to controller by proactively pushing flow entries to the DevoFlow [35] switch, which handles short-lived flows in switch and long-lived flows in controller.

4.2.2 SDN controller platform challenges

Among the typical challenges with respect to the distributed controller platform, the following can be counted: latency between a forwarding device and a controller instance, fault tolerance, load balancing, consistency, and synchronization [16, 73, 124]. Further challenges in controller platform are as follows:

  1. 1.

    High availability: The authors in [58, 86, 103] identify high availability among the challenges of a controller platform and investigate methods to meet high availability requirements by using the classical LOCAL and CONGEST models of distributed systems [107], improving the southbound API and controller placement heuristics. Furthermore, it is reported that fault tolerant data storage is a crucial requirement to build a reliable distributed controller [16, 18, 19]. Moreover, the authors in [86] propose a runtime system for automated failure recovery by spawning a new controller instance. In addition, an efficient approach is also presented where static rules are installed on switches by controllers in order to locate link failure.

  2. 2.

    Control delegation and scalability: The importance of delegating the control to the data plane is discussed in [58, 86] along with its impact on the improvement of network performance by keeping the basic network functions in the data plane such as OAM, ICMP processing, MAC learning, neighborhood discovery, defect recognition, and integration [46, 104]. This approach also yields controller failure tolerance to be capable of keeping the basic network operations alive in case the controller fails. Furthermore, SDN control function such as reporting state and attribute value changes, threshold crossing alerts and hardware failure can be delegated to the data plane in order to enhance operational efficiency.

  3. 3.

    Modularity and flexibility: The need for modularity and flexibility in controllers is tackled in [58, 86]. The proposal of recursive abstraction of OpenFlow controllers, namely recursive abstraction of OpenFlow networks (ROAN) [106] deploys multiple controllers in a hierarchical manner. Under the same concept, ElastiCon [143] is an elastic distributed controller architecture that manages dynamic expansion or reduction of the controller pool based on the traffic [86].

    The SDN controllers lack modularity; hence, the developers have to implement the basic network services from scratch [26, 104]. This results in difficulty in maintaining, building, scaling, and hindering with further development. Pyretic [97] and corybantic [96] are possible solutions that are considered for modularity in SDN [86].

  4. 4.

    Interoperability and application portability: Interoperability and portability solutions are expected to prevent compromise in safety or performance of the network while allowing various loosely coupled network applications to coexist on the same control plane. In [103], FLARE [2] , a control architecture for deeply programmable networks has been proposed to provide programmability to interface between control and data planes as well as the individual planes themselves.


4.2.3 Resilience

Moving SDN control plane functionality to a logically centralized remote location introduces challenges concerning critical control plane functions such as link failure detection or restoration. Researchers tackled SDN resilience point out that the malfunctioning of any SDN element should not degrade service availability [58, 103]. While using distributed controller architecture for SDN resiliency sounds viable, related work reports potential trade-off between resilience and scalability, and further between durability and consistency. The existing SDN resilience solutions presented by the authors include Google B4 [61], SlickFlow (resilient flow routing in OpenFlow networks) [115], and INFLEX (cross-layer network resilience that provides on demand path fail-over) [10].

4.2.4 High volume demands

The authors in [53] point out the challenges regarding increase in demand volumes and consequent challenges. Suitable services for various types of data traffic is needed such as video conferencing or web browsing in a short-time range, along with efficient resource requirement utilization. The main challenge is reported as the accommodation of the growing demands while maintaining the quality of service and security for the flows [6, 17]. Network administrator also needs to estimate the required number of controllers for determining the network topology and the localization of these controllers.

4.2.5 SDN scalability

Challenges experienced with respect to controller scalability are listed as follows [50]: (1) the overhead of flow setup latency and additional control plane traffic increasing the network load, (2) the eastbound and westbound API’s communication between SDN controllers, and (3) excessive use of computational power and storage space while throughput causes decline in the response time. DevoFlow is one of the scalability solutions that simplifies the design of high performance OpenFlow switch to enable a scalable management architecture [35]. DIFANE is an early scalable solution that aims to reduce the number of requests destined to the controller by splitting the rule-set over the switches in the network [156]. Kandoo is also a scalable solution that uses two layers of the controller in order to reduce the overhead of the events that occur frequently. This ultimately aims at creating a distributed control plane [52]. In addition to these, the concept of elasticity of SDN controllers is considered while most of these studies are classified into the following three categories: control plane scalability, data plane scalability, and hybrid scalability. The proposal of developing and deploying high performance controllers in order to increase the throughput of the control platform is discussed as another approach to overcome the controller scalability. As seen in the earlier section, delegation to data plane is one of the solutions that can overcome the scalability challenges of the controller. Lastly, the hybrid approach proposes the use of authoritative switches to share the workload of the controller and improve the scalability [58, 86, 154].

4.2.6 SDN security

A comprehensive survey on SDN security has been presented in [126] along with security threats, challenges as well as existing solutions. Besides, the authors in Li et al. [79] discuss the security challenges in OpenFlow-based SDN, mainly focusing on the challenges related to the OpenFlow switch, controller, and the channel. At the switch level, security issues are identified as confidentiality, integrity, and availability against spoofing, scanning, hijacking, DoS (denial of service), and tampering attacks. Malicious actions and intrusions can be seen as security threats at SDN the controller level. The attacks related to the channel are man in the middle attack, network monitoring, and repudiation; and they can be used to infer sensitive information.

In OpenFlow-based SDN, various security concerns are introduced by the programmability of the control logic centralization. It is stated that rapid evolution of SDN may cause vendors to avoid complete implementation of the specifications and to skip the transport layer security (TLS) entirely resulting in an access path for the attackers. Counter measures against these attacks have been reported as follows; encryption algorithms can be used against scanning while switches and controllers should be equipped with intrusion detection systems (IDS) against intrusion attacks [127]. Spoofing and hijacking can be defended by authentication and address validation techniques. DoS can be defended by enhanced trust mechanism and access policies. FleXam is a DoS defense mechanism that allows controller to access packet level information and help detect DoS attacks [133].

The research in [8, 58] discuss the categories of threats and vulnerabilities in SDN and list the threats under the following categories attack on network entities by forged traffic flows, DoS attacks on switches and controllers, and exploitation or hijacking of switches in the network to launch attacks on other entities. Control plane communications may be targeted to exploit the weaknesses in secure socket layer (SSL) and TLS protocol implementations. Stringent authentication mechanisms and trust models can mitigate the identity-based attacks while DoS is reported to be prevented by placing rate bounds on the requests of control plane.

Sandboxing is a well-defined protocol to control access to security domains. Attacks such as control plane saturation where control plane is overloaded by botnets can be overcome by the AVANT-GUARD data plane extension [132] that allows control plane to define traffic statistics or conditions. Another solution is enabling the switches to proxy the TCP handshake.

The authors in [50] discuss the potential challenges and security in SDN, associating it with the programmable aspect that introduces a complex set of problems. The authors propose security assertion markup language (SAML) allowing public and private key exchange; which is a security policy with unified syntax for OpenFlow protocol that enables authentication, authorization, access control, and secure transport between the controller and application or multiple controllers and switches. While IPS [118] are presented to cope with intrusion attacks, layer 4 to layer 7 services are used to insert different security policies into OpenFlow. Furthermore, assigning virtual IP addresses to hosts to hide the real IP from external attacks by using OpenFlow random host mutation (OF-RHM) [60] can be considered as another countermeasure against security threats in OpenFlow-based SDN.

In a comprehensive survey study in [126], security issues and challenges against persistent attacks have been introduced along with useful insights for countermeasures. Some of the main security issues that need to be addressed are confidentiality, authenticity, integrity, availability, and consistency. The criteria to evaluate the security provided by SDN are reported to be the network management, costs, attack detection, and migration. Major concerns related to the security of SDN are reported as unauthorized access, data leakage, data modifications, malicious/compromised applications, and DoS. The survey provides a thorough discussion on the pros and cons of SDN in improving the security of the network and the additional security challenges it brings along.

4.3 NFV

In this section, we present the NFV architecture, its benefits in cloud systems, challenges, and proposed solutions of NFV with respect to management and orchestration, performance, resource allocation, reliability, stability, and security (Table 2).
Table 2

Comparison of recent studies / reviews on challenges, solutions and open issues in NFV





Open issues

Cotroneo et al. [34]

Net. function softwarization

Reliability NFVI, limitation of fault injection testing tools

DS-Bench [43]/D-Cloud, refail, Simian army, CloudVal

No open issues presented

Han et al. [51]

Network function virtualization

Virtual appliance performance, dynamic instantiation, migration, efficient placement

NAPI, DPDK, CLickOS [85]

Optimal performance, lightweight simplified VM, redirection architecture and carrier’s data center footprint, troubleshooting and fault isolation.

Mijumbi, et al. [95]

Management and orchestration, resource allocation

MANO management, deployment, operation resource migration, allocation, placement

Cloud4NFV, NetFATE, virtualized S-GW/P-GW, MIQCP, BIP, ViRUS [145]

Interfacing, interoperability, traffic and function monitoring, distributed management, dynamic resource allocation, VNF survivability.

Li et al. [80]

Network function virtualization

Function virtualization, portability, standard interfaces, function deployment, traffic steering

DPDK, NetVM, ClickOS [85] (FV); virtual software NFs (portability); normalized North/South bound API (Std. interfaces); heuristics (traffic steering)

Optimized solutions for traffic steering

Lal, et al. [76]


Isolation failure, regulatory compliance failure, DoS protection failure

Hypervisor introspection and security zoning (isolation), geo-tagging using remote attestation (regulatory compliance), flexible VNF strategic deployment (DDoS)

Standard interface for virtual security functions, securely manage/monitor VNFs during migration, trust management between vendors.

Yang and Fung [152]


Elasticity of NFV, standard interface, management and orchestration

Elasticity control signals through trusted functional blocks

Compromised VNF, DDoS, trust management in NFV

NFV enables the deployment of network elements virtually on demand and quickly on commodity platforms in a shared environment by the use of servers and virtualization technology [100].

The NFV management and orchestration (NFV-MANO) is considered the main functional module of the NFV architecture; it is mainly responsible for deployment, management, and the orchestration of the network services. The NFV orchestrator (NFVO), VNF manager (VNFM), and virtualized infrastructure manager (VIM) are the three main blocks of the NFV-MANO [100].

Figure 3 illustrates the NFV architecture in detail [39]. The NFVO mainly performs the network service orchestration and the life cycle management. The VNFM handles life cycle management of the virtual network function (VNF) instances and each VNF instance is assigned a VNFM. The VNFM and NFVO collaboratively instantiate, configure, update, and terminate the VNFs. The VIM manages and orchestrates the NFVI resources such as on-boarding VNFs. It supports and manages the VNF forwarding graphs (VNFFGs) like virtual link creation and maintenance. Furthermore, the VIM performs resource management for both software and the physical repositories.
Fig. 3

Network function virtualization components along with management and orchestration design blocks based on ETSI specification in [39]. (This diagram was recreated based on the original reference by using

The NFV architecture further includes other blocks such as the VNF, the software version of the network services available on the physical network devices (e.g., firewall and load balancing), the element management (EM); which is responsible for the functionality of configuration, fault management, performance, and security. The NFV infrastructure (NFVI) offers a platform for deploying the network services in the form of physical compute resources, storage, and network. In addition, the operational support system/business support system (OSS/BSS) provides the network service by exchanging information with the NFV-MANO functional blocks; it also provides management and orchestration of legacy systems [100].

4.4 An overview of NFV challenges

The authors in [51] discuss the challenges in NFV. During virtualization, even light utilization of the underlying network can lead to abnormal latency variations and significant throughput stability. Furthermore, efficient placement of virtual functions and dynamic on demand instantiation is an issue that needs to be researched in order to enable successful adoption of the NFV solution. To address, the placement of VNFs, the authors envision placing the network functions at the edge of the network. In case of mobile core, network authors propose installation of virtualized packet gateways to handle traffic for a small geographical location at the mobile telephone switching office (MTSO).

The authors in [34] discuss the software reliability-related challenges in NFV. They discuss the use of fault injection techniques that deliberately introduce faults to a system, with the aim of assessing the impact of these faults on the performance and continuity of the service along with efficiency and effectiveness of the use of these mechanisms. The fault injection testing discussed in this paper are as follows: (1) for fault injection tests on VMs, D-Cloud [13] adopts QEMU and emulates hardware faults; (2) for fault injection testing on cloud management stack, PreFail [64], and Simian Army [139] are possible tools that allow to inject faults to cloud computing platforms. (3) For fault injection testing on hypervisor, CloudVal [109] framework is considered as a possible tool. It is worth mentioning that these tools are applicable to a limited extent of NFVIs; hence, the authors in [34] discuss the limitations to develop a new fault injection tool for NFVIs.

4.4.1 Management and orchestration

The authors in [95] focus on the scenarios where services to a particular customer are provided by functions that are scattered across different server pools. The challenges are listed as follows: an acceptable level of orchestrations at each user level, consistent, and on demand instantiation of all required functions to ensure the manageability of the solution. Some approaches presented here include Cloud4NFV [134, 135], an end to end management platform for VNF; and NetFATE [81], an orchestration approach for VFs. Furthermore, the architecture proposed in [33] is built on an orchestrator that ensures automatic placement of virtual nodes and allocation of network services on them.

The inter-operability support is a key requirement of NFV. The ETSI MANO framework is more focused on defining the intra-operability interfaces without providing clear guidelines on the inter-operability. The dynamicity of functions, where functions are moved from one VM to another, undervalues the availability monitoring mechanism as a part of the end-to-end management solution. The relationship between ETSI-proposed NFV-MANO framework and traditional network management functions remains open definitions.

4.4.2 Network performance of VNF

The authors in [51] discuss the challenges experienced in the network performance of VNFs. When a virtual network function is deployed, both host and network resources are consumed. The state of the art in the performance guarantee under NFV focuses on either host sharing or network sharing whereas sharing both types of resources remains open. Offering performance guarantees and isolation is costly and technically difficult due to resource sharing and competition between multiple network functions and also due to the heterogeneous resource specifications of different functions. When softwarized network functions are deployed through virtualization on general purpose servers, the challenge is experienced with respect to the difficulty faced to completely avoid performance degradation and knowing to what extent the performance factors such as throughput and latency will be affected. The performance degradation should be kept minimum in order not to affect the portability of VNFs on different hardware platforms. The authors discuss the use of VNF instances, software technologies like Linux’s new API (NAPI) [38] and Intel’s data plane development kit (DPDK) [147]. Network performance information on different levels such as hypervisor, virtual switch, and network adapter must be gathered by the NFV architecture. In order to make proper design decisions of NFV systems, an understanding of the maximum achievable performance of the underlying programmable hardware is required [51].

4.4.3 Challenges at the functions level

In [80], the challenges at the functions level are listed as NFV portability, function virtualization, standard interface, function deployment, and traffic steering.

The challenge with respect to portability is related to achieving high performance using the hardware accelerators while having hardware independent network functions at the same time. The ability to load, execute, and move the VNFs across different but standard servers in a multi-vendor environment was expected to be possible in the NFV framework. The virtualized network functions defeats the portability goals and major benefits of NFV such as multi-tenancy and resource isolation. To cope with this, using a virtual software environment to deploy the network function has been presented as a viable solution. Once this is achieved, OS-independence of VNFs can be achieved, and resource isolation is achieved by deploying the VNFs in independent VMs. Here, portability can be allowed via hypervisor layer by separating VNFs from underlying OS [80].

The challenge with function virtualization is that neither the virtual machine nor the hypervisor is optimized to achieve high performance like high I/O speed, fast packet processing, short transmission delays when processing the middle-boxes from standard servers. As for the need for OS-independent platform, it should be able to host a wide range of VMs and software packages in order for the servers to be able to implement various functionalities. In addition, to cope with the challenge with multi-tenancy, the NFV hardware and software platforms should support multi-tenancy since they are run simultaneously by software belonging to the different operators [80].

The challenge in the deployment of standard interfaces [130, 155] is concerned with the interface between NFV and underlying infrastructure, as well as the interface between the centralized controller and the VNFs. This is required to help set a smooth link between the NFV and the upper/lower layers. The solution proposed by the authors is to have normalized North/South bound API between these layers [80].

The challenges under function deployment [24, 33, 125] are mainly related to the algorithmic and system design, which stems from the automated provisioning of resources for network and function processes with respect to the usage to the resources. The challenge of automated placement and allocation of the VNFs has significant impacts on the performance of service chaining. As a solution to this, a usage monitoring system has been proposed to collect and report the behavior of resources. Furthermore, translating higher-level policies generated from the resource allocation and optimization mechanisms into lower level configurations is identified as another issue. The authors in [80] report the need to develop standards and templates in order to guarantee automated and consistent translation. As the last point under the challenges at the functions level, traffic steering is pointed out. As stated in the reference study, online computing of traffic steering can be achieved only by heuristic algorithms that reduces the computational complexity [80].

4.4.4 Resource allocation

Efficient algorithms are required to help determine the placement of network functions and migration between servers for objectives such as load balancing or failure recovery [141]. In order to address the challenge of sub-optimal resource utilization, the authors in [95] propose a function placement model with the objective of reducing the network overhead load imposed by the control plane while mixed integer quadratically constrained program (MIQCP) [92] has been proposed for mapping VFN forwarding graphs to the physical resources, a binary integer program (BIP) [151] has been proposed as a greedy heuristics to improve computational efficiency. To overcome the migration challenges where physical server may be placed in various different InP domains, the authors propose the use of ViRUS [145] allowing runtime system to switch between different blocks of code.

4.4.5 Reliability and stability

The authors in [51] report the importance of reliability, which allows network operators to offer specific services like video call and video on demand, irrespective of physical, or virtual network appliances. When evolving to NFV, the carriers should guarantee that neither the service level agreement nor the service reliability is affected. This availability requirement is often accompanied by the necessity to provide stability that poses another challenge to NFV, and these typically happen when large number of software based virtual appliances from various different vendors are relocated/reconfigured and run on different hypervisors.

4.5 Security

The authors in [76, 152] discuss several types of vulnerabilities and attacks possible on NFV. Below is a list and discussion of possible attacks and vulnerabilities under NFV.
  1. 1.

    Isolation failure risk: This type of attack is also known as a VM escape attack, and it occurs when an attacker gets access to the hypervisor through compromised VNFs running on the hypervisor. The authors state that these attacks are caused due to the failure of proper isolation between the hypervisors and the VNFs. This attack can also be seen in the scenarios where the network components that are deployed and connected dynamically using NFV can lead to improper separation between the network and its subnet; this can lead to the attacker compromising the virtual firewalls and restrict their functionality only to allow enough access to carry out the attack. This can also lead to the attacks caused by the elastic nature of the NFVI, allowing the attacker to gain knowledge about a multi site network infrastructure. The best practice solution is hypervisor introspection and security zoning in order to prevent against this type of attack as proposed in [76].

  2. 2.

    Regulatory compliance failure: Since NFV allows migration of VNFs, it becomes possible to violate regulatory policies, allowing attackers to migrate the VNFs from legal location to an illegal location and resulting in a complete ban of service or exerting a financial penalty at the service provider’s end. Geo-tagging using remote attestation is considered as a possible solution against this type of attacks [76].

  3. 3.

    Denial of service protection failure: This attack can be used to exhaust the network resources in order affect service availability. A compromised VNF can be used to generate and send a large number of traffic to other VNFs over the same or different hypervisors. This attack can be used to consume large amount of resources like CPU, storage, and memory. A solution proposed is the enablement of flexible VNF deployment.


In addition to all, the study in [152] presents further vulnerabilities under the dynamic service scaling and elasticity of NFV, decomposing the services from data plane and control plane, enforcing policies and virtualizing resources from control functions, and managing/controlling the entire network [67, 137]. In order to ensure security in these scenarios, the elasticity control signals must pass through trusted NFV orchestrator, VNF managers, and VIM. As stated by the authors, monitoring and managing NFVI and VNFs for security is challenging due to the dynamic and complex nature of these components in the virtualized environment. In the same study, security challenges associated with the standard interface is also discussed by the authors: this is because various security services can be defined based on user demands through the standard interfaces before using these security functions.

In addition to the challenges stated above, managing trust chains and trustworthiness evaluation of products from various vendors are still open and least tackled issues in NFV security [152].

4.6 SDN-NFV solutions

In this subsection, we discuss the integrated SDN-NFV architecture, and discuss the advantages of combining the two technologies. We survey the challenges and proposed solutions with respect to integrating SDN and NFV in cloud systems (Table 3).
Table 3

Comparison of recent studies / reviews on challenges, solutions and open issues in SDN-NFV integration





Open issues

Wood et al. [149]

SDN-NFV security challenges

Integrity of software-based network

Identified as a remaining challenge

Limitation on smart data plane by encrypted payloads

Matias et al. [89]

SDN-based NFV architecture

Complexity of optimal placement; isolation of shared and virtual resources, traffic steering, stateless processing

FlowNAC [88]

Optimal VNF placement under dynamic settings

Mekky et al. [93]

NFV enabled with SDN data plane

Routing inflexibility, choke points, imbalanced flow

OpenNF, FlowTag [40], NEWS [93]

Handling traffic demand uncertainty

Lorenz et al. [82]

Security of SDN-NFV

Controller-centric, VNF-centric, hybrid SDN-NFV approaches; PFG appliance, control plane security and performance

Authentication and authorization, FortNox, encryption mechanisms, mutual authentication. control plane firewall placement, hybrid approach

Challenges remain open issues

Ma et al. [84]

SDN-NFV industry 4.0

Performance, data transmission speed and processing; computation, reliability, design complexity, efficient use network devices

FlowVisor, VTN, SDCRN, ICN, hierarchical construction of multiple controllers

Challenges concerning hierarchical controller design

Duan et al. [36]

SDN-NFV QoS assurance; VN construction

QoS guarantee; VSF abstract descriptions, available/discoverable VSF, optimal set of VSF

Cooperation of infrastructure provider, VSF supplier, VN operator, composite network-cloud SPs (QoS); centralized broker-based orchestration, distributed policy-based choreograph (VN construction)

E2E QoS, cooperation from diverse functional roles, VSF composition in the SDNV

Reynaud et al. [119]

SDN-NFV security challenges

NFV vulnerability affects SDN controller, SDN controller vulnerabilities affect NFVI

Survey covering broad range of solutions

Security in 5G

SDN and NFV concepts address different aspects in cloudified communications. It is worthwhile mentioning that they denote separate concepts; however, they can benefit from each other. SDN has contributed to the virtualization of network infrastructure, which enables us to isolate, abstract, and share the network infrastructure. SDN provides a logically centralized control plane that can flexibly direct packet flows between network devices based on programmable policies. Some examples of the SDN technology are OpenFlow, ForCES, and I2RS. On the other hand, NFV is used to create virtual network functions that are software instances of the standard network functionalities. The NFV transforms the traditional hardware appliance with customized application-specific integrated circuits (ASICs) into software running in VMs on common of-the-shelf hardware to increase flexibility and lower the cost. VNFs are composed of service chains, and they are the basic elements to achieve complete virtualization of service delivery. Inter VNF communication and traffic steering are considered to be a limitation of the underlying legacy network infrastructure [99]. The interaction between the SDN and NFV is proposed to evolve beyond providing network infrastructure that significantly improves how VNFs are designed. Figure 4 illustrates a typical service decomposition over software defined network function virtualization (SDNFV) via service graphs [149]. In the example scenario in Fig. 4 ([149]), packet flows may require network functions different from each other. A service graph is used to indicate the order and type of network functions used to process that particular packet flow. This is achieved by mapping the network function to the NetVM hosts. Upon the arrival of a packet, a flow table lookup is called to check whether its service graph is already determined. In the case that the service graph has not been determined yet, the packet is transferred to the SDN controller. The SDN controller undertakes the service graph determination process, and updates all NetVMs associated to that flow with the new flow table rules. Performing complex services becomes possible for SDN applications by placing flow rules across multiple hosts [149]
Fig. 4

Service decomposition under SDN-NFV integration as presented in the reference study in [149] via network functions hosted on NetVM hosts and service graphs for the incoming flows. (This diagram was recreated based on the original reference by using

4.6.1 SDN enabled NFV-architecture

The research in [89] presents the advantages of an SDN-enabled NFV architecture by discussing the progressive advancement from the SDN-agnostic NFV architecture to a fully SDN-enabled one. This approach extends the application domain of NFV with respect to service provisioning. While effective programming the underlying network to build VNFs is the key issue, reducing the cost of operation is reported as one of the main outcomes of the SDN-enabled virtualized infrastructure. The research tackles how to overcome the limitation imposed by the trade-off between flexibility and performance through SDN-enabled NFV solutions.

To test different architectures and show the difference in their analysis, the authors present the use of the FlowNAC solution [88], which is already deployed over the OpenFlow-based EHU-OEF infrastructure. The idea of using FlowNAC in the service provisioning scenario is to achieve fine-grained control. In the same research [89], the main challenges introduced in the SDN-enabled NFV architecture are listed as follows: (1) the design of the VNF by splitting the components to be deployed over compute and network resources, and having a network infrastructure that supports the dual role for traffic steering and VFN processing; (2) addressing the complexity of optimal placement based on VFN design employing network elements and the orchestration of additional type of resources; (3) isolation of shared virtual resources from different tenants and the necessary interface that the virtualization layer is supposed to provide for the effective use of the virtual compute and network resources; and (4) guaranteed isolation between the traffic steering and stateless processing of network function by the underlying network infrastructure, along with the isolation between processing of different network functions in both control and data planes.

4.6.2 Enabling NFV within SDN data plane

The authors in [93] study how SDN benefits from NFV by chaining network function on demand directly on the SDN data plane. Current isolation of network functions from SDN makes the controller unaware of the number, placement, and capacity of the network functions causing challenges such as inflexibility in routing, choke points, and imbalanced flows. The challenge with isolation of the control on the network functions from the SDN is that it becomes difficult to identify a flow at the SDN switch as the network function can modify the packets in transit. It is worth noting that the network functions are capable of dropping packets, changing the packet contents, absorbing and generating new packets, whereas these modification to the packets are unnoticed by the SDN controller. Such challenges can be overcome by the placing the network functions in the SDN data plane and letting the centralized controller have complete knowledge of the network state while it supports the network functions. More specifically, OpenNF proposes a virtualized network function architecture by having a central OpenNF controller that controls the network functions and interacts with the SDN controller [44] FlowTag is another proposal that tracks the flow by re-defining some packet header fields as tags and uses SDN to support service chaining [40]. This approach also keeps the network functions outside the scope of SDN. The authors in [93] propose the new enablement within SDN data plane (NEWS), which delegates SDN complete knowledge about the state of the network at the same time, efficiently and scalably supports the network functions, and thus chaining multiple network functions locally on the SDN framework. The framework uses open vSwitch to present the implementation of this architecture and show effective enablement of network functions by populating the SDN data plane with network functions.

4.6.3 SDN-NFV-based security solution for enterprise networks

The authors in [82] have proposed various architectural designs to integrate SDN-NFV based security solution to enterprise networks in order to reduce the operational costs [27]. Currently, the security system of enterprise networks such as PGF (perimeter gateway firewall) may fail to detect malicious attacks and intrusion from nodes that are compromised, and thus they may lead to installation of additional security systems at each level increasing the acquisition and maintenance expenses. The authors show differences in the application of SDN-NFV stateful/stateless firewall. It was observed that even an SDN controller-centric stateless firewall approach where the handshake is handled by the controller, showed high throughput once the connections between the client and the control plane is established. However, high latency and scalability issues remain. On the other hand, the VNF-centric approach where all the incoming traffic is diverted through the VNF firewall makes application level filtering possible and results in low latency during the connection. Although VNF-centric approach has been shown to be scalable and reliable, limited throughput per instance and high resource consumption in case of an increase in traffic in flow occur as its drawbacks. To cope with the drawbacks of the SDN controller-centric and VNF-centric approaches, the authors finally came up with the hybrid approach that adopts a VNF-centric approach for the connection setup and the SDN controller-centric approach for long lasting data intensive connections. This approach demonstrates high throughput with improved scalability and low latency. However, these benefits come at the expense of increased complexity and the lack of availability in application level filtering for some of the established connections [82].

It is worthwhile mentioning that there are also challenges to be addressed prior to this hybrid approach being adopted as also reported by the authors. Firstly, ensuring control plane security remains an open issue. Possible solutions that are discussed include using authentication and authorization management, the placement of control plane firewall between the controller and switch to identify rules that are possibly corrupted, and using encrypting the connection for controller and switch against eavesdropping [15, 113].

4.6.4 SDN-NFV-integrated architecture for industry 4.0 environment

The software-defined cognitive radio network presented in the same study enables the SDN controller to make the frequency band decision so as to reduce the overhead due to the computation on the equipment below and to separate transmission of the control signals and the payload. The OpenFlow access point (OF-AP), is used to grant control to the administrator from the SDN controller. Hierarchical approaches to construct multiple controllers have also been discussed as possible improvements.

In addition, using information-centric network (ICN) enables a cache mechanism in order to store the message content from the database onto a cache sever thus reducing the delay, and improving the speed to provide high performance and scalability [84].

4.6.5 Service quality assurance in virtual network environment

In [36], challenges concerning QoS have been presented by focusing on the concerns of a software-based virtual function being capable of guaranteeing similar quality of service as that guaranteed by the dedicated hardware. The challenge of having cooperation from the infrastructure providers, VNF suppliers, VN operators, and composite network cloud service providers while moving to an integrated SDN-NFV service environment is important in order to be able to provide end-to-end (E2E) QoS guarantees. The authors further mention the challenges posed to the traditional performance evaluation methods such as queuing theory-based modeling and analysis due to the dynamic development of virtual service functions provided by the SDN-NFV.

4.6.6 Virtual network construction

Virtual network construction challenges are discussed in [36]. Some of these challenges are related to the availability and discoverability of the virtual service functions (VSFs). Although the composition of cloud service functions have been extensively studied to provide some useful techniques to use the virtual service function composition [32], these studies were mainly focused on the computing service and not particularly the network services. Thus, the authors propose further studies to be conducted in the composition of the virtual service functions with respect to SDN by focusing mainly on virtual service function and virtual compute functions across both the computing and networking domains. Centralized broker-based orchestration schemes and distributed policy-based choreograph mechanisms are the solutions that are discussed in this work.

4.6.7 Security challenges in SDN-NFV

The study in [119] discusses some of the security concerns faced in the SDN-NFV architecture. When SDN is used in the tenant domain, the SDN controller that is deployed as a VNF controls the traffic and instructs other VNFs on the actions to perform. Thus, the NFV vulnerability could compromise and affect the SDN controller and the other VNFs to bring down an entire network service. When SDN is used in infrastructure domain, the security vulnerability of the SDN controller is also capable of affecting the entire NFVI, as the SDN controller is a part of the NFVI when it is used in the infrastructure domain. SDN-NFV is used to support 5G networks to facilitate the convergence of both fixed and mobile access by programmable networks. Multi-tenancy of 5G leads to a slight shift in the confidentiality, integrity, and availability requirements. These security impacts are not negligible in 5G infrastructure.

The research in [149] aims to find out the affect of software-based networks on the security of data center and wide area networks. Attackers are more likely to target powerful and flexible networks. The packet data can be manipulated and viewed by the network elements, also with no input from endpoints of the flow, the controller redirects the packets. The challenge here is to ensure integrity and maintain level of trust between the control and data planes. The main challenge that is pointed out by the authors is to identify the limitation on the benefits and capabilities of smart data plane when an application encrypts the traffic before it is sent to the network.

5 CloudRAN solutions

With the recent explosion in the volume of mobile data, service providers are challenged with the need to improve the network capacity and offer high speed transmission facilities. A possible solution to cope with the network capacity challenges was the addition of several small cells forming a complex heterogeneous infrastructure. Another approach has been introduced by multiple input multiple output (MIMO) and massive MIMO [45, 54] technologies to provide service to a large number of users through several antennas in the same frequency. The operational and capital costs of achieving this and other challenges (e.g., inter-cell interference) have introduced further challenges for the service providers [29].

Cloud-radio access network (cloudRAN) is expected to provide various benefits to mobile operators especially for them to cope with the increasing expense of infrastructure and operational costs due to the large volume of the mobile Internet traffic. The high operational costs result in a drastic fall in the average revenue per user when compared to the increasing expenses. In order to support this surge in mobile Internet traffic, the operators will have to spend more to build and operate a new network infrastructure [150].

Several proposals have been presented to ensure energy efficiency handling of the increasing traffic requirements; however, these approaches were researched for several years but have eventually reached their limitations. Some of the approaches that were researched are (a) advanced transmission techniques such as MIMO and beam forming, which aims to improve the spectrum efficiency; (b) cognitive radio approach to access the spectrum holes using dynamic spectrum access technologies, (however, it lacks reliability and consistency in service provisioning); and (c) introduction of small cells to reuse the frequency (however, this would increase the number of air interfaces and infrastructure operation and management cost) [150].

Various limitations are present in the current RAN architecture with respect to supporting mobile operators with the increasing demands introduced the move to cloud-based IT platforms to provide the necessary computational power and lower operational costs [29, 150].

CloudRAN is expected to provide strong reliable service, with low cost and improve the revenue of mobile operators. It is expected to support the various air interfaces and provide flexible software upgrades, and also, optimize the mobility, coverage, and operation in broadband cellular wireless systems [150].

The cloudRAN (also denoted as C-RAN) is an advancement in the RAN architecture that attempts to apply the cloud technology to the host and deploy RAN functions. Traditional RAN network is based on a distributed architecture, and it uses the backhaul network to interconnect the distributed cell sites with the baseband units, where the baseband functions are executed [29].

The C-RAN architecture aims to centralize the baseband functions at some centralized location that are connected to the cell site with the help of the fronthaul network. C-RAN aggregates all the computation resources in a centralized location and handing-off the simpler functions to the remote radio head (RRH). Thus C-RAN will reduce the expense of operations, enable pooling of processing resources across the cells, and reduce capital expenditure. C-RAN can be virtualized to provide load balancing and scalability and help manage resource utilization [150].

C-RAN helps improve energy efficiency by freeing the individual base stations from providing round the clock service. The dynamic allocation of processing capability and migration of tasks to the base station pool from remote data centers help reduce the power and load [150].

Greater spectral efficiency at the cell edge by sharing of channel state information of mobile services among the cooperating base stations leads to increase in the capacity and enabling multiplexing of streams on the same channel, as well as enabling multi-point cooperation. The enablement of multi-point cooperation improves the efficiency, enables faster hardware upgrades, and provides greater spectral efficiency at the cell edge with the help of efficient multi-cell coordination [5, 150].

5.1 C-RAN architecture

As illustrated in Fig. 5, the C-RAN architecture mainly consists of a baseband unit (BBU), an optical transmission network (OTN), and a remote radio head (RRH). The base station functionalities such as baseband processing and packet processing are carried out by the BBU whereas the frequency conversion, A/D and D/A conversions, amplification, and radio functions are handled by the RRH. The RRH communicates with the BBU pool using optical fibers. The antennas are equipped with RRHs which help in transmitting and receiving radio frequency (RF) signals. Dynamic employment of a real-time virtualization technology that maps the radio signals from one RRH to any BBU processing entity in the BBU pool and vice versa is made possible by placing multiple BBUs in a central physical pool and using RF strategies to distribute the RRH [29, 144, 150].
Fig. 5

Minimalist overview of the C-RAN architecture based on the reference study in [49]. The architecture consists of the virtual BS pools that communicate via X2 interfaces, the optical transport network that connects the wireless front end (RRUs and UEs) with the base band unit (this diagram was recreated based on the original reference by using

5G is envisioned to ensure higher capacity, extremely low network latency, and better energy efficiency allowing to accommodate a greater number of devices and traffic, as well as facilitate a large number of use cases such as machine type communication for IoT, beam forming, hotspots, and small cells along with fronthaul and backhaul [90].

5.1.1 Cloud-RAN and 5G

The authors in [144] discuss the need of C-RAN in various scenarios of 5G network, mainly with the user dense network and the multiple radio access technologies. The study focuses on the flexible backhauling, automated network organization, and advanced mobility management. Thanks to the flexibility and scalability of a cloud-based implementation, as well as its inherent centralization nature, C-RAN can facilitate the fifth generation (5G) communication technologies such as full duplex, ultra-dense networks, and large-scale antenna systems. C-RAN allows the spectrum and BBU resources to be shared by various heterogeneous networks. This simplifies the handover in mobile VNs because the virtual BS is located in a centralized BBU [70].

Large-scale cooperative signal processing in the physical layer is a complex requirement of 5G networks which makes it important to have significant and advanced computation. The advancement in RF and baseband are required to adapt to new air interfaces. In order to enable efficient use of ultra dense radio nodes, advancement in the integrated access, and heterogeneous convergence is required. There should be seamless integration of software-defined air interface technologies into the 5G radio access network architectures [108]. C-RAN has emerged as one of the 5G-oriented solutions to steer the network architecture and control resources. Decoupling of the traffic management operations from the radio access technologies has led to the combination of the virtualized network core and fronthaul architecture [7].

The authors in [108] list the following advantages of C-RAN, from which the 5G network can benefit: (1) achieve higher system capacity and lower power consumption by moving RRHs closer to the users, thus eliminating the need to propagate over long distances to reach users; (2) cooperative processing techniques can be leveraged to handle interfaces, because the centralized baseband processing at the BBU pool; and (3) integration of C-RAN architecture with SDN and NFV technologies provides the necessary functionality of scalability and flexibility that are required for the development of future mobile networks under a 5G communications [144].

6 Conclusions

Cloud networking has evolved over the years while significant advancements have been witnessed in network planning, design, control, and management. These changes were necessary to meet the ever growing needs of the on demand service requests. In order to allow organizations to take full advantage of benefits like scalability, flexibility, and efficiency, there has been an obvious need for cost-effective transition from vendor-specific hardware-based network functionalities to the deployment of software-defined network functions. This transition enables the reduction in cost of operations and infrastructure, which plays a major role in the future of networking.

In this paper, we have mainly discussed some of the architectural challenges and solutions to overcome these challenges seen in todays leading cloud communication technologies such as software-defined networking (SDN), network function virtualization (NFV), SDN-enabled NFV solutions, and cloud radio access networks (C-RAN).

Some of the concerning challenges such as security, scalability, resilience, high availability, performance, isolation, switch design, controller placement, and manageability are identified along with their corresponding solutions particularly for SDN, NFV, and SDN-NFV integration. Indeed, we have further pointed out and discussed open issues, challenges, and opportunities despite the existing solutions on these concepts. Therefore, the solutions that have been proposed to overcome the reported challenges also introduce unaddressed issues that lead to opportunities for future research. In the end of the paper, we have provided a brief architectural design and understanding of the cloudRAN technology that uses the integrated SDN-NFV that can be enabled to achieve efficient and cost effective means of 5G wireless networks.



We would like to thank the authors of the references in [25, 49, 58, 149] for giving us their consent to redraw the corresponding figures in those references. In addition, we would like to acknowledge ETSI for the specification in [39] which formed the basis for Fig. 3 in this article.

Funding Information

This work was supported in part by the Natural Sciences and Engineering Research Council of Canada (NSERC) under Grant RGPIN/2017-04032.


  1. 1.
    Amazon - ELB [online] Accessed 12 Jan. 2018
  2. 2.
    Nakao A (2012) Invited talk: Deeply Programmable Network (DPN) through Advanced Network Virtualization. International Symposium on Network Virtualization, Kyoto. Available Online: Google Scholar
  3. 3.
    (2004) Data center : Load balancing data center [online]
  4. 4.
    Agarwal K, Dixon C, Rozner E, Carter J (2014) Shadow macs: scalable label-switching for commodity ethernet. In: Proceedings of the third workshop on hot topics in software defined networking, hotSDN ’14. ACM, New York, pp 157–162Google Scholar
  5. 5.
    Agrawal R, Bedekar A, Kalyanasundaram S, Kolding T, Kroener H, Ram V (2016) Architecture principles for cloud ran. In: IEEE 83Rd vehicular technology conference (VTC spring), pp 1–5Google Scholar
  6. 6.
    Akyildiz IF, Lee A, Wang P, Luo M, Chou W (2014) A roadmap for traffic engineering in software defined networks. Comput Netw 71:1–30CrossRefGoogle Scholar
  7. 7.
    Al-Dulaimi A, Anpalagan A, Bennis M, Vasilakos AV (2015) 5g green communications: C-ran provisioning of comp and femtocells for power management. In: IEEE International conference on ubiquitous wireless broadband (ICUWB), pp 1–5Google Scholar
  8. 8.
    Ali ST, Sivaraman V, Radford A, Jha S (2013) Securing networks using software defined networking: a survey. IEEE Trans Reliab 64(3):1–12Google Scholar
  9. 9.
    Appelman M et al Performance analysis of OpenFlow hardware.
  10. 10.
    Araujo JT, Landa R, Clegg RG, Pavlou G (2014) Software-defined network support for transport resilience. In: IEEE Network operations and management symposium (NOMS), pp 1–8Google Scholar
  11. 11.
    Atiewi S, Yussof S (2014) Comparison between cloud SIM and green cloud in measuring energy consumption in a cloud environment. In: 2014 3rd international conference on advanced computer science applications and technologies, pp 9–14Google Scholar
  12. 12.
    Bannour F, Souihi S, Mellouk A (2017) Distributed SDN control: survey, taxonomy and challenges. IEEE Commun Surv Tutorials PP(99):1–1Google Scholar
  13. 13.
    Banzai T, Koizumi H, Kanbayashi R, Imada T, Hanawa T, Sato M (2010) D-cloud: design of a software testing environment for reliable distributed systems using cloud computing technology. In: 2010 10Th IEEE/ACM international conference on cluster, cloud and grid computing, pp 631–636Google Scholar
  14. 14.
    Bari MF, Boutaba R, Esteves R, Granville LZ, Podlesny M, Rabbani MG, Zhang Q, Zhani MF (2013) Data center network virtualization: a survey. IEEE Commun Surv Tutorials 15(2):909–928CrossRefGoogle Scholar
  15. 15.
    Benton K, Camp LJ, Small C (2013) OpenFlow vulnerability assessment. In: Proceedings of the second ACM SIGCOMM workshop on hot topics in software defined networking, hotSDN ’13. ACM, New York, pp 151–152Google Scholar
  16. 16.
    Berde P, Gerola M, Hart J, Higuchi Y, Kobayashi M, Koide T, Lantz B, O’Connor B, Radoslavov P, Snow W, Parulkar G (2014) ONOS: towards an open, distributed SDN OS. In: Proceedings of the third workshop on hot topics in software defined networking, hotSDN ’14. ACM, New York, pp 1–6Google Scholar
  17. 17.
    Bhattacharya B, Das D (2013) SDN based architecture for QoS enabled services across networks with dynamic service level agreement. In: 2013 IEEE International conference on advanced networks and telecommunications systems (ANTS), pp 1–6Google Scholar
  18. 18.
    Botelho F, Bessani A, Ramos FMV, Ferreira P (2014) On the design of practical fault-tolerant SDN controllers. In: 2014 Third european workshop on software defined networks, pp 73–78Google Scholar
  19. 19.
    Botelho FA, Ramos FMV, Kreutz D, Bessani AN (2013) On the feasibility of a consistent and fault-tolerant data store for SDNs. In: 2013 Second european workshop on software defined networks, pp 38–43Google Scholar
  20. 20.
    Boutaba R, Fonseca N, Kliazovich D, Limam N (2015) Cloud networking and communications II. Comput Netw 93:405–407CrossRefGoogle Scholar
  21. 21.
    Braun W, Menth M (2014) Wildcard compression of inter-domain routing tables for OpenFlow-based software-defined networking. In: 2014 Third european workshop on software defined networks, pp 25–30Google Scholar
  22. 22.
    Cai Z, Cox AL, Ng TSE Maestro: a system for scalable openflow control. Rice University Technical Report TR10-11Google Scholar
  23. 23.
    Calheiros RN, Ranjan R, Beloglazov A, De Rose CAF, Buyya R (2011) CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Softw Pract Exper 41(1):23–50CrossRefGoogle Scholar
  24. 24.
    Cannistra R, Carle B, Johnson M, Kapadia J, Meath Z, Miller M, Young D, DeCusatis C, Bundy T, Zussman G, Bergman K, Carranza A, Sher-DeCusatis C, Pletch A, Ransom R (2014) Enabling autonomic provisioning in SDN cloud networks with NFV service chaining. In: OFC 2014, pp 1–3Google Scholar
  25. 25.
    Carapinha J, Jiménez J (2009) Network virtualization: a view from the bottom. In: Proceedings of the 1st ACM workshop on Virtualized infrastructure systems and architectures, pp 73–80Google Scholar
  26. 26.
    Casado M, Foster N, Guha A (2014) Abstractions for software-defined networks. Commun ACM 57 (10):86–95CrossRefGoogle Scholar
  27. 27.
    Casado M, Freedman MJ, Pettit J, Luo J, McKeown N, Shenker S (2007) Ethane: taking control of the enterprise. SIGCOMM Comput Commun Rev 37(4):1–12CrossRefGoogle Scholar
  28. 28.
    Chandrasekaran B, Benson T (2014) Tolerating SDN application failures with legosdn. In: Proceedings of the third workshop on hot topics in software defined networking, hotSDN ’14. ACM, New York, pp 235–236Google Scholar
  29. 29.
    Checko A, Christiansen HL, Yan Y, Scolari L, Kardaras G, Berger MS, Dittmann L (2015) Cloud RAN for mobile networks—a technology overview. IEEE Commun Surv Tutorials 17(1):405–426CrossRefGoogle Scholar
  30. 30.
    Chen J, Zheng X, Rong C (2015) Survey on software-defined networking. In: Qiang W, Zheng X, Hsu CH (eds) Cloud computing and big data. Springer International Publishing, Cham, pp 115–124Google Scholar
  31. 31.
    Chowdhury N, Boutaba R (2009) Network virtualization: state of the art and research challenges. Communications Magazine IEEE 47(7):20–26CrossRefGoogle Scholar
  32. 32.
    Chowdhury NMK, Boutaba R (2010) A survey of network virtualization. Comput Netw 54(5):862–876CrossRefzbMATHGoogle Scholar
  33. 33.
    Clayman S, Maini E, Galis A, Manzalini A, Mazzocca N (2014) The dynamic placement of virtual network functions. In: IEEE Network operations and management symposium (NOMS), pp 1–9Google Scholar
  34. 34.
    Cotroneo D, Simone LD, Iannillo AK, Lanzaro A, Natella R, Fan J, Ping W (2014) Network function virtualization: challenges and directions for reliability assurance. In: IEEE International symposium on software reliability engineering workshops, pp 37–42Google Scholar
  35. 35.
    Curtis AR, Mogul JC, Tourrilhes J, Yalagandula P, Sharma P, Banerjee S (2011) DevoFlow: scaling flow management for high-performance networks. SIGCOMM Comput Commun Rev 41(4):254–265CrossRefGoogle Scholar
  36. 36.
    Duan Q, Ansari N, Toy M (2016) Software-defined network virtualization: an architectural framework for integrating SDN and NFV for service provisioning in future networks. IEEE Netw 30(5):10–16CrossRefGoogle Scholar
  37. 37.
    El Ferkouss O, Snaiki I, Mounaouar O, Dahmouni H, Ali RB, Lemieux Y, Omar C (2011) A 100gig network processor platform for openflow. In: Proceedings of the 7th international conference on network and services management, CNSM ’11. International Federation for Information Processing, Laxenburg, pp 286–289Google Scholar
  38. 38.
    Emmerich P, Raumer D, Beifuß A, Erlacher L, Wohlfart F, Runge TM, Gallenmüller S, Carle G (2015) Optimizing latency and CPU load in packet processing systems. In: 2015 International symposium on performance evaluation of computer and telecommunication systems (SPECTS), pp 1–8Google Scholar
  39. 39.
    Fayazbakhsh SK, Sekar V, Yu M, Mogul JC (2013) FlowTags: enforcing network-wide policies in the presence of dynamic middlebox actions. In: Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking (HotSDN ’13). ACM, New York, pp 19–24Google Scholar
  40. 40.
    Fayazbakhsh SK, Chiang L, Sekar V, Yu M, Mogul JC (2014) Enforcing network-wide policies in the presence of dynamic middlebox actions using flowtags. In: Proceedings of the 11th USENIX conference on networked systems design and implementation, NSDI’14. USENIX Association, Berkeley, pp 533–546Google Scholar
  41. 41.
    Ferrazani Mattos DM, Duarte OCMB (2016) AuthFlow: authentication and access control mechanism for software defined networking. Ann Telecommun 71(11–12):607–615CrossRefGoogle Scholar
  42. 42.
    Fonseca P, Bennesby R, Mota E, Passito A (2012) A replication component for resilient OpenFlow-based networking. In: 2012 IEEE Network operations and management symposium, pp 933–939Google Scholar
  43. 43.
    Fujita H, Matsuno Y, Hanawa T, Sato M, Kato S, Ishikawa Y (2012) DS-Bench Toolset: tools for dependability benchmarking with simulation and assurance. In: IEEE/IFIP International conference on dependable systems and networks (DSN 2012), pp 1–8Google Scholar
  44. 44.
    Gember-Jacobson A, Viswanathan R, Prakash C, Grandl R, Khalid J, Das S, Akella A (2014) OpenNF: enabling innovation in network function control. In: Proceedings of the 2014 ACM conference on SIGCOMM, SIGCOMM ’14. ACM, New York, pp 163–174Google Scholar
  45. 45.
    Gesbert D, Kountouris M, Heath RW, Chae bC, Salzer T (2007) Shifting the MIMO paradigm. IEEE Signal Process Mag 24(5):36–46CrossRefGoogle Scholar
  46. 46.
    Goguen J (1999) An introduction to algebraic semiotics, with application to user interface design. In: Nehaniv CL (ed) Computation for metaphors, analogy, and agents. Springer Berlin Heidelberg, Berlin, pp 242–291Google Scholar
  47. 47.
    Gourov V, Gourova E (2015) Cloud network architecture design patterns. In: Proceedings of the 20th european conference on pattern languages of programs, euroPLop ’15. ACM, New York, pp 1:1–1:11Google Scholar
  48. 48.
    Greenberg A, Hamilton J, Maltz DA, Patel P (2009) The cost of a cloud : research problems in data center networks. ACM SIGCOMM Computer Communication Review 39(1):68–73CrossRefGoogle Scholar
  49. 49.
    Hadzialic M, Dosenovic B, Dzaferagic M, Musovic J (2013) Cloud-RAN: innovative radio access network architecture. In: Proceedings ELMAR-2013, pp 115–120Google Scholar
  50. 50.
    Hakiri A, Gokhale A, Berthou P, Schmidt DC, Gayraud T (2014) Software-defined networking: challenges and research opportunities for future internet. Comput Netw 75(PartA):453–471CrossRefGoogle Scholar
  51. 51.
    Han B, Gopalakrishnan V, Ji L, Lee S (2015) Network function virtualization: challenges and opportunities for innovations. IEEE Commun Mag 53(2):90–97CrossRefGoogle Scholar
  52. 52.
    Hassas Yeganeh S, Ganjali Y (2012) Kandoo: a framework for efficient and scalable offloading of control applications. In: Proceedings of the first workshop on hot topics in software defined networks, pp 19–24Google Scholar
  53. 53.
    Horvath R, Nedbal D, Stieninger M (2015) A literature review on challenges and effects of software defined networking. Procedia Computer Science 64:552–561CrossRefGoogle Scholar
  54. 54.
    Hoydis J, ten Brink S, Debbah M (2011) Massive MIMO: how many antennas do we need? CoRR arXiv:1107.1709
  55. 55.
    Hu F, Hao Q, Bao K (2014) A survey on software defined networking (SDN) and OpenFlow: from concept to implementation. IEEE Commun Surv Tutorials 16(c):1–1Google Scholar
  56. 56.
    Hu F, Qiu M, Li J, Grant T, Tylor D, McCaleb S, Butler L, Hamner R (2011) A review on cloud computing: design challenges in architecture and security. J Comput Inf Technol 19(1):25– 55CrossRefGoogle Scholar
  57. 57.
    Hwang K (1992) Advanced computer architecture: parallelism, scalability, programmability, 1st edn. McGraw-Hill Higher Education, New YorkGoogle Scholar
  58. 58.
    Kreutz D, Ramos FMV, Veríssimo PE, Rothenberg CE, Azodolmolky S, Uhlig S (2015) Software-defined networking: a comprehensive survey. In: Proceedings of the IEEE, vol 103, no. 1, pp 14–76Google Scholar
  59. 59.
    Ismail MA, Ismail MF, Ahmed H (2015) Openstack cloud performance optimization using linux services. In: 2015 International conference on cloud computing (ICCC), pp 1–4Google Scholar
  60. 60.
    Jafarian JH, Al-Shaer E, Duan Q (2012) OpenFlow random host mutation: transparent moving target defense using software defined networking. In: Proceedings of the first workshop on hot topics in software defined networks, hotSDN ’12. ACM, New York, pp 127–132Google Scholar
  61. 61.
    Jain R, Paul S (2013) Network virtualization and software defined networking for cloud computing: a survey. IEEE Commun Mag 51(11):24–31CrossRefGoogle Scholar
  62. 62.
    Jennings B, Stadler R (2015) Resource management in clouds: survey and research challenges. J Netw Syst Manag 23(3):567–619CrossRefGoogle Scholar
  63. 63.
    Jensen M, Schwenk J, Gruschka N, Iacono LL (2009) On technical security issues in cloud computing. In: 2009 IEEE International conference on cloud computing, pp 109–116Google Scholar
  64. 64.
    Joshi P, Gunawi HS, Sen K (2011) Prefail: a programmable tool for multiple-failure injection. SIGPLAN Not 46(10):171–188CrossRefGoogle Scholar
  65. 65.
    Kantarci B, Mouftah HT (2012) Designing an energy-efficient cloud network [Invited]. J Opt Commun Networking 4(11):B101CrossRefGoogle Scholar
  66. 66.
    Kaur T, Chana I (2015) Energy efficiency techniques in cloud computing: a survey and taxonomy. ACM Comput Surv 48(2):1–46CrossRefGoogle Scholar
  67. 67.
    Keeney J, Meer vdS, Fallon L (2014) Towards real-time management of virtualized telecommunication networks. In: 10Th international conference on network and service management (CNSM) and workshop, pp 388–393Google Scholar
  68. 68.
    Kim J, Dally WJ, Abts D (2007) Flattened butterfly: a cost-efficient topology for high-radix networks. SIGARCH Comput Archit News 35(2):126–137CrossRefGoogle Scholar
  69. 69.
    Kirkpatrick K (2013) Software-defined networking. Commun ACM 56(9):16CrossRefGoogle Scholar
  70. 70.
    Kitindi EJ, Fu S, Jia Y, Kabir A, Wang Y (2017) Wireless network virtualization with SDN and C-RAN for 5g networks: requirements, opportunities, and challenges. IEEE Access 5:19,099–19,115CrossRefGoogle Scholar
  71. 71.
    Kliazovich D, Bouvry P, Khan SU (2012) GreenCloud: a packet-level simulator of energy-aware cloud computing data centers. J Supercomput 62(3):1263–1283CrossRefGoogle Scholar
  72. 72.
    Koponen T, Amidon K, Balland P, Casado M, Chanda A, Fulton B, Ganichev I, Gross J, Gude N, Ingram P, Jackson E, Lambeth A, Lenglet R, Li SH, Padmanabhan A, Pettit J, Pfaff B, Ramanathan R, Shenker S, Shieh A, Stribling J, Thakkar P, Wendlandt D, Yip A, Zhang R (2014) Network virtualization in multi-tenant datacenters. In: Proceedings of the 11th USENIX conference on networked systems design and implementation, NSDI’14. USENIX Association, Berkeley, pp 203–216Google Scholar
  73. 73.
    Koponen T, Casado M, Gude N, Stribling J, Poutievski L, Zhu M, Ramanathan R, Iwata Y, Inoue H, Hama T, Others, Shenker S (2010) Onix: A distributed control platform for large-scale production networks. OSDI, Oct pp 1–6Google Scholar
  74. 74.
    Krautheim FJ (2009) Private virtual infrastructure for cloud computing. In: Proceedings of the 2009 conference on Hot topics in cloud computing (HotCloud’09). USENIX Association, BerkeleyGoogle Scholar
  75. 75.
    Kreutz D, Esteves-Verissimo P, Magalhaes C, Ramos FMV (2017) The KISS principle in software-defined networking: an architecture for keeping it simple and secureGoogle Scholar
  76. 76.
    Lal S, Taleb T, Dutta A (2017) NFV: security threats and best practices. IEE Commun Mag 55 (8):211–217CrossRefGoogle Scholar
  77. 77.
    Lam CF (2010) Optical network technologies for datacenter networks (invited paper). In: 2010 Conference on optical fiber communication (OFC/NFOEC), collocated national fiber optic engineers conference, pp 1–3Google Scholar
  78. 78.
    Laoutaris N, Sirivianos M, Yang X, Rodriguez P (2011) Inter-datacenter bulk transfers with netstitcher. SIGCOMM Comput Commun Rev 41(4):74–85CrossRefGoogle Scholar
  79. 79.
    Li W, Meng W, Kwok LF (2016) A survey on OpenFlow-based software defined networks: security challenges and countermeasures. J Netw Comput Appl 68:126–139CrossRefGoogle Scholar
  80. 80.
    Li Y, Chen MIN, Member S (2015) Software-defined network function virtualization : a survey. IEEE Access 3Google Scholar
  81. 81.
    Lombardo A, Manzalini A, Schembra G, Faraci G, Rametta C, Riccobene V (2015) An open framework to enable NetFATE (Network Functions at the edge). In: Proceedings of the 2015 1st IEEE Conference on Network Softwarization (NetSoft), London, pp 1–6Google Scholar
  82. 82.
    Lorenz C, Hock D, Scherer J, Durner R, Kellerer W, Gebert S, Gray N, Zinner T, Tran-gia P (2017) An SDN/NFV-enabled enterprise network architecture offering fine-grained security policy enforcement. IEEE Commun Mag 55(3):217–223CrossRefGoogle Scholar
  83. 83.
    Luo Y, Cascon P, Murray E, Ortega J (2009) Accelerating OpenFlow switching with network processors. In: Proceedings of the 5th ACM/IEEE symposium on architectures for networking and communications systems, ANCS ’09. ACM, New York, pp 70–71Google Scholar
  84. 84.
    Ma YW, Chen YC, Chen JL (2017) SDN-enabled network virtualization for industry 4.0 based on IoTs and cloud computing. In: 2017 19Th international conference on advanced communication technology (ICACT), pp 199–202Google Scholar
  85. 85.
    Martins J, Ahmed M, Raiciu C, Olteanu V, Honda M, Bifulco R, Huici F (2014) ClickOS and the art of network function virtualization. In: Proceedings of the 11th USENIX conference on networked systems design and implementation, NSDI’14. USENIX Association, Berkeley, pp 459–473Google Scholar
  86. 86.
    Masoudi R, Ghaffari A (2016) Software defined networks: a survey. J Netw Comput Appl 67:1–25CrossRefGoogle Scholar
  87. 87.
    Mastelic T, Oleksiak A, Claussen H, Brandic I, Pierson JM, Vasilakos AV (2014) Cloud computing: survey on energy efficiency. ACM Comput Surv 47(2):33:1–33:36CrossRefGoogle Scholar
  88. 88.
    Matias J, Garay J, Mendiola A, Toledo N, Jacob E (2014) Flownac: flow-based network access control. In: Proceedings of the 2014 third european workshop on software defined networks, EWSDN ’14. IEEE Computer Society, Washington, pp 79–84Google Scholar
  89. 89.
    Matias J, Garay J, Toledo N, Unzilla J, Jacob E (2015) Toward an SDN-enabled NFV architecture. IEEE Commun Mag 53(4):187–193CrossRefGoogle Scholar
  90. 90.
    Mattisson S (2017) Overview of 5g requirements and future wireless networks. In: ESSCIRC 2017 - 43Rd IEEE european solid state circuits conference, pp 1–6Google Scholar
  91. 91.
    McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J (2008) OpenFlow: enabling innovation in campus networks. SIGCOMM Comput Commun Rev 38 (2):69–74CrossRefGoogle Scholar
  92. 92.
    Mehraghdam S, Keller M, Karl H (2014) Specifying and placing chains of virtual network functions. CoRR arXiv:1406.1058
  93. 93.
    Mekky H, Hao F, Mukherjee S, Lakshman TV, Zhang ZL (2017) Network function virtualization enablement within SDN data plane. In: IEEE INFOCOM 2017 - IEEE Conference on computer communications, pp 1–9Google Scholar
  94. 94.
    Memon G, Varvello M, Laufer R, Lakshman T, Li J, Zhang M (2013) Flashflow: a GPU-based fully programmable OpenFlow switch. Tech. rep., University of OregonGoogle Scholar
  95. 95.
    Mijumbi R, Serrat J, Gorricho JL, Bouten N, De Turck F, Boutaba R (2016) Network function virtualization: state-of-the-art and research challenges. In: IEEE communications surveys & tutorials. Firstquarter, vol 18, no. 1, pp 236–262Google Scholar
  96. 96.
    Mogul JC, AuYoung A, Banerjee S, Popa L, Lee J, Mudigonda J, Sharma P, Turner Y (2013) Corybantic: towards the modular composition of SDN control programs. In: Proceedings of the twelfth ACM workshop on hot topics in networks, hotnets-XII. ACM, New York, pp 1:1–1:7Google Scholar
  97. 97.
    Monsanto C, Reich J, Foster N, Rexford J, Walker D (2013) Composing software-defined networks. In: Proceedings of the 10th USENIX conference on networked systems design and implementation, nsdi’13. USENIX Association, Berkeley, pp 1–14Google Scholar
  98. 98.
    Moura J, Hutchison D (2016) Review and analysis of networking challenges in cloud computing. J Netw Comput Appl 60:113–129CrossRefGoogle Scholar
  99. 99.
    Muṅoz R., Vilalta R, Casellas R, Martinez R, Szyrkowiec T, Autenrieth A, Lõpez V, Lõpez D (2015) Integrated SDN/NFV management and orchestration architecture for dynamic deployment of virtual SDN control instances for virtual tenant networks [Invited]. J Opt Commun Networking 7(11):B62CrossRefGoogle Scholar
  100. 100.
    Mustafiz S, Palma F, Toeroe M, Khendek F (2016) A network service design and deployment process for NFV systems. In: IEEE 15Th international symposium on network computing and applications (NCA), pp 131–139Google Scholar
  101. 101.
    Nadas S (2010) Virtual router redundancy protocol (VRRP) version 3 for IPv4 and IPv6. RFC 5798.
  102. 102.
    Naous J, Erickson D, Covington GA, Appenzeller G, McKeown N (2008) Implementing an openflow switch on the NetFPGA platform. In: Proceedings of the 4th ACM/IEEE symposium on architectures for networking and communications systems, ANCS ’08. ACM, New York, pp 1–9Google Scholar
  103. 103.
    Nunes BAA, Mendonca M, Nguyen XN, Obraczka K, Turletti T (2014) A survey of software-defined networking: past, present, and future of programmable networks. IEEE Commun Surv Tutorials 16(3):1617–1634CrossRefGoogle Scholar
  104. 104.
    (2013) Open networking foundation: SDN architecture overview. Onf (1), 1–5Google Scholar
  105. 105.
    Park SH, Lee B, Shin J, Yang S (2014) A high-performance IO engine for SDN controllers. In: 2014 third european workshop on software defined networks, Budapest, pp 121–122Google Scholar
  106. 106.
    Park SH, Lee B, You J, Shin J, Kim T, Yang S (2014) Raon: recursive abstraction of OpenFlow networks. In: 2014 Third european workshop on software defined networks, pp 115–116Google Scholar
  107. 107.
    Peleg D (2000) Distributed computing: a Locality-Sensitive approach society for industrial and applied mathematicsGoogle Scholar
  108. 108.
    Peng M, Li Y, Zhao Z, Wang C (2015) System architecture and key technologies for 5G heterogeneous cloud radio access networks. IEEE Network 29(2):6–14CrossRefGoogle Scholar
  109. 109.
    Pham C, Chen D, Kalbarczyk Z, Iyer RK (2011) Cloudval: a framework for validation of virtualization environment in cloud infrastructure. In: 2011 IEEE/IFIP 41St international conference on dependable systems networks (DSN), pp 189–196Google Scholar
  110. 110.
    Piraghaj SF, Dastjerdi AV, Calheiros RN, Buyya R (2017) ContainerCloudSim: an environment for modeling and simulation of containers in cloud data centers. Software: Practice and Experience 47(4):505–521Google Scholar
  111. 111.
    Pongrácz G, Molnár L, Kis ZL (2013) Removing roadblocks from SDN: OpenFlow software switch performance on intel dpdk. In: Proceedings of the 2013 second european workshop on software defined networks, EWSDN ’13. IEEE Computer Society, Washington, pp 62–67Google Scholar
  112. 112.
    Porras P, Cheung S, Fong M, Skinner K, Yegneswaran V (2015) Securing the software-defined network control layer. In: Proceedings of the 2015 network and distributed system security symposium (NDSS)Google Scholar
  113. 113.
    Porras P, Shin S, Yegneswaran V, Fong M, Tyson M, Gu G (2012) A security enforcement kernel for OpenFlow networks. In: Proceedings of the first workshop on hot topics in software defined networks, hotSDN ’12. ACM, New York, pp 121–126Google Scholar
  114. 114.
    Rad BB, Diaby T, Rana ME (2017) Cloud computing adoption: a short review of issues and challenges. In: Proceedings of the 2017 international conference on e-commerce, e-business and e-government, ICEEG 2017. ACM, New York, pp 51–55Google Scholar
  115. 115.
    Ramos RM, Martinello M, Rothenberg CE (2013) Slickflow: resilient source routing in data center networks unlocked by openflow. In: 38Th annual IEEE conference on local computer networks, pp 606–613Google Scholar
  116. 116.
    Rauen ZI, Kantarci B, Mouftah HT (2017) Resiliency versus energy sustainability in optical inter-datacenter networks. Opt Switch Netw 23:144–155CrossRefGoogle Scholar
  117. 117.
    Rawat DB, Reddy SR (2017) Software defined networking architecture, security and energy efficiency: a survey. IEEE Commun Surv Tutorials 19(1):325–346CrossRefGoogle Scholar
  118. 118.
    Rehman RU (2003) Introduction to intrusion detection and snortGoogle Scholar
  119. 119.
    Reynaud F, Aguessy FX, Bettan O, Bouet M, Conan V (2016) Attacks against network functions virtualization and software-defined networking: state-of-the-art. In: 2016 IEEE NetSoft Conference and Workshops (NetSoft), Seoul, pp 471–476Google Scholar
  120. 120.
    Rostami A, Jungel T, Koepsel A, Woesner H, Wolisz A (2012) Oran: OpenFlow routers for academic networks. In: 2012 IEEE 13Th international conference on high performance switching and routing, pp 216–222Google Scholar
  121. 121.
    Rudell RL, Sangiovanni-Vincentelli A (1987) Multiple-valued minimization for PLA optimization. IEEE Trans Comput Aided Des Integr Circuits Syst 6(5):727–750CrossRefGoogle Scholar
  122. 122.
    Santos N, Gummadi KP, Rodrigues R (2009) Towards trusted cloud computing. In: Proceedings of the 2009 conference on hot topics in cloud computing, hotcloud’09. USENIX association, BerkeleyGoogle Scholar
  123. 123.
    Schehlmann L, Baier H (2013) COFFEE: a concept based on OpenFlow to filter and erase events of botnet activity at high-speed nodes. GI-Jahrestagung pp 2225–2239Google Scholar
  124. 124.
    Schmid S, Suomela J (2013) Exploiting locality in distributed SDN control. In: Proceedings of the second ACM SIGCOMM workshop on hot topics in software defined networking (HotSDN ’13). ACM, New York, pp 121–126Google Scholar
  125. 125.
    Schöller M, Stiemerling M, Ripke A, Bless R (2013) Resilient deployment of virtual network functions. In: 2013 5Th international congress on ultra modern telecommunications and control systems and workshops (ICUMT), pp 208–214Google Scholar
  126. 126.
    Scott-Hayward Sa, Natarajan Sb, Sezer SA (2016) Survey of security in software defined networks. Surv Tutorials 18(1):623–654CrossRefGoogle Scholar
  127. 127.
    Seeber S, Rodosek GD (2015) Towards an adaptive and effective IDS using OpenFlow. Springer International Publishing, Switzerland, pp 134–139Google Scholar
  128. 128.
    Shah H, Wankhede P, Borkar A (2013) Challenges in cloud environment. In: Patnaik S, Tripathy P, Naik S (eds) New paradigms in internet computing. Advances in intelligent systems and computing, vol 203. Springer, BerlinGoogle Scholar
  129. 129.
    Shamugam V, Murray I, Leong JA, Sidhu AS (2016) Software defined networking challenges and future direction: a case study of implementing SDN features on openstack private cloud. IOP Conference Series: Materials Science and Engineering 121(1):012,003CrossRefGoogle Scholar
  130. 130.
    Shen W, Yoshida M, Kawabata T, Minato K, Imajuku W (2014) vConductor: an NFV management solution for realizing end-to-end virtual network services. In: The 16th asia-pacific network operations and management symposium, pp 1–6Google Scholar
  131. 131.
    Shin S, Song Y, Lee T, Lee S, Chung J, Porras P, Yegneswaran V, Noh J, Kang BB (2014) Rosemary: a robust, secure, and high-performance network operating system. In: Proceedings of the 2014 ACM SIGSAC conference on computer and communications security, CCS ’14. ACM, New York, pp 78–89Google Scholar
  132. 132.
    Shin S, Yegneswaran V, Porras P, Gu G (2013) Avant-guard: scalable and vigilant switch flow management in software-defined networks. In: Proceedings of the ACM SIGSAC conference on computer & communications security, CCS ’13. ACM, New York, pp 413–424Google Scholar
  133. 133.
    Shirali-Shahreza S, Ganjali Y (2013) Efficient implementation of security applications in Openflow controller with FleXam. In: 2013 IEEE 21st annual symposium on high-performance interconnects, San Jose, CA, pp 49–54Google Scholar
  134. 134.
    Soares J, Dias M, Carapinha J, Parreira B, Sargento S (2014) Cloud4nfv: a platform for virtual network functions. In: 2014 IEEE 3Rd international conference on cloud networking (cloudnet), pp 288–293Google Scholar
  135. 135.
    Soares J, Goncalves C, Parreira B, Tavares P, Carapinha J, Barraca JP, Aguiar RL, Sargento S (2015) Toward a telco cloud environment for service functions. IEEE Commun Mag 53(2):98–106CrossRefGoogle Scholar
  136. 136.
    Subashini S, Kavitha V (2011) Review: a survey on security issues in service delivery models of cloud computing. J Netw Comput Appl 34(1):1–11CrossRefGoogle Scholar
  137. 137.
    Szabo R, Kind M, Westphal FJ, Woesner H, Jocha D, Csaszar A (2015) Elastic network functions: opportunities and challenges. IEEE Netw 29(3):15–21CrossRefGoogle Scholar
  138. 138.
    Tootoonchian A, Gorbunov S, Ganjali Y, Casado M, Sherwood R (2012) On controller performance in software-defined networks. In: Proceedings of the 2nd USENIX conference on hot topics in management of internet, cloud, and enterprise networks and services, hot-ICE’12. USENIX Association, Berkeley, pp 10–10Google Scholar
  139. 139.
    Tseitlin A (2013) The antifragile organization embracing failure to improve resilience and maximize availability. ACM Queue 11(6):1–7Google Scholar
  140. 140.
    Varghese B, Buyya R (2018) Next generation cloud computing: new trends and research directions. Futur Gener Comput Syst 79:849–861CrossRefGoogle Scholar
  141. 141.
    Veitch P, McGrath MJ, Bayon V (2015) An instrumentation and analytics framework for optimal and robust NFV deployment. IEEE Commun Mag 53(2):126–133CrossRefGoogle Scholar
  142. 142.
    Wang B, Qi Z, Ma R, Guan H, Vasilakos AV (2015) A survey on data center networking for cloud computing. Comput Netw 91:528–547CrossRefGoogle Scholar
  143. 143.
    Wang R, Butnariu D, Rexford J (2011) Openflow-based server load balancing gone wild. In: Proceedings of the 11th USENIX conference on hot topics in management of internet, cloud, and enterprise networks and services, hot-ICE’11. USENIX Association, Berkeley, pp 12–12Google Scholar
  144. 144.
    Wang R, Hu H, Yang X (2014) Potentials and challenges of c-RAN supporting multi-RATs toward 5G mobile networks. IEEE Access 2:1200–1208Google Scholar
  145. 145.
    Wanner L, Srivastava M (2014) Virus: Virtual function replacement under stress. In: Proceedings of the 6th USENIX conference on power-aware computing and systems, hotpower’14. USENIX Association, Berkeley, pp 2–2Google Scholar
  146. 146.
    Wen X, Chen Y, Hu C, Shi C, Wang Y (2013) Towards a secure controller platform for openflow applications. In: Proceedings of the second ACM SIGCOMM workshop on hot topics in software defined networking, hotSDN ’13. ACM, New York, pp 171–172Google Scholar
  147. 147.
    Wippel H (2014) Dpdk-based implementation of application-tailored networks on end user nodes. In: 2014 International conference and workshop on the network of the future (NOF), pp 1–5Google Scholar
  148. 148.
    Wood T, Gerber A, Ramakrishnan KK, Shenoy P, Van der Merwe J (2009) The case for enterprise-ready virtual private clouds. In: Proceedings of the 2009 conference on hot topics in cloud computing, hotcloud’09. USENIX association, BerkeleyGoogle Scholar
  149. 149.
    Wood T, Ramakrishnan KK, Hwang J, Liu G, Zhang W (2015) Toward a software-based network: Integrating software defined networking and network function virtualization. IEEE Network 29(3):36–41CrossRefGoogle Scholar
  150. 150.
    Wu J, Zhang Z, Hong Y, Wen Y (2015) Cloud radio access network (c-RAN): a primer. IEEE Network 29(1):35–41CrossRefGoogle Scholar
  151. 151.
    Xia M, Shirazipour M, Zhang Y, Green H, Takacs A (2015) Network function placement for nfv chaining in packet/optical datacenters. J Light Technol 33(8):1565–1570CrossRefGoogle Scholar
  152. 152.
    Yang W, Fung C (2016) A survey on security in network functions virtualization. In: IEEE NETSOFT 2016 - 2016 IEEE NetSoft conference and workshops: Software-defined infrastructure for networks, clouds, IoT and services, pp 15–19Google Scholar
  153. 153.
    Yao G, Bi J, Xiao P (2011) Source address validation solution with openflow/nox architecture. In: 2011 19Th IEEE international conference on network protocols, pp 7–12Google Scholar
  154. 154.
    Yeganeh SH, Tootoonchian A, Ganjali Y (2013) On Scalability of Software Defined Networking. IEEE Commun Mag 13(February):136–141CrossRefGoogle Scholar
  155. 155.
    Yoshida M, Shen W, Kawabata T, Minato K, Imajuku W (2014) Morsa: a multi-objective resource scheduling algorithm for nfv infrastructure. In: The 16th asia-pacific network operations and management symposium, pp 1–6Google Scholar
  156. 156.
    Yu M, Rexford J, Freedman MJ, Wang J (2010) Scalable flow-based networking with DIFANE. SIGCOMM Comput Commun Rev 41(4)Google Scholar
  157. 157.
    Yu M, Wundsam A, Raju M (2014) NOSIX: a lightweight portability layer for the SDN OS. SIGCOMM Comput Commun Rev 44(2):28–35CrossRefGoogle Scholar
  158. 158.
    Zhang Q, Cheng L, Boutaba R (2010) Cloud computing: state-of-the-art and research challenges. Journal of Internet Services and Applications 1(1):7–18CrossRefGoogle Scholar

Copyright information

© Institut Mines-Télécom and Springer International Publishing AG, part of Springer Nature 2018

Authors and Affiliations

  1. 1.The School of Electrical Engineering and Computer ScienceUniversity of OttawaOttawaCanada

Personalised recommendations