SDN for NFV: What will happen when the rubber hits the tarmac?

The ETSI Network Function Virtualization (NFV) Industry Specification Group (ISG) has recently been meeting in Okinawa, Japan for their 6th set of working group face to face meetings. There is no denying the energy and drive that the ETSI NFV ISG have for publishing their various specification documents by the end of this year. Having taken part in a number of earlier working group sessions (but not this most recent one) I do appreciate the resources and effort being invested in this definition process from across the telecommunications industry.

I do however anticipate that once the specifications are published there will be a number of hurdles that will need to be overcome before the NFV dream becomes a viable reality. For me the first big hurdle is encouraging the open source community or any of the major proprietary VM vendors to adopt all the features being asked for in the NFV related specifications. This is because the Virtual Machine market is predominantly driven by the needs of the enterprise datacentre. To support the full NFV feature set will add complexity to the VM orchestration layers for which the datacentre market may have little appetite. While it is true that what the ETSI NFV ISG argue; datacentre applications would benefit from carrier grade orchestration, the applications in the datacentre tend to be fundamentally different to those in telecommunications. For instance a typical web based service is connectionless, is based on atomic transactions and any session related state is usually held by the client. Telecommunication related applications tend to be the opposite.

Given the momentum that the NFV initiative has developed it should reasonably be anticipated that the telecoms industry will be able to expect that sections of the industry will respond to their needs. It may just take a while before such solutions are found in mainstream data-centric products.

More interesting for Radisys is what happens in terms of the network forwarding devices which will be needed to underpin the deployment of NFV applications. These are the Software Defined Networking (SDN) elements which get orchestrated in order to stitch together the network to underpin the distributed virtualized application. Various protocols are being suggested for this role, of which OpenFlow is seen to be the general favourite. Although due to OpenFlow’s perceived lack of a formal network modelling approach other solutions such as ForCES is also being cited in some quarters as a suitable alternative.

In my personal opinion, the biggest challenge for crafting an SDN forwarding element for use in a carrier class NFV deployment is scale. A carrier class application could have to track 10’s millions of subscribers and 100’s millions of flows. The responsiveness required to manage such tables, just to track the life cycle of each subscriber or flow, will go way beyond what any conventional SDN controller can handle and swamping the update rate capabilities of SDN based forwarding elements. (Have a listen to my short video on SDN).

As a network architect at Radisys this is the type of problem that I enjoy wrestling with. The solution in my mind is to build intelligence into the networking element itself. Make the networking element capable of autonomous behaviour. This means automatically creating appropriate rules for new flows, monitoring the health of VMs and initiating failover as required. Only by proactive intervention will the response times demanded by carrier class applications be met. It means that the network element is able to respond to in-band messaging from the application itself, so that there is as low latency as possible between events and the corresponding action to adapt the network.

This is why I am very excited about the forthcoming next generation T-Series product family from Radisys. By building intelligent switching products, each supporting 400Gbps of raw throughput, we will deliver the ultimate SDN forwarding element designed to address the needs of the carrier class NFV network infrastructure.

While the ETSI delegates eat sashimi in Okinawa, (which will be outstanding if it is anything like the tapas in Malaga for their previous meeting – which I did attend), Radisys architects are busy refining requirements for our NFV ready networking element. Do please drop me a line if you have any specific features which you think that we need to address.

Twitter icon