Service provision within the communications industry has traditionally been based on network operators deploying physical proprietary devices and equipment for each function that is part of a given service. In addition, service components have strict chaining and/or ordering that must be reflected in the network topology and in the localization of service elements. These, coupled with requirements for high quality, stability and stringent protocol adherence, have led to long product cycles, very low service agility and heavy dependence on specialized hardware. In addition, the traffic that networks must carry continues to increase, requiring SPs to continuously purchase, store and operate new physical equipment. This does not only require high and rapidly changing skills for technicians operating and managing this equipment, but also requires dense deployments of network equipment such as base stations. Moreover, as networks become bigger and complex, so does the requirements on network management and configuration. All these have led to high CAPEX and OPEX for SPs, reduced ARPU, and hence led to lower profitability. Software Defined Networking (SDN) and Network Functions Virtualization (NFV) have been proposed as possible solutions to these problems.

Challenges

However both NFV and SDN are relatively new technologies in early stages of development. There are still challenges and work to be done before the anticipated gains can be realised in form of real deployments. Challenges include: For NFV: management and orchestration, inter-operability, security in cloud, performance, energy efficiency, resource allocation; for SDN: controller design and architectures, solution scalability, abstractions, and programming languages and paradigms, etc.

Introduction to NFV

NFV leverages virtualization technology to offer a new way to design, deploy and manage networking services. The main idea of NFV is the decoupling of physical network equipment from the functions that run on them. This means that a network function - such as a firewall - can be dispatched to a TSP as an instance of plain software. This allows for the consolidation of many network equipment types onto high volume servers, switches and storage, which could be located in data centres, distributed network nodes and at end user premises. This way, a given service can be decomposed into a set of Virtual Network Functions (VNFs), which could then be implemented in software running on one or more industry standard physical servers. The VNFs may then be relocated and instantiated at different network locations (e.g. aimed at introduction of a service targeting customers in a given geographical location) without necessarily requiring the purchase and installation of new hardware. NFV promises TSPs with more flexibility to further open up their network capabilities and services to users and other services, and the ability to deploy or support new network services faster and cheaper so as to realize better service agility. To achieve these benefits, NFV paves the way to a number of differences in the way network service provisioning is realized in comparison to current practice. In summary, these differences are as follows:
Decoupling software from hardware. As the network element is no longer a composition of integrated hardware and software entities, the evolution of both are independent of each other. This allows separate development timelines and maintenance for software and hardware.
Flexible network function deployment. The detachment of software from hardware helps reassign and share the infrastructure resources, thus together, hardware and software, can perform different functions at various times. This helps network operators deploy new network services faster over the same physical platform. Therefore, components can be instantiated at any NFV-enabled device in the network and their connections can be set up in a flexible way.
Dynamic scaling. The decoupling of the functionality of the network function into instantiable software components provides greater flexibility to scale the actual VNF performance in a more dynamic way and with finer granularity, for instance, according to the actual traffic for which the network operator needs to provision capacity.

Introduction to SDN

SDN proposes an important architecture for the management of large scale complex networks, which may require re-policing or re-configurations from time to time. This achieved by decoupling network control from forwarding. In particular, SDN promises to provide a multi-layer platform which encompasses programmability not only at the forwarding and control planes, but also at the transport layers below and orchestration and services layers above the data and control planes. This allows network control to become directly programmable via an open interface (e.g., ForCES, OpenFlow, etc) and the underlying infrastructure to become simple packet forwarding devices (the data plane) that can be programmed. Early SDN models focused primarily on moving the control plane out of the network elements
into controllers on the theory that the switching elements could remain simple, general-purpose, and cost-effective while at the same time allowing the control plane to rapidly evolve. A number of recent SDN models, on the other hand, include approaches in which control and data plane programmability works in concert with existing and future distributed control planes. According to the Open Network Foundation (ONF), SDN addresses the fact that the static architecture of conventional networks is ill-suited for the dynamic computing and storage needs of today's data centres, campuses, and carrier environments. The SDN architecture is:
Programmable. SDN makes network control directly programmable since control is decoupled from forwarding functions. This programmability can be used to automate network configuration in such a way that network administrators can run "SDN apps" that help to optimize particular services such as VoIP so as to ensure a high Quality-of-Experience (QoE) for phone calls.
Agile. Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs. This makes the network more agile since logic is now implemented in a software running on commodity hardware, which has shorter release cycles than device firmware.
Centrally managed. Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.
Open standards-based and vendor-neutral. When implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols

Relationship between SDN and NFV

NFV and SDN have a lot in common since they both advocate for a passage towards open software and standard network hardware. Specifically, in the same way that NFV aims at running NFs on industry standard hardware, the SDN control plane can be implemented as pure software running on industry standard hardware. In addition, both NFV and SDN seek to leverage automation and virtualization to achieve their respective goals. In fact, NFV and SDN may be highly complementary, and hence combining them in one networking solution may lead to greater value. For example, if it is able to run on a VM, an SDN controller may be implemented as part of a service chain. This means that the centralized control and management applications (such as load balancing, monitoring and traffic analysis) used in SDN can be realized, in part, as VNFs, and hence benefit from NFV's reliability and elasticity features. In the same way, SDN can accelerate NFV deployment by offering a flexible and automated way of chaining functions, provisioning and configuration of network connectivity and bandwidth, automation of operations, security and policy control.
However, SDN and NFV are different concepts, aimed at addressing different aspects of a software-driven networking solution. NFV aims at decoupling NFs from specialized hardware elements while SDN focuses on separating the handling of packets and connections from overall network control. As stated by the ONF in the description of the SDN architecture, the NFV concept differs from the virtualization concept as used in the SDN architecture. In the SDN architecture, virtualization is the allocation of abstract resources to particular clients or applications; in NFV, the goal is to abstract NFs away from dedicated hardware, for example to allow them to be hosted on server platforms in cloud data centres. It can be observed that the highest efforts in promoting and standardizing SDN is in data centre and cloud computing areas while telecom carriers are driving similar efforts for NFV. Finally, an important distinction is that while NFV can work on existing networks because it resides on servers and interacts with specific traffic sent to them, SDN requires a new network construct where the data and control planes are separate.