As software-defined networking takes off, it's become the basis of a parallel development: network function virtualisation.
NFV is a boon to the data centre. For decades now, giants and minnows of the networking industry alike – Cisco and all of its competitors, along with anybody offering firewalls, WAN optimisation devices and the rest – have dedicated development dollars to embiggening their packet processors to cope with ever-more-complex operations (with correspondingly costly kit).
Ever since Intel started pumping packet processing capabilities into its silicon, it's become feasible to shift network functions onto virtual instances running on white-box servers – making (say) a firewall both cheaper and easier to scale up and down.
A few years ago, carriers had a light-bulb moment. There are network functions in customer premises equipment (CPE) like broadband routers, they reasoned: why not pull those functions back into the carrier network? Hence was born the idea of the “virtual CPE”, something described by ETSI in this 2013 document (with a focus on enterprise networking, but it's just as applicable to the broader user base).
So what does the industry mean when it talks about Virtual CPE? After all, won't you still need something to take those bits from the wire (or the wireless or the fibre)?
The aims of the V-CPE are multi-faceted – and in a lot of ways, targeted to the carrier's needs rather than the end user's (although there's an inevitable pitch to the end user as well).
The basic checklist that vendors offer up includes simplicity, capex and opex, upgrade paths, security, and new service rollout. I'll address these later, but first let's look at the architecture that the industry has in mind.
Compared to the dumb modems of the early Internet, or even an early DSL modem, today's home broadband router has become a victim of considerable bloat. As well as terminating the signals coming from the carrier (layer 1 and layer 2 functions), it's a simple Layer 3 router, a NAT firewall, an Ethernet switch, a wireless access point, a DCHP server, and a Web server (to let you manage the thing). Oh, and it either serves as a telephone or runs a VoIP server.
Today's CPE (original image, Juniper Networks, here).
The V-CPE argument says the CPE should be a standard (and pretty dumb) device with minimal features. Anything beyond what the CPE needs to pass packets should be executed as software in a customer-specific virtual instance in the carrier's cloud.
Where the CPE-cloud line should be drawn is something the industry hasn't yet nailed down, but there's pretty broad agreement on a few things. A modem is absolutely necessary, as is the voice telephony termination, wireless capability, and Ethernet switching.
Functions broadly imagined as being put into the cloud include routing, NAT, DHCP, firewalling and security – and anything the carrier wants to introduce in the future.
CPE with its brains blown out.
The carriers love this idea, because from their point of view:
- Cheaper CPE – the last decade has seen an arm's race in CPE capability. Providers and broadband router vendors have worked hard to pack more stuff into the kit as a differentiator. That makes the kit more expensive, and often that cost is something the carrier picks up and amortises over the life of the customer.
- Cheaper support – a single standard CPE means there's a lot fewer steps to follow on the fault-finding list. If something's gone wrong at the V-CPE end, reboot is probably a lot faster in the cloud than in the CPE.
- Security – Not only can security functions be put into the carrier network, the V-CPE also gets around a serious problem, that home broadband users almost never flash new firmware to their routers in response to a security vulnerability. And at Layer 2, the device becomes too dumb to need an admin Web server to be compromised.
- Upgradeability – A new function (cloud storage, a home video server, home automation, DPI and so on) can be created in the cloud instance without sending out new routers.
- Manageability – the user can still furtle with settings, because they'll just see a Web interface to their V-CPE in the cloud. However, the carrier can offer management services without having to try and access the customer's kit.
What's the catch?
With so many pluses, there can't possibly be a catch, can there?
Well, yes, there can, and as catches go, “it's the best there is”.
One of the guiding principles of the Internet is “smart hosts, dumb network”: the network's only job is to shut packets around. It's an architecture that's credited with a big chunk of the Internet's vibrant innovation.
It's also been anathema to the telecommunications carrier, because it moved applications out of their networks and into the hands of others – where the carrier didn't get to charge for the service.
Relegation to mere bit-shifters has been a serious issue for telcos around the world: customers' relentless appetite for bandwidth demands expensive network upgrades, but average revenue per user (ARPU) rises nowhere near as fast as data consumption.
The V-CPE is a godsend in this context. Any new service the carrier can imagine gets implemented in its brand-new smart network – and offers the long-lost and bitterly-mourned chance to turn services into billing events.
Think it won't happen? Look at the mobile business, where there are smartphones that don't bill if you're using the Facebook or Twitter app they shipped with the phone as a product differentiator, but soak you by the megabyte if you go surfing the Internet at large.
V-CPE also offers not-so-subtly anti-competitive customer wrap-ups, the chance to return to a world where the “real” CPE is designed for one network and one network only (something which has existed in the past).
The degree of ownership a customer has over their services is also worth considering. What if one of the rare individuals who understands TCP/IP addressing wants to create their own home network's addressing scheme, to fulfil a need of their own, only to find that it's not supported by the carrier (on a 'you don't need to worry about that' basis)?
The Register would like to close with a final unanswered question about the world of V-CPE: if the carrier is delivering Layer 2 to the customer, rather than Internet TCP/IP traffic, does this have implications for the neutrality of the customer's service?
What if, some day, users find that access to YouTube must be via the carrier's mandated video service rather than as generic Internet traffic? Would this be caught by whatever neutrality regulations the world eventually agrees on?
Of course, most customers won't notice the change. Heaven knows, they calmly accept the conversion of the once-open Internet with the Web as its interface into a dizzying array of nearly worthless single-function apps. ®