NFV (Network functions virtualization)

Defining SDN & NFV

It's been nearly three years since software-defined networking (SDN) was first referenced at Light Reading and nearly 15 months since network functions virtualization (NFV) arrived on the scene. (See Big Switch Raises $13.75M and Tier 1 Carriers Tackle Telco SDN.)

The pace of development in both SDN and NFV has been astonishing when compared with the usual pace of the telecom sector so, not surprisingly, everyone wants a piece of the action and to be associated with the hottest technology trends in town.

That also means it can be easy to lose sight of what these developments are about, especially as the terms get added to just about every public statement made in the communications market. ("We have SDN-enabled our parking lot…" and "Our hot beverage facilities have been greatly enhanced by NFV" are just two examples I am waiting eagerly to read.)

So here are two quick definitions that, from now on, we will reference when writing about these critical topics. The SDN definition comes from the very able and experienced team at Heavy Reading (thanks folks) and the NFV definition from the first white paper published by the European Telecommunications Standards Institute (ETSI) Industry Specifications Group (ISG) that is at the heart of NFV developments.

SDN (software-defined networking)
SDN is an architectural concept that encompasses the programmability of multiple network layers -- including management, network services, control, forwarding and transport planes -- to optimize the use of network resources, promote interoperability across suppliers and network layers, increase network agility, unleash service innovation, accelerate service time-to-market, extract business intelligence and ultimately enable dynamic, service-driven virtual networks. – Heavy Reading

NFV (network functions virtualization)
NFV aims to... leverage standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, Network Nodes and in the end user premises... [NFV] is applicable to any data plane packet processing and control plane function in fixed and mobile network infrastructures. – NFV ISG (ETSI)

You can be sure we will be linking back to these definitions regularly in 2014 as the noise around SDN and NFV gets even louder.

— Ray Le Maistre, Editor-in-Chief, Light Reading

Page 1 / 2   >   >>
Eddie_ 1/24/2014 | 4:00:15 AM
Re: my favourite SDN definition wildcard22,


today's leading article from Carol is a perfect fit for our discussion, I think. In my opinion it shows a multifaceted picture of the term 'open' and it underlines it's importance for a definition of SDN. Therefore your definition is a good approach, anthough Carol's article claims much more openness, e.g. torards North, East/West. 

t.bogataj 1/24/2014 | 2:25:57 AM
Re: my favourite SDN definition wildcard22,

I agree with your remarks. Regarding open interfaces, SBI is still the easiest challenge, regardless of whether it is OF or any other standard (and/or well-adopted) interface. All other interfaces (north-/east-/westbound) depend on applications and use cases and will hardly get universally standardised.

Let's wait and see what ONF NBI WG comes up with... But I remain sceptical that anyone is able to find a common denominator.

wildcard22 1/23/2014 | 4:26:18 PM
Re: my favourite SDN definition T,

This defintion is close 

SDN focuses on four key features:
• Separation of the control plane from the data plane
• A centralized controller and view of the network
• Open interfaces between the devices in the control plane (controllers) and those in the data plane
• Programmability of the network by external applications

But a couple of issues:

1) Instead of "centralized" controller, we have consistently said "logically-centralized". In other words, the controllers are actually distributed, but they give the appearence of being 'one', so that applications can be written on top, as though they were being written for a centralized platform.

2) Open interfaces between control and data planes is a no-brainer. But there has never  been a requirement for the interface(s) between controllers to be open (i.e standardized). This is because, achieving point number (1) above is hard, and is critically dependent on these controller<->controller interfaces. Moverover, the needs of these interfaces to achieve (1) change, given the networking segment (enterpise, DC, WAN, etc) and the mode-of-operation (proactive, reactive, hybrid). So it is too early to "standardize" these interfaces


Eddie_ 1/23/2014 | 11:15:18 AM
Re: SDN is open! Sterling,

from my perspective "interoperability across vendors and layers" is not strong enough. An Ecosystem controlled by a single vendor could also claim some (internal) interoperabilty. "Interoperability" (especially between layers) could even be used as an argument for proprietary solutions.


sterlingperrin 1/23/2014 | 9:19:32 AM
Re: SDN is open! Eduard0,

Good point about the requirement for openness. This is a recurring theme in my operator discusisons as well. In the HR definition, the wording about "interoperability across vendors and layers" is meant to address the opennes requirement as a proprietary technology would not achieve these needs.



t.bogataj 1/23/2014 | 9:01:43 AM
Re: my favourite SDN definition Eddie,

Quoting definitions of of alliances and forums inevitably leads to their specific views (see my comment below). Citing ONF means adopting its view that SDN SBI equals OF.

I suggest reading an article by Sezer et al. in the July 2013 edition of IEEE Communications Magazine. Quoting from the article:

SDN focuses on four key features:
• Separation of the control plane from the data plane
• A centralized controller and view of the network
• Open interfaces between the devices in the control plane (controllers) and those in the data plane
• Programmability of the network by external applications

The definition can hardly get any better than that. And it also addresses your comment on 'openness'.


Eddie_ 1/23/2014 | 7:48:28 AM
my favourite SDN definition includes all aspects discussed:


t.bogataj 1/23/2014 | 2:38:01 AM
Re: Defining SDN SDN is an architectural approach that separates applications from control layer, and (a part of) control layer from the forwarding plane. SDN is much wider than particular views that some vendors or industry alliances promote. Reducing SDN to OpenFlow SBI only, and saying that the two are equal is just too narrow.

A car is a four+ wheel transportation device. Gasoline-based internal-combustion engines are just one way to implement (a part of) a car. Saying that SDN=OF is like saying that a car is a gasoline-engine based device – a definition too narrow and thus false.

Time will tell what the operators (not vendors) will recognise as SDN and what they will adopt as SDN. Maybe OF will become a de facto standard within SDN, while other SBIs will not be used for SDN. But even then OF SBI will still be just one way to implement (a part of) SDN.

TomNolle 1/22/2014 | 1:09:48 PM
Re: Defining SDN I have to disagree, Sam, unless "the industry" means something other than the broad community of buyers.  In three consecutive surveys of 277enterprises I've never found the "separation of control plane" standard as their baseline for SDN.  In the latest survey the majority did not even require that OpenFlow be a part of SDN.  I would agree with those who will say that this view is in part the result of vendor merchandizing but whatever the cause it is what it is, and so it's fair to try to come up with a definition of SDN (and NFV) that fits current usage.

Keats said something like "Beauty is truth; truth beauty.  That is all ye know on earth and all ye need to know" and it's a really nice sentiment but not a particularly helpful way of addressing the real world.
Eddie_ 1/22/2014 | 11:05:23 AM
SDN is open! What I am missing in the discussion about the definition of SDN s the word 'open'. From my perspective, openness is the most important architectural aspect of SDN as well as it is it's  biggest benefit. A definition of SDN should takt that aspect into account. Otherwise any proprietary approach could also sail under the flag of SDN. 


Eddie Beier
Page 1 / 2   >   >>
Sign In