The Ultimate Guide to the Role of SDN in NFV

Feeling confused about the role of  SDN in NFV? You are not alone!..

Many get stuck in understanding the role of SDN in NFV. Still, others want to know what is SDN ? And Others simply are not clear about the use cases for SDN in NFV.

Do you know that without the right SDN architecture,  you will end up with rigid, inelastic and not-scalable NFV?

But, don’t worry!

This ultimate guide is all you need to get clarity on how SDN can help you build up a truly elastic Telco Cloud. It doesn’t matter whether or not you know about SDN. You will know everything in the guide from A to Z. You will learn:

• The Role of Networking in NFV.
• What is SDN and its benefits?
• Where to place  SDN components  in NFV i.e. location of SDN controller, switches and applications
• SDN Use cases in NFV: Dynamic Service Chaining, VNF Scaling, 5G Network Slicing, among others.

You may read from start to end or jump to the section. You may comeback using browser back button or Red pointer at the bottom

Section 1: Networking Role in NFV

Before understanding SDN, we should know the networking’s role in NFV.

To understand this, we zoom into the NFVI Block of ETSI MANO Architecture.

Physical and Virtual Network form the part of the networking domain.

To take this discussion forward,  a Data Center/NFVI set up in the example below that shows components of the networking domain.

This simplified diagram of modern data center shows the three main components of the networking domain: Virtual Switch (VSwitch), Top-of-Rack (TOR/Leaf Switch) and Spine Switch.

Two racks host multiple servers. With each rack having a Top-of-Rack (TOR) Switch (also called leaf)  and a spine switch that connects those TOR switches.

Comparing this diagram with the ETSI Architecture above:

• The TOR and Spine switches form the physical network.
• While the VSwitch (Virtual Switch) which resides in the server is a part of the virtual network.

PS: In some deployments, VSwitch can reside in TOR switch too.

VNFs communicate in this fashion:

1. VNFs in the same server communicate through VSwitch.
2. VNFs in the same rack but different servers communicate through TOR switch
3. VNFs in a different rack happens through both TOR and Spine switch.

So, you can see that networking forms an important part of NFV Architecture as all VNF to VNF communication happens through this layer.

Let’s move to the next step on how SDN can help with this networking

But before that, what is SDN?

Section 2: What is SDN  and benefits?

SDN stands for Software Defined Networking.

ITU-T Y.3300 defines SDN as follows:

“SDN relocates the control of network resources to a dedicated network element, namely SDN controller, which provides a means to program, orchestrate, control and manage the network resources through software (i.e., SDN applications)”

SDN has the following three layers:

Ref: ITU-T Y.3300

In other words, the three layers are

The Three Layers in SDN

1. Application Layer
2. Controller Layer  that has the control plane
3. Network Resource layer that has the data plane/forwarding plane ( also called SDN resources)

The ITU-T definition sums up many things nicely:

• First, It is about the separation of Control Plane ( SDN Controller) and Data Plane (Network Resources). ( Data Plane forwards the packets while control plane instructs forwarding plane on how and where to process the packets)
• Second, Abstraction through northbound, can help in programmability and opens the door for automation.

As a consequence to above,  the control plane from the current switches/router moves to a central place, leaving behind a simple box with data plane only that can just forward the traffic as instructed by a centralized SDN controller.

This leads to the question, what are the benefits of SDN?

Benefits of SDN

• Centralized control gives the ability to manage the network more easily.

• BOX without control plane makes it simple and lowers CAPEX

• BOX without control plane makes it simple and lowers CAPEX

• The interfaces are “Open”, so it opens the door for automation and programmability.

• Is enabler for Network virtualization: a virtual network (overlay) on top of the physical network which is totally separate with no dependence on the physical network

Network Virtualization is itself is a big topic in data centers. I explain this further in the first use case of the SDN below.

But before that we need to understand where SDN sits in NFV Architecture.

Section 3: Location of SDN Controller, Resources

ETSI has specified the location of SDN elements inside NFV. This section summarizes the probable locations of SDN Controller, SDN Resource and SDN Application in NFV Architecture.

Note that ETSI use the word “SDN Resource” for the forwarding element (Compared to the word “Network Resource” which ITU-T is using)

There is a lot of flexibility where SDN controller and other elements can sit inside NFV Architecture.

Location of SDN Controller

First, let’s see the location of the SDN Controller. The SDN Controller can sit in any of the five locations:

• Part of VIM
• Part of NFVI
• As VNF
• Part of OSS
• As PNF

Location of SDN Resource

SDN Resource sits in any of the following locations as shown:

• Physical Switch or Router
• Virtual Switch or Router
• e-switch, software-based SDN enabled switch in a server NIC
• Switch or Router as VNF

Location of SDN Application

SDN Application sits in any of the following positions

• As part of PNF
• As part of VIM
• As part of VNF
• As part of EM
• As part of OSS/BSS

This table summarizes the location of different SDN elements.

Summarizing it all in one Example Scenario

Here is an example of all components of SDN in one NFV Diagram.

SDN Application sits in OSS/BSS that connects to SDN Controller which is controlling the resources in the virtual network of NFVI

After going through the location of different resources, let’s discuss the need for the SDN controller in NFV.

Section 4: Use Case1: VM Mobility in Data Center

That is, use SDN Controller in NFV for the same reason as you use it in IT Data Center

When you think about IT Data Center, few requirements come to mind:

• Flexibility in networking
• Flexibility in moving Virtual Machines (VMs) from one location to another
• Centralized control of security policies
• Multi-Tenancy

Now, the traditional DC does not support the flexibility of these features. One of these issues needs more explanation.

Issue of moving VMs in DC (The Infamous VM Mobility Issue)

Servers typically get IP addresses based on their physical location, for example, based on the TOR switch for the server rack or the C-VLAN configured to the server. Servers can only move locations, flexibly,  if it’s within the same IP subnet.

This constraint is OK for physical servers, which do not move frequently, However, it severely impacts the movement of VMs which move more frequently such as those within the multi-tenant data center.

Any solution for a scalable multi-tenant data center must allow VM movement without the constraint of subnet boundaries.

Not only there is an issue to move VM but also in very big scale networks, the VLANs can exhaust as they have a limitation of  4094 only.

Network Virtualization is the answer

Network Virtualization helps solve the issue of VMs movement. It builds up a virtual network on top of the physical network with no dependency on it.

Network Virtualization enables overlay tunnels that help establish virtual networks. There are multiple ways to do these tunnels, for example, VXLAN, STT, NVGRE, etc.

How VXLANs solve VM Mobility issu

VXLAN is a tunneling protocol that encapsulates Layer 2 Ethernet frames in Layer 3 UDP packets, enabling you to create virtualize Layer 2 subnets

However, it is very scalable: Through the use of a 24-bit number VXLAN identifier, it can generate as many as 16 million different virtual networks

The result is a complete separation from infrastructure networking domain.

The VMs are free to move anywhere and cross any subnets with no issue as they are no longer tied to the IP subnets of the infrastructure domain.

Also, this solves the issue of running a highly scalable Multi-tenant network with no limitations of VLANs as in traditional networking.

Ok if this is true in IT DC, all these can be true in Telco DC in case of NFV.

So you need SDN for VM Mobility in NFV if

• If you need a highly scalable and secure multi-tenant network. The tenants can be your external customers or internal departments of  a Service Provider.
• You want a cloud-like architecture where VNFs do not tie to any physical location. You want to move VNF workloads freely. You often migrate VMs from one location to another ( within or to a different data center) .
• You want to prepare for disaster recovery or you have a requirement to migrate the data center and are forced to move all your VNFs to a different data center but you do not want the hassle and headaches that arise because of the configuration changes that need to happen in networking because of this change.

Section 5: Use Case 2: Network Service using VNF-FG

That is creation of Network Service using VNF-Forwarding Graph ( VNF-FG)

Remember one of the Jobs of the NFVO?

I.e. Creation/Orchestration of  Network Services ( NS).

A Network Service (NS) associates a group of VNFs.

Creation of Network Services requires connecting VNFs in particular order as VNF-FGs, already explained in the article here

The VNF-FGs, then have virtual links connecting them as shown in the figure below. These links can be layer 2 or layer 3.

Do you really need SDN for VNF-FG?

Perhaps No!

You can use the Neutron networking component inside the OpenStack to help with this connectivity.

But that is rather a static way of creating networks !

What, if you need a more flexible creation of Network Services?

You need it for more dynamic behavior

For example, you want to make, break and modify virtual links fast !

Want to innovate and experiment the creation of new services !

You are migrating VNFs and want to create Network connectivity fast.

Then SDN is the answer for you. SDN, having centralized control, gives you more control over how you want to spin up network services quickly. You may not need to go to each switch to do configurations. That is the power of SDN

Section 6: Use Case 3: VNF Scaling

It is not unusual for a VNF to run out of resources like RAM, CPU or bandwidth. In that regard, it is wise to have a plan for the VNF’s Smooth scaling. There are different strategies as shown below.

Vertical Scaling: That adds more CPU, RAM etc in the same Virtual Machine. (This is least disruptive)

Horizontal Scaling: That scales out a Virtual and adds another Virtual Machine with more resources either inside the same server or another server. ( So this is more challenging as it needs efficient networking too)

Increasing Bandwidth : That adds more networking resources if existing links are congested.

Lets take example of horizontal scaling. The manual way would be to spin up new virtual machine and then add the additional networking links as shown in the diagram.

However in a highly flexible and cloud like environment where resources are scaled out and scaled in continuously, this manual way would not scale very well. That is where a software defined networking can help create, delete and modify network resources on the fly.

Section 7: Use Case 4: Dynamic Service Chaining

Service Chaining is one of the hot use cases in NFV. And for one reason: the combination of SDN and NFV enables service chaining more dynamically.

The Mobile core is one such example which needs flexible service chains in Gi-LAN. But what is a service chain in the first place?

One such example below shows two service chains: The red service chain connects DPI,  FW ( Firewall) and NAT while the blue service chain DPI and IDS together.

But Isn’t VNF-FG creation discussed earlier as service chaining

On the face, we can consider the earlier Use Case 2 of VNF-FG as “service chaining” as different VNFs are chained together.

Yes, we can call it service function chaining.

But this use case takes one step further: Dynamic Service Chaining

One can create dynamic service chains based on action in one of the service function. How?

Understand the word Dynamic in “Dynamic Service Chaining”

To understand Dynamic service function on chaining, lets first understand the Service function chaining as per IETF RFC 7655:

For this, all we need to understand is the role of three functions. Classifier, Encapsulation and Service Function Forwarder (SFF)

Easy way to understand IETF Service Chaining

• 1st Step: Encapsulation: Traffic goes into a classifier that encapsulates traffic in a service function header before sending it to SFF ( Service function header). Note that this “encapsulation” is a very important step as it defines the service path, ie.  which service functions the traffic will touch as it passes through the service chain.
• 2nd Step: Forwarding: The job of the SFF is to route the traffic among different service function chain according to the header information of this  “encapsulated traffic“.
• 3rd Step : De-encapsulation: After the traffic passes through a service chain, SFF sends the traffic back to an SF classifier, which removes the SF encapsulation before sending the traffic back to the network.

So far so good, so how does this apply to NFV and where is the dynamic behavior?

One example is shown by one of the use cases of the Open Daylight controller.

In the use case below a dynamic service chain,  all traffic is mapped to the green service chain that has DPI function. The other two functions are  P2P Rate Limiter and HTTP ( For example Header Enrichment).

As the DPI analyzes the flow, it finds out that the traffic is  bit torrent.  it would then send feedback to the SDN controller ( ODL in this case). which would then ask the Classifier to re-classify that particular flow to follow the Blue chain instead of the green chain, thereby rate limit the PTP  bit torrent traffic ( So no need for the DPI to be in service chain after the re-classification).

However, if the DPI determines that the traffic is HTTP, it should be redirected to HTTP function-the red chain. So the beauty of this particular scenario is that service path has changed based on the detection in the first service function (DPI). which is much more efficient and faster compared to the scenraio that all traffic must pass through DPI.

Section 8 :Use Case 5: Network Slicing for 5G

3GPP considers Network Slicing as one of the key technologies for 5G Network. Operators could share the same physical network to different tenants.

What is Network Slicing and its benefits?

These virtual networks must be isolated from one another. There may be one virtual network for delay sensitive services, there may be another one for Mobile broadband. Still another one as a trial network for testing purpose.

When compared to traditional networks, slicing has following advantages

• Traffic differentiation per service in terms of QoS.
• Network resource isolation for improved security and reliability
• More scalable services per traffic type
• Multi-tenant 5G Network: Opening doors for flexible MVNOs ( Mobile Virtual Network Operator)

How SDN Can help here?

The below diagram shows two tenants. Each tenant can, in turn, run multiple slices in his own domain. The NFVI resources are shared. Each Tenant has access to his VMs in the shared NFVI infrastructure. ( Green Tenant has acces to green resources and Blue Tenant to blue VMs). There are three different Infrastructure providers here, two for the  NFVI infrastructure and the third one provides its WAN domain.

Multiple DC Controllers and WAN controller

There are multiple SDN controllers here.

1. Tenant SDN Controller, that dynamically chains the VNFs as per Network service defined by the NFVO.
2. Infrastructure SDN Controller owned by Infrastructure provider that manages the NFVI resources inside the NFVI Pop. A simple analogy is that the Tenant SDN controller manages the overlay on top of the underlay which is  managed by the infrastructure provider.
3. The WAN Controller that manages the SDN connectivity in the WAN domain

Each tenant manages the slices that are operative in its domain through its NFVO, that coordinates resource management in different NFVI PoPs. NFVO would need to orchestrate resources across different domains.

So you can see the power of SDN in network slicing. The SDN controllers would help create a seamless slice from the data center to the WAN enabling end to end transport slice for 5G.

Conclusion

So after this long article what you feel about your knowledge about SDN role in NFV.

This article summarizes the top use cases for SDN in NFV. Let me know in the comments below on your views on the use cases and If I missed something or you would like to add any other use case.