The European Telecommunications Standards Institute (ETSI), the organisation steering the development of carrier Network Functions Virtualisation (NFV), and the Open Networking Foundation (ONF), the forum behind OpenFlow and Software Defined Networks (SDN) have announced a hook-up with the objective of accelerating the introduction of NFV.

The two bodies say they’ll work together to show how SDN can enable forwarding-plane support for some of the most important NFV use cases. “In particular, our two organizations will collaborate on the means to build dynamic, programmable VNF forwarding graphs. ETSI’s NFV ISG has launched a call for NFV Proofs of Concept (PoC) and published a PoC framework,” says the press release.

The ONF says it’s releasing a supporting OpenFlow-enabled SDN and NFV solution brief, designed to showcase how operators are combining NFV and SDN to get to the greater agility telcos are seeking through the introduction of the new approaches.

In the early days of ETSI’s NFV push (just over a year ago - can it be so recent?) we were often asked about the difference between NFV and SDN and how they fitted together. With this announcement it’s become clear just how complementary the two approaches are.

If you think of the carrier network as a collection of data processing functions connected by high speed links, it starts to make sense.

To now those processing functions - routing, switching, record storing (data collection), monitoring, transcoding etc etc - were all done by specific servers or black boxes rooted to their particular spots in the network.

Once you virtualise these functions through NFV though, the functions can (if required) be floated around the network to other servers where they can better intercept the data that needs to be processed, or to where there is some spare processing power. So you get resilience plus the ability to optimise the performance of the network.

The function-moving bit is what can be properly supported by SDN which, of course, separates the ‘control’ and ‘data’ planes in the network so that - amongst other things - flows between the functions can be reconfigured on the fly.

Of course NFV doesn’t need to do this (and in fact many implementations probably won’t in the early stages of NFV introduction) but it makes sense that the real power and flexibility to be gained from virtualisation will be won by marrying NFV with SDN.