- NFV needs SDN to achieve its full potential
- These technologies will also significantly change business processes
- 2 uses for SDN are virtual backplane and service function chaining
To ensure network functions virtualization (NFV) achieves its maximum potential, the networks themselves must become as dynamic and programmable as virtualized network functions (VNFs). Software-defined networking (SDN), with its programmability and easy configuration, makes it a perfect match for the networking needs of rapidly changing NFV applications.
SDN primarily has been used in data center applications, however, and NFV needs a more robust solution. NFV infrastructure needs to support network functions across many geographical locations. It also needs to be a highly reliable, high performance solution that can interwork easily with legacy networks.
Why is SDN needed for NFV?
In the past, the network was semi-static. Changes had to be made manually, through command line interfaces or management systems. Manual changes were error prone, so only specially trained and dedicated experts were allowed to make carefully documented changes. Deploying a new network element meant following stringent procedures and rigid rules to avoid conflicts with existing installations. Even small changes could take weeks or months.
NFV and SDN significantly improve the process of enabling new services. SDN helps in this process by virtualizing networks in a way similar to server virtualization for compute and storage. SDN provides easy-to-use network abstractions with open northbound APIs, such as OpenStack® Neutron. This allows more people – as well as automated systems – to provision and configure networks. It also cuts response times down to minutes or seconds.
But the introduction of NFV and SDN goes beyond technology: it requires a change in mindset and procedures. Service providers need to accept a much higher level of autonomous behavior in their systems to enable network-wide changes to be made within minutes. This includes deploying VNFs, software upgrades to enable new features, service scaling, and realigning network resources.
Laying the network foundations for NFV
NFV introduces cloud practice into service provider networks. Network functions are virtualized and automated to run on a shared server infrastructure that provides the necessary compute, storage and network resources. Network functions are more demanding than most IT applications, however, which means NFV carries specific requirements, including:
- Dynamics and scalability. NFV infrastructures need to be dynamic. They must support highly scalable applications that can respond to changing service uptake. When a VNF scales or moves to a different location, the networks need to follow without manual intervention.
- Connectivity in a distributed environment. The primary role of the network in NFV — SDN or not — is to provide connectivity between VNF components (VNFCs). Most NFV applications require Layer 2 or Layer 3 connectivity. For some applications, Layer 1 and Layer 0 network control may also be needed (transport SDN). SDN networks provide:
- Static or dynamic IP addressing
- Floating IP addresses
- Middlebox services
While IT clouds strive to centralize and consolidate data centers, NFV nodes need to be carefully distributed throughout geographic coverage areas to guarantee performance and high availability, and to avoid unnecessary traffic backhaul to centralized data centers.
- Security. A high level of security from any external or internal attacker is a fundamental requirement of any carrier infrastructure. For example, connectivity should be restricted to those elements that are supposed to talk to each other, and only legitimate data traffic should be allowed (through firewalls and security groups). VNFs must be sufficiently isolated from any “noisy” neighbors for performance and security reasons.
- Legacy interworking. Introducing NFV will be a gradual process, taken in steps. Interworking with legacy networks will be critical to ensure uninterrupted services throughout the evolution to a fully NFV-based infrastructure.
- Capacity and reliable performance. VNFs often support high-performance data and media traffic. Sufficient bandwidth and packet throughput must be available, both across the wide area network and between the server network interface cards, hypervisors and virtual switches.
Network functions with real-time performance requirements are also sensitive to latency and jitter. And the network needs to guarantee service availability in case of failures and force major disasters.
- Policies and changing roles and responsibilities. Today, many services are supported by service silos. Each service comes with its own hardware, software and operational team. With NFV, service providers deploy a more horizontal model where the NFV platform – with its compute, storage and networking resources – is a common layer that doesn’t need to be duplicated for each service. This changes the roles and responsibilities of the operational teams. NFV and SDN will be much more policy-driven to ensure a coherent operational model and better automation.
How can SDN be used with NFV?
SDN can play several different roles in an NFV network. Two notable examples are the virtual backplane and service function chaining (SFC).
The virtual backplane
An NFV network needs to take on an additional task that was solved with special hardware for physical network functions. The larger physical network elements consist of a number of processing blades and interface cards connected via a backplane with a switching fabric. As these network elements become virtualized (VNFs), blades and cards are mapped to components (VNFCs) on virtual machines (VMs) running on the same servers, on different servers, or even distributed across multiple data centers (Figure 1).
Figure 1 demonstrates evolved packet core functions that are traditionally housed inside a router platform and with NFV are virtualized into separate VMs running on different servers. These functions include serving gateway, packet data network gateway, control, and termination. Internal communication paths now need to be mapped to (virtual) networks.
Packet performance is guaranteed and optimized for physical network functions by tuning the hardware and software together. Managing traffic flows between functions within a virtualized environment is a new task, which will be discussed below.
Service function chaining and virtual CPE
SFC is widely recognized as an important application of NFV and SDN. It allows service providers to create and sell packages of value-added services by adding them dynamically to the customer’s data path (Figure 2).
A service chain is a sequence of VNFs spliced into the data path between a traffic source and a traffic sink. For example, the blue service chain in figure 2 includes a firewall and a video optimizer. The red chain also includes the firewall but adds anti-virus and parental control functions.
Service chains can be applied to fixed broadband networks and mobile networks. In the former case, SFC enables the virtualization of customer premises equipment (vCPE). With SFC, subscriber traffic can be steered through a sequence of service functions moved from the physical CPE into the network.
With NFV and SDN, service providers can assemble service function chains through software configuration without physically installing appliances and without rewiring or manually reconfiguring network connectivity. They can use NFV to dynamically deploy virtual appliances and scale them out to match traffic demand.
In addition, SDN enables service providers to steer subscriber traffic according to the service chain configurations through different sequences of service functions. They can modify and enhance service chains on the fly, for example, by replacing one service function with a newer version or with a similar function from a different vendor. What’s more, subscribers can add or remove functions from their personal chains using a self-service portal.
This article is excerpted from the Alcatel-Lucent strategic white paper entitled The right SDN is right for NFV. To contact the author or request additional information, please send an email to firstname.lastname@example.org.