Knitting NFV Together Using SDN (and More)

Achieving NFV with SDN

Software-defined networking (SDN) is networking, so it must connect things, right?

Yes, but SDN doesn’t connect elements by routing IP packets. Counter to many rumors, IP routing is still very much a part of the SDN equation. IP routing connects point A in the network with point B, hop by hop, and it scales, doing so by constantly propagating structured addressing information (subnets) through network links, capturing knowledge about the link topology.

But what if point B is not a point? What if it is a network function, content, or a service? And what if we want the network to pick the best, most available (elastically, dynamically, etc.) point B, one that fits A the best at this very moment? Subnet routing cannot figure these types of abstracted coordinates.

Until quite recently, IP routing was the most scalable thing around—far more scalable then circuit switching, or any client-server software control structure we could think of. So when it came to the above requirements, we had to just get by, perhaps with the help of policy routes, DPI and DNS tricks.

But that’s not the case anymore. From the requirements side, resource mobility, elasticity and abstraction become the norm rather than exception. From the industry abilities side, based on IP networking, incredibly scalable software lookup technologies evolved for Internet applications. They can now be used to connect identities, content and functions, and do so dynamically, elastically, and with personalized virtualization of applications and network functions.

As a simple example, we can think of the service provider network access control list (ACL)—today an extra burden of configuration on IP interfaces, susceptible to errors and broken by any entity movement or network topology change. Using SDN technology and scalable global software lookup, access control becomes a policy record, like an electronic medical record that follows identities around.

Building NFV Graphs

A more sophisticated network functions virtualization (NFV) example is the virtualization of the mega evolved packet core (EPC) and IP multimedia subsystem (IMS) core functional boxes for subscriber mobility or voice-over-IP. The trend is to unbundle such “big” functional network junction form-factors in favor of micro virtual machines and to do so by capacity and features. These micro components can be assembled dynamically by SDN connectivity. This means SDN steering and mapping the right flows, to the right NFV virtual machine, at the right sequence, in what is known as the NVF Forwarding Graph (NFV-FG). NFV-FG chains, balances, functions and protects the consistent long-lived states created in them.

However, there are two notions to keep in mind about these hot new networking software technologies:

1. Software-defined lookups can only scale as an overlay to an IP underlay. This means they cannot route flows hop-by-hop instead of IP without introducing exponential complexity. They must also use some type of distributed hash or directory to scale the number of lookups per second, distributed by IP routing. This aspect of SDN control makes IETF standards work on IP overlays and mapping underlays such as LISP, VXLAN and NVO3 key to the scale of SDN technology.

2. Software-defined lookup decisions are global and costly and therefore cannot be applied per packet. They must be applied per flow or network conversation. This is key for an efficient lookup-to-packets transaction ratio, for reasonable footprint of SDN gear, and for clean separation of technology disciples and suppliers. This separation makes the Open Networking Foundation (ONF) OpenFlow-related work in standard bodies and the flow instruction set defined by switch NIC vendors also key for the success of SDN technology. The term SDN switching chip is not an oxymoron.

These two points define the key demarcations that will make SDN robust, scalable, highly functional, and cost-effective as a new programmable fabric of connectivity for users, network functions, content, and services. Separating control from forwarding using OpenFlow and overlay separation of identities from routing locations enable vendors and service providers to embrace SDN and to succeed, as demonstrated by announced, large-scale, real-life SDN deployments in fixed-mobile carrier functions.


Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers.

While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDNCentral cannot guarantee that inaccuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within this site, or any information accessed through this site.

The content of any third party web site which you link to from the SDNCentral site are entirely out of the control of SDNCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDNCentral’s endorsement or association. The copyright and any other intellectual property right any third party content belongs to the author and/or other applicable third party.


  1. kulin shah says

    Really interesting article Sharon. The point you make about IP routing still being valid and needed but thinking of NFV as a way to go from point A to service, virtualized function etc. is really strong and hits home in a simple manner. On those lines, what are some of the specific 1. use cases & 2. specific methods you are seeing with customers or in the industry in general to achieve NFV today or in the near future?

  2. Sharon Barkai says

    Thanks for the comment. I will attempt to answer your questions as best I can.

    Separating SDN control/forwarding and structuring SDN as overlay-mapping enable networkers to focus on new programmable connectivity tasks while relying on existing IP and known DB mechanisms for scale, consistency, and high-availability. Virtualized network functions (NFV) are key applications as such. We can segment uses into four main categories:

    1. Layer 2/3 flat network virtualization connecting both hosted and customer end-point locations
    2. Subscriber broadband mobility and IP telephony cores, Internet access features, filters, analytics, optimization, etc.
    3. Platform and hosted applications as services delivered like carrier core functions on behalf of enterprises, content distribution network functions, etc.
    4. Virtualized, aggregated, and clustered customer premise and last mile appliances such as set-tops, gateways, radio controllers, etc.

    What we typically encounter for early stage NFV applications in these segments is:

    – Packaged deployments of virtual layers 2/3 (1) as basis for subscriber and content functions (2 and 3), and not just as pure standalone capability
    – Deployments clustered as overlay around an existing and untouched bridged routed network, EPC switches, or WAN backbone routers
    – Deployment that combines existing non-virtual functional boxes, yet pooled all-actively using SDN flow mapping with virtual add-on feature servers.

    So, while underlying technologies are already shifted towards SDN/NFV, delivery is typically packaged as traditional clustered boxes around existing in-place and un-meddled with backbones, combining existing and virtual functional boxes around an updated overlay topology.

    I hope this helps!

Leave a Reply