The Dawn of Virtual CPE

This Industry Viewpoint was authored by Dr. Yuri Gittik, RAD

If service providers hope to meet the challenges of automated, speedy, and profitable service delivery, they need networks that are agile, efficient, and well orchestrated. Programmable networks – now viewed as a must for providers – is the driver behind the acceleration in network function virtualization (NFV) and software-defined networking (SDN).

Infonetics Research estimates carriers will be spending up to $11 billion on SDN and NFV by 2018, with NFV representing most of that. The organization’s 2014 survey found that 93 percent of service provider respondents plan to deploy NFV in some aspect of their network. Virtual customer premises equipment (vCPE) for business services was the top rated use case.

What is vCPE, Anyway?

With virtualized CPE, at least some of the networking functionality associated with conventional customer premises equipment is virtualized and possibly moved to other network locations. But even as virtualization involves relocating some functionalities from the customer premises to data centers, the computational power in the CPE pulls in the other direction, enabling relocation of other functionalities from deep in the network to the customer premises.

The business vCPE (also known as the vE-CPE, with the E for enterprise) is a virtualized networking appliance at the customer edge that delivers communication services to enterprises. What has been a collection of single-purpose, hardware-based devices – such as a router, load balancer, or firewall – at each customer location has been transformed. In the vCPE model, virtualized appliances can be dynamically added or dropped to a single physical device as needed.

Physical and virtualized vCPE functions are divided between the customer site and the “provider edge” of the network, typically the data center. This ensures maximum flexibility and performance, especially since the network-located functionality can also be shared among multiple tenants.

It isn’t surprising that vCPE is seen as the ideal candidate for testing the NFV and programmable network concepts. Enterprise equipment tends to be both CapEx and OpEx intensive, and these costs have a significant impact on network operations. This can severely limit a service provider’s ability to roll out new services quickly, or make timely service modifications and upgrades.

Conventional, appliance-based CPE involves slow, expensive deployment processes, which are no longer acceptable in today’s market. Thus NFV-enabled vCPE is a logical choice for service providers, holding out the promise of increased revenues and lower total cost of ownership.

Implementing vCPE

The vCPE architecture combines physical and virtualized entities at the customer premises and elsewhere in the network, such as at the data center or local aggregation point. That raises three key issues for service providers when it comes to implementation:

• Minimal required functionality at the handoff point. Although virtualized CPE functions may run on virtual machines in the cloud, some basic data forwarding and service demarcation and termination capabilities are still required at the customer site. The customer-located physical CPE must include at least a simple switch with essential forwarding functionality, as well as xDSL or cable modem functionalities in many cases.

• Virtualization, or not? While there are network functions that may be virtualized and relocated to the cloud, others should remain embedded in the CPE. Typical examples, particularly for high access rates, are data-plane functionalities, such as packet forwarding, traffic queueing, and prioritization. This will affect the physical CPE architecture.

• Location, location, location. Different physical and virtualized functions can be service chained regardless of location, but there are often speed and performance advantages when they stay within the same location/device. Such implementations can be hybrid, using both physical and virtualized resources. In one hybrid model example, an applicationawareness functionality might use a deep packet inspection engine as a virtualized control plane located in the network, with hardware-based forwarding and flow marking functionalities to ensure wire-speed operation at the customer site.

Three scenarios help to illustrate the issue of where vCPE functionalities should reside.

First, using only a basic switch/router as the physical device at the customer premises, while all virtualized functions reside at the data center. Service providers can choose between deployment of a vendor-specific, integrated vCPE software package featuring a pre-selected set of related service applications, and service chaining of individually-sourced network functions. The most likely use of this approach would be in the smaller enterprise services market, where speeds and performance requirements can be fully supported by cloud vCPEimplementation.

Second, placing both physical and virtualized vCPE functionalities at customer sites, with no virtual functions in a central network location. A network interface device with an integrated computing platform could act as the NFV infrastructure. Alternatively, a standalone server can be co-located with the NID, although this wouldn’t help with either per-application traffic handling or traffic offload for hardware-based processing.

Third, placing virtualized functions wherever their performance, cost, and policy compliance are optimal – either at the customer edge or in the network. In this scenario, functions residing in different locations can be dynamically ordered, configured, and chained to meet customer business needs.

The second and third scenarios here are examples of a distributed approach to NFV, placing virtualized functions where it makes the most functional and economic sense, whether at the data center, POP, or the customer edge. This approach is particularly well-suited to value-added services characterized by high networking costs and stringent performance requirements. Placing at least some virtualized functionality at the customer location can avoid bandwidth inefficiency and application performance degradation.

Unintended Consequences

Relocating functions could affect service quality, so service providers have to weigh these issues:

• Bandwidth efficiency. What is the bandwidth “cost” of moving functionality deeper into the network? Excess bandwidth expenditures could degrade service delivery in areas still served by relatively low-speed connections such as DSL.
• Security. Does moving a function to the network expose sensitive end user data? For example, an encryption application located anywhere but at the customer premises won’t provide adequate protection, as traffic interception can occur en route in an unsecure access segment.
• Survivability. Critical functions must remain operative even when the access link is down. Hosting IP PBX or router functions at a data center, for example, might mean an inability to locally handle calls or deliver traffic in a network failure.
• Application performance. Is network-added delay acceptable? This is a critical consideration when engineering delay-sensitive workflows. In some cases, function relocation can harm performance due to inadequate access link bandwidth or excessive delay. A firewall, for instance, might be affected by frequent session timeouts due to packet loss and reordering as traffic travels farther.
• Diagnostics and QoE: Testing and troubleshooting applications need to accurately measure link and end-to-end service quality, as well as localize faults, starting from service handoff. If done at a data center, it may make it hard to determine the cause of performance and traffic handling issues.

Looking Ahead

We are on the verge of seeing a multitude of vCPE options being streamlined to fit a variety of practical use cases at the service and operations levels. In addition to function placement and end-point device capabilities, much of the industry’s attention will be focused on management and orchestration. This orchestration may also enable dynamic relocation of functions to provide optimal QoE based on factors such as changing network loads, which changes the way the issues above need to be considered.

The trend towards programmability and automation in the network makes the case for use of SDN principles when implementing vCPE solutions.

Current vCPE implementation options generally presume manual provisioning of functions alongside various proprietary virtual networking mechanisms. The next evolutionary phase will address automation of connectivity and optimization of function selection and placement. This does not necessarily require the deployment of SDN switches at the customer premises as long as existing equipment can be configured by the new orchestration platform.

Especially for business services, vCPE is a prime candidate for initial commercial deployment of NFV. It offers hardware abstraction and the promise of shorter and more flexible deployment cycles for new services. As the programmable network becomes a reality, much of the industry’s focus is turning to automation and control. Over time, vCPE will move from loose couplings to integrated entities, with management functionalities increasingly part of a dynamic control plane.

Dr. Yuri Gittik heads Strategic Marketing for RAD Data Communications, a leading global provider of Ethernet systems and other network access equipment. Contact him at yuri_g@rad.com.

 

If you haven't already, please take our Reader Survey! Just 3 questions to help us better understand who is reading Telecom Ramblings so we can serve you better!

Categories: Industry Viewpoint · NFV