Virtual CPE (vCPE) is one of the hotter topics these days, and even though it has its roots in NFV the concept seems to be taking some tottering steps on its own. As it does, it may be exposing some evolutionary trends that could supplement or replace aspects of the NFV value proposition, and even help us understand where services are heading.
vCPE is part of a very well-established trend toward “service-sourcing” in networks. In the old days, businesses built networks from circuits and nodal devices—routers most recently. As IP convergence and Carrier Ethernet matured, this model was gradually replaced by an edge-networking model, where an operator provided architected multi-site connectivity (VLANs or VPNs) and users simply attached to it at each site. In most cases the edge devices were essentially members in the architected connectivity operators provided, and in some cases they were even “customer-located equipment” or CLE, provided by and owned by the operator but located on the premises.
The benefit of architected connectivity is that you don’t have to build a network from trunks and nodes on your own. The value proposition for this type of service is much the same as for the cloud, so if it’s good to buy architected L2 or L3 services, then it follows it might be helpful to buy higher-layer services as well. In many cases, users of VLANs and VPNs purchase equipment or features to add to basic L2/L3 connectivity, and it’s these devices that were among the primary targets of the early NFV work. Why buy and install devices that add specific functionality and have to be maintained, updated, changed in and out, when you can do that virtually, as-a-service?
Generalizing service deliveries, meaning true networking-as-a-service, requires a general access model or you end up with access connections waiting for something to connect with. Elasticity of services demands, in a realistic world, an access pipe with enough capacity and capability to terminate all the variable stuff you plan to use/sell. Adva’s latest agile access notion, which is only vaguely NFV-ish in detail, is a good example of an agile demark. You could in theory set up multiple L2 terminations on a trunk, a combination of L2 and L3. This also seems compatible with Brocade’s elastic edge concept, which uses a hosted router/firewall inside the carrier cloud to serve as the L3 ramp to a simple L2 dmarc. It’s not NFV but it might be important in exploiting what NFV can do.
Another approach that’s being touted is the “agile CPE” model, where a device that has general hosting capability is used to replace multiple special-function devices like firewalls and routers. This could look a lot like NFV in that you could add “VNFs” to the box to add functionality, but unlike classic NFV there’s no need to host the VNFs in a cloud. RAD, Overture, and other vendors are now offering boxes that do this.
Silver Peak just announced another slant on next-gen vCPE; their Unity EdgeConnect uses the Internet to create secure VPNs that can either augment or replace standard carrier VPNs (MPLS). Their approach lets users employ a single access connection to support the cloud, the Internet, and VPNs. It wouldn’t be difficult to add hosted NFV-ish features to such a model, either.
If the virtual CPE model is based on hosting at the dmarc, then it’s logical to associate it with more versatile edge devices. Logical but maybe not necessary. Any server with the right network card could terminate a carrier connection and be used to host connection-point or network-based functions, of course. Given the fact that operators are looking to replace specialized network devices with servers, it seems inevitable that there’d be interest in vCPE that’s hosted on such a box at the termination point, whoever owns it.
And whoever supplies it. If vCPE is a good idea, if higher-layer services are a good idea, then the dmarc might be very valuable real estate indeed. There’s a lot of stuff that is best done there, either on a transient basis (like “service chaining”, where local function hosting could alleviate massive first-cost problems associated with building cloud data centers for VNFs) or permanently. Firewalls and encryption obviously belong close to the service termination, and voice services benefit from having a local virtual IP PBX locally for intra-facility calls. Application acceleration belongs at the dmarc too, or very close to it. Get a good camel’s nose under the dmarc tent and there’s a lot of follow-on business you could do.
You might even have a lot of carrier partnership opportunities. A lot of cloud services and even advanced network services could benefit from local representation, and the owner of the dmarc device might have a chance to promote deals with network/cloud providers based on their incumbency. If the device vendor could induce the user to take a “vCPEaaS” deal, retaining ownership and management of the edge, then the opportunity could get a lot larger.
Something like this could be a boon not only to Carrier Ethernet companies who have been finding it harder to get into the NFV-and-SDN revolution, but even for consumer equipment vendors. There’s no reason why a Level 2 service interface with multiple L3 terminations couldn’t work with any consumer broadband service model—telco or cable. You could even envision models where a user’s mobile broadband service has multiple virtual terminations, perhaps for direct access to wearables or simply to add service features.
This is where vCPE cuts both ways, in NFV or even SDN terms. Because vCPE could be an agent for services it could promote services by facilitating their use. vCPE, for example, could make services “appear” at a dmarc, a trivial-sounding but essential element in getting user access to those services. I’ve already noted that vCPE could be used as an on-ramp to NFV-type service chaining in the cloud, offering operators a way of providing VNF hosting before they have enough customers to justify cloud data centers. But sometimes the access road is as far as you need to go. vCPE could tap off a significant segment of early NFV opportunity if those VNFs you start hosting in vCPE stay there and never move to a carrier cloud at all. Similarly, SDN services could be terminated in vCPE to make them easy to access, or you could use CPE to create what looked like SDN from legacy service technologies.
“Real” NFV offers broader services, greater agility, and lower mass-cost points, providing that you actually design your implementation to do all of that. As vCPE becomes hotter, proponents of real NFV will have to pay more attention to how to differentiate their expressway from the on-ramp, rather than just promoting the notion of chaining VNFs. And vCPE vendors may make that hard to do, if they learn their own positioning lessons in the crucible of competition. Or maybe they’ll form a common cause. It could be an interesting marriage, or struggle, to come.