Linux Foundation Announces Major Network Functions Virtualization Project

Andy Updegrove writes: The Linux Foundation this morning announced the latest addition to its family of major hosted open source initiatives: the Open Platform for NFV Project (OPNFV). Its mission is to develop and maintain a carrier-grade, integrated, open source reference platform for the telecom industry. Importantly, the thirty-eight founding members include not only cloud and service infrastructure vendors, but telecom service providers, developers and end users as well. The announcement of OPNFV highlights three of the most significant trends in IT: virtualization (the NFV part of the name refers to network function virtualization), moving software and services to the cloud, and collaboratively developing complex open source platforms in order to accelerate deployment of new business models while enabling interoperability across a wide range of products and services. The project is also significant for reflecting a growing recognition that open source projects need to incorporate open standards planning into their work programs from the beginning, rather than as an afterthought.

Comments

Businessese Bingo

[Art3x]

collaboratively developing complex open source platforms in order to accelerate deployment of new business models while enabling interoperability across a wide range of products and services

Bingo!

Re:Businessese Bingo

[Trepidity]

* complex open source middleware

* for the cloud

Re:Businessese Bingo

[brakarific]

I happen to work as a field engineer for one of the bigger companies that is funding this project. I work pretty closely with our product management and software development group. There are massive network virtualization projects going on now with a couple of Tier 1 Carriers and Hosting companies. There are probably more projects that I'm unaware of. The Carriers and Hosting Companies aren't looking for new standards, they are just tired of buying a $20k - $150k router that can only ever be a router. That is a large capex risk that you can't recoup if you don't need it after a year or two. A x86 platform on the other hand is very low risk as it is the swiss army knife of data center expenditures. If you can place almost everything on x86 gear then your expense risk is pretty much nill.

We all know that there is a reason ASICs have always been used for TCP/IP processing and not x86 procs. Up until about a year ago that fact still held true. That was until Intel developed a cool little piece of code called DPDK. Seriously, look into it if you want to know why x86 might actually be OK for simple L3/4 IP/TCP tasks such as routing/firewall/vpn etc. I know that today you can push 40gbps line speed L3 operations on COTS hardware on a single proc (8 cores) in a server. To buy a router today that can do the same will cost you around $25 - $30k. Switching operations that still require low latency and high port density will still need to be done on dedicated switches, but anything requiring brute horsepower for L3 forwarding at high throughput (not the same as latency) will be able to be done in virtual appliances now.

While we are still a few years away from mass market enterprise virtual router/firewall parity to hardware, we will make it there. The is a boatload of money to be made any time there is a huge market disruption. There are only three companies that don't want this kind of disruption, namely Cisco, Juniper, and Huawei. Every other networking vendor is watering at the mouth at the very thought that they could steal money and market share from those three. There are huge amounts of money and talent working on this (Intel, VMWare, Red Hat, HP, Brocade, and many more). I know for a fact that Intel is going to invest massively in networking over the next few years. Sit tight and watch John Chambers writhe in his comfy leather chair. It's gonna be fun watching that company go the way of Blackberry.

Beware

[TechyImmigrant]

The telecoms contributors will play dirty. I promise you.

horrible VM latency

[fredness]

Translation: VM's are cheap and flexible, but have horrible packet latency
Solution: don't use a VM

Move along, nothing to see here, yawn.

Re:Businessese Bingo and Telecom Workloads

[billstewart]

No, the point of being a telecom company is to connect your customers together, move their data where they want it efficiently, and get them to pay you for it. Telecom workloads not only include digging ditches for your access line and running wavelength division multiplexors across them, they also include things like routing IPv4/IPv6, firewalls, load balancing, intrusion detection, preventing and mitigating DDOS, hosting CDNs, routing lots of private networks that all run RFC1918 addresses and maybe VLANs, MPLS, maintaining really large BGP tables, fast rerouting around failures, etc.

We're virtualizing that stuff instead of buying big expensive custom-built routers for the same reasons you're virtualizing your compute loads instead of stacking up lots of 1U machines. Internet-scale routers are blazingly expensive, and we want to use Moore's Law to do the compute-bound parts of the workload cheaply and efficiently and let us build new services quickly because we only have to upgrade the software, while using expensive custom hardware only for the things that really need it, plus a lot of that hardware is getting replaced by things like Openflow switches and SDN, which we'd like to take advantage of, and buying expensive dedicated-purpose hardware means you're often stuck overbuilding because the scale of your different types of workloads changes faster than you can redesign hardware.

Also, the transition of lots of enterprise corporate computing from traditional data center structures to clouds means that the communication patterns change a lot faster, and we need to keep up with them. This stuff does seem to be driven a lot more by the needs of the users (telecom and data center) than by the manufacturers of virtualization software or traditional hardware.

And yes, every bit of business buzzword bingo does flow across our desks.