Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

The evolution of Carrier Ethernet service chaining offers new options

Operators looking to service chaining for Carrier Ethernet must assess both the issues and opportunities for use via NFV or as hosted network edge services.

Network functions virtualization (NFV) has captured operators' attention and support because it offers the possibility of reducing costs and increasing revenue at the same time. One of the principle focuses of early interest in NFV has been in using service chaining to create enhanced business services by adding hosted functions in succession because they can replace or augment traditional business wide area network (WAN) service gateway features.

While the service chaining model is important, it must address issues and opportunities for Carrier Ethernet beyond the service chain. Service chaining is an element of NFV describing a linkage of connected virtual network functions (VNFs) to provide service features that would otherwise have been offered in an appliance or device. In theory, a service chain could be part of any NFV-based service and could include any sort of VNF. But the most common example of service chaining comes from Carrier Ethernet, where many vendors are proposing to host service-edge features from DNS and DHCP to firewalls, monitoring and even virus scanning inside the cloud instead of on the customer's premises.

Virtual CPE and service chaining are popular with operators, as well. Some studies show that pulling features back into the cloud would reduce the need for on-site technicians to install them, shorten deployment times to accelerate time to revenue, and reduce support calls created when customers set up their own local devices. VNFs and cloud hosting could also be less expensive than deploying custom devices, which would lower Capex.

Adding features to existing sites is a clearer revenue opportunity than providing the same features a different way, which is useful to the buyer only if it's cheaper.

The value of NFV's service chaining and vCPE isn't in question, but just how much revenue providers would generate and how much they'd save is difficult to assess because of the scope of current proof-of-concept demonstrations and NFV trials. One of the problems is that the operations and management details on NFV are scarce at this stage, so it's hard to assess what it would actually cost to operate service chain-based Carrier Ethernet services. Another problem is that the cost of hosting virtual functions depends on the overall efficiency of the cloud resource pool, which depends on its size. In early deployment, resource pools large enough to be efficient will be underutilized for a period of time before demand grows enough to fill them with revenue-generating VNFs.

Carrier Ethernet VNF model includes edge-host options

One interesting alternative to classic service chaining is to host service VNFs in a server or appliance on the customer premises rather than in the cloud. Supporters of this model point out that since something has to be installed to terminate a Carrier Ethernet connection, if that something had a board or other facility that could be loaded with VNFs from an NFV resource, all of the agility benefits could be obtained, and operations complexity could be reduced.

If the goal is to create agile services to extend basic Carrier Ethernet, it may not even be necessary to adopt NFV to support this edge-host model. Vendors that supply an on-premises device that can support loading and running features could also provide their own management tools to deploy those features. This would create a "hosted function" in a general sense rather than NFV's virtual network function, and it could be done today without any incremental investment in NFV. The question operators have to ask regarding Carrier Ethernet service evolution is where they think that evolution should go. Certainly adding features like network address translation, DNS and firewalls has value. But many companies already make these features available as part of customer-located equipment provided either by the operator or as part of their own network. Displacing existing technology is always difficult, so the question is, would it make more sense to focus on adding features not already supported?

Extensions for Carrier Ethernet services to build ARPU

Service chaining and NFV can be helpful even for old services where the operator has evidence that high costs (which force higher prices) or deployment delays inhibit the acceptance of the service. In either case, the impact of service chaining should be assessed carefully to ensure the previous service technology -- CPE-based in most cases -- is really causing a problem and that service chaining can address it sufficiently to make a difference. This may require careful lab testing and even a field trial.

Some operators believe that since Carrier Ethernet users are primarily enterprises, the best way to augment average revenue per user (ARPU) would be to offer them cloud services, either in the form of public cloud hosting (IaaS) or application services (SaaS). If operator cloud services appear to be part of a Carrier Ethernet network, they would be as accessible as the company's data center resources. Surveys suggest that operators are generally considered credible cloud providers, but exploiting that favorable mindset may take a sales and marketing effort on the carrier's part.

Even some communications services could be seen as extensions to Carrier Ethernet. Email hosting, Web hosting, and unified communications and collaboration services could all be made available as virtual sites on a company's Carrier Ethernet network. These services don't require service chaining or NFV, but these new approaches could again reduce operator costs and let them price the services more competitively.

Where an NFV focus is desirable because the operator has a long-term commitment to NFV, it might be better to position service chaining as a new service set augmenting either premises function hosting as described earlier, or even CPE or CLE. Adding features to existing sites is a clearer revenue opportunity than providing the same features a different way, which is useful to the buyer only if it's cheaper. The operator could then evolve the customer relationship from a hybrid premises-cloud service feature hosting model to a pure NFV model over time, adding vCPE when a service disruption could be justified and when overall carrier profits from the vCPE model were clearly demonstrated.

Whatever an operator's revenue goals may be, it's important to remember that service technology only enables the service; the service sales generate new revenue. Whether a new revenue opportunity is truly new or is based on presumed lower operator costs supporting lower price points, don't ignore the market testing.

Next Steps

NFV to transform provider clouds and architectures

NFV gives dedicated hardware a run for its money

Why virtual network functions are at home in the enterprise

SDN could drive Carrier Ethernet growth

This was last published in May 2015

Dig Deeper on Telecommunication networking