white paper - oneaccessthe real market drivers for nfv the initial target of the first nfv white...

NFV Migration: Pure Pragmatism or Pragmatic Purity?

White Paper

+33(0)1.77.71.12.00 | [email protected] | www.oneaccess-net.com2

Table of Contents

3

5

6

6

1311

Single CPE Deployment Models

Side-Car NFV Deployment Models

Conclusion

The Real Market Drivers for NFV

NFV Deployment - Status in 2016

NFV CPE Deployment Models


When you ask most people what NFV means to them, service agility and time-to-revenue are the two most frequently cited answers. These are indeed two of the main end-goals of NFV but on their own they miss a vital and enabling aim: how operators and other communication service providers should go about achieving these benefits. In other words, how can they achieve the operational flexibility that is required in order to successfully undertake and complete the process of migrating network services to a virtualized operational model in a non-disruptive manner.

The Real Market Drivers for NFVThe initial target of the first NFV white paper was appliance consolidation where service agility and capex savings were the two key objectives. Quoting from the white paper summary:

“Network Operators’ networks are populated with a large and increasing variety of proprietary hardware appliances. To launch a new network service often requires yet another variety and finding the space and power to accommodate these boxes is becoming increasingly difficult; compounded by the increasing costs of energy, capital investment challenges and the rarity of skills necessary to design, integrate and operate increasingly complex hardware-based appliances. Moreover, hardware-based appliances rapidly reach end of life, requiring much of the procure-design-integrate-deploy cycle to be repeated with little or no revenue benefit. Worse, hardware lifecycles are becoming shorter as technology and services innovation accelerates, inhibiting the rollout of new revenue earning network services and constraining innovation in an increasingly network-centric connected world.”

NFV Introductory White Paper, Oct 2012

Thus standard hardware would accelerate procure-design-integrate-deploy cycles with the associated benefit that running multiple network functions on COTS (common-off-the-shelf) platforms would lead to significant hardware savings

Procure

Design

Integrate

Deploy

Appliance or function consolidation in the POP or data center is clearly a desirable objective but many functions belong at the customer premises and hybrid-WAN connections re-inforce the need to keep many of them there. Yet applying the idea of appliance consolidation to the customer branch raises a distinct conundrum: numerically few customer sites actually need such consolidation. According to operator estimates shared with OneAccess, the vast majority of enterprise branch office sites, circa 95% in Europe and 80% in North America (excluding separate voice gateways), have just a single appliance or customer premises equipment (CPE) - an enterprise router.


Nonetheless, many large network operators are targeting NFV and in particular NFV management at all their enterprise customers. Why is this? Because in so doing, they are looking to dramatically accelerate service testing and deployment cycles for the network functions contained within ‘a typical CPE’. Here, they see a significant opportunity to realize opex savings and protect future revenues. The thinking here is simple: the sooner you can deploy a customer service, the sooner you can charge for it. What’s more, deploying quickly reduces the risk of your customer being lured away by a competitor’s offering simply because it is available (or deployable) before yours. NFV also provides an opportunity to upsell services that would have previously been cost-prohibitive if an additional appliance were needed. This confirms that the operators’ real drivers to NFV are service agility and time-to-revenue.

NFVRationale

Accelerate service testing

& deployment

cycles

Opex savings

Deploying quickly reduces

risk

Opportunityto upsellservices

Serviceagility

$

Both appliance consolidation and service agility require abstracting network functions from the underlying hardware and the path to do this is via a white-box CPE. Yet a big issue that many operators are wrestling with is that a typical white-box CPE, based on any of Intel’s X86 CPU families, is significantly more expensive than the enterprise router CPE deployed by operators today.

As a result of this disjuncture, some innovative ideas concerning operational deployment are being reviewed and discussed by these operators with their vendors. This need for different deployment models and considerable operational flexibility to support different migration paths to virtualization is the main subject of this white paper.


NFV Deployment - Status in 2016One of the key developments in the move to virtualization is the focus on CPE deployment models for the initial launch of services. This is an interesting and initially counter-intuitive development as the biggest opportunity for savings supposedly comes from a more centralized operational model where VNFs are mostly run in data centers or, more likely, multiple data centers at major or super-POPs distributed around an operator’s network. To date, the centralized model has not been the initial deployment focus for a variety of reasons:

• CAPEX: there are significant up-front Capex costs that need to be incurred in order to roll out a centralized NFV model. Depending on the size of the operator network anywhere between 10 and 30 super-POPs need to be initially built to provide the necessary coverage to roll out a nationwide service. Getting sign-off for the necessary level of investment to achieve service launch is proving difficult to achieve, particularly when there are many technical, scalability and ROI issues still to be solved. As a result, building this centralized capability

now remains a leap of faith in NFV’s ability to eventually deliver measurable commercial benefits and transformative cost reductions. A more detailed discussion of the economic issues with centralization is provided in the Thin-CPE section below.

• MANO Maturity: one of the key blocking elements is delivering a viable system for virtualized management and operations (NFV-MANO). All the operators are struggling to achieve this and finding that the available technology components have varying levels of maturity and interoperability issues to address. The preferred open-source components for implementing MANO (typically OpenStack) still have gaps to fill, in particular for:

- Scalability, where OpenStack can effectively manage no more than 500 computing nodes- Modifications to insert new VNFs into the service chain- The avoidance of “start-up storms”- OpenStack security over the Internet- Backwards compatibility- Troubleshooting

Despite showing signs of progress and development, the bottom-up approach taken by the open-source community is only yielding incremental and slow results. The issues are being resolved but BT1 and others doubt that OpenStack is yet carrier-class.

• Lock-in Avoidance: one of the issues is that operators want to remain in control of NFV-MANO. Given its strategic nature, they want to guarantee openness and avoid vendor lock-in. As a result they are typically doing the integration work themselves in an environment where the appropriate skills are in short supply internally and where additionally there is very little deployed reference code to work from available elsewhere.

• Scalability Issues: leaving aside the much higher scalability requirements of residential services, enterprise services still need to achieve a level of scalability and multi-tenancy that does not require inordinate amounts of compute and memory resources. The use of containers is one way forward but by itself this approach is insufficient - additional multi-tenancy support will be required from the VNF vendors to make their use viable

in data centers. Yet if multi-tenancy is the route forward for high levels of scalability this raises other issues such as service function chaining and service elasticity for individual or groups of tenants within a container or VM. In addition, OpenStack as mentioned above also needs to add at least three orders of magnitude in terms of scalability for enterprise services.

1 Peter Willis, BT at SDN & Openflow World Congress, October 2015

$


• Traffic Engineering: most of the control plane for enterprise services was previously located at the CPE level. Implementing VNFs at the data center or network edge requires careful attention to designing the network to cope with the additional traffic flows, latency and privacy issues generated by a more centralized control plane.

For all these reasons, the operators who are under considerable pressure to show progress in their virtualization efforts, have focused their initial service launches on the more manageable problem of rolling out CPE that can be managed in a virtualized manner. Their pragmatism has led to a number of different deployment models being explored as listed below.

NFV CPE Deployment ModelsA range of single CPE deployment models are described below. A separate section further down describes the innovative use of side-car deployments (two-boxes in effect) to address cost and legacy issues.

Single CPE Deployement ModelsNETCONF - enabled Classical CPE

A major issue is what to do with the installed base at operators and, more importantly, how to manage the transition to next-generation management systems based on NFV principles. Today’s installed base of CPEs is mostly provisioned with either CLI scripts or TR-069.

Adding NETCONF to an existing router is in most cases not feasible. Support for the protocol itself is relatively easy but NETCONF is all about manipulating service elements and network objects using a data-model with the use of YANG for network elements being preferred by almost all operators. This not only requires a new management framework that has been designed to support NETCONF/YANG but also more memory and storage resources than most classical CPE have been shipped with. As a result, with some exceptions, an upgrade of the installed base of CPEs is not feasible.

An approach, pioneered by OneAccess, is to provide classical CPEs with integrated NETCONF/YANG support. Thus the diversity of network interfaces (DSL, 4G, fiber, TDM, etc.) can be supported, integration with next-generation OSS components that require NETCONF support is assured, and above all the network-processor-based design delivers the same cost-effective CPE platforms as previously. The network functions can be controlled with NETCONF but they are in this case PNFs. This has less flexibility than the X86 white-box CPE approach and as with gray-boxes does not deliver network functions abstraction but is dramatically more cost effective. Fully virtualized network functions (VNFs) can be added to this model either from the data center or using the side-car approach described in a separate section below.


To facilitate migration, OneAccess delivers its NETCONF-enabled CPE with joint CLI and NETCONF support where there is equivalence between CLI and YANG objects. This means that not only can the CPE be migrated to next-generation OSS (NFV-MANO) at the pace the operator is able to sustain, but that the eventual migration of service descriptions is greatly facilitated. These two capabilities provide a level of future-proofing that is extremely attractive for operators who are reluctant to jump on the white-box CPE bandwagon and provides a smooth and low-impact path to virtualization.

Gray-Box Deployments for Early-Bird Virtualized Services Launches

The first real NFV deployments for enterprise services in 2016 and early 2017 are centered around a so-called ‘gray’-box. This is a box that can run X86-based VNFs but where many network functions remain dependent on specialized hardware, i.e. they are physical network functions (PNFs). In effect, a PC server has been inserted inside a classical CPE or chassis design and the box is managed as one entity. The emergence of this deployment model has been dictated by availability and pragmatism. The most well-known example of the gray-box is the NFX250 from Juniper, which was early to market with this approach and it has enabled operators to move swiftly and show progress in implementing virtualization. Both AT&T and Verizon have initially chosen gray-boxes for their initial ‘universal CPE’ deployments alongside hosting a number of VNFs from other vendors.

What is clear is that the gray box is being used as a stepping stone to get some skin in the virtualization game and ensure that some of the operational functions of delivering virtualized network services can be tested and refined. The use of gray-boxes however goes against the principle of abstracting all network functions from the hardware and undermines both the openness and service agility goals cherished by the operators. It is also an expensive deployment model as you need two processors (a network processor and an x86 CPU) in the box. Nevertheless it is a proof-point for delivering at least some services in a virtualized manner.

White-Box CPE for Appliance Consolidation

If the gray-box has been used for pragmatic reasons, the purer and certainly more attractive deployment model for operators is to look for a genuine white-box CPE where the software and network functions are fully abstracted from the underlying hardware. This approach is often referred to as the ‘Thick CPE’.

Many of the procurement discussions surrounding white-box CPE have involved whether to seek out bare-metal server boxes and to build or license the on-board hosting environment for VNFs (the cheapest way forward in terms of CAPEX) or alternatively to buy a pre-integrated platform where the underlying x86 hardware and hosting middleware are sourced from one vendor to minimize integration and trouble-shooting efforts. The majority preference by the operators is for the latter model though they remain keen to retain the option to buy the components independently or to be able to port a best-of-breed hosting middleware to other platforms.


Most of the established networking vendors have committed to providing white-box CPEs in the future and some are already available. There are also a number of white-box specialists that have delivered products for Cloud deployments and who can provide x86 appliances that can fulfil the CPE role.

The larger operators are looking to source up to five categories of white-box CPE with varying degrees of compute, memory and storage resources depending on the number and weight2 of VNFs they intend to deploy. A recurrent requirement is to integrate basic routing and switching requirements in the middleware of the white-box CPEs so as to leave a maximum amount of cores and memory for other VNFs3.

Cost nevertheless remains a major issue. White-box CPEs, although cheaper than an equivalent gray-box CPE, are more expensive to procure than classical CPEs in terms of comparable performance and network functions. In particular, if an operator wants to use VNFs that require acceleration mechanisms they need to procure appliances with more expensive Intel CPUs and/or hardware add-ons. Although, Intel is making CPUs available that better meet operator needs (especially with the new Denverton NS range), the reality is that Intel has a monopoly in this field and, until the ARM vendors can provide an effective competitive response, will seek to maximize its wallet share from NFV deployments, which today certainly and even in the next few years will remain a low volume business for them.

Thin CPE

The Thin CPE model has been touted as the purest form of virtualization; it combines the following characteristics:

• As the name implies, the CPE deployed is minimalist and focuses on transport and connectivity functions - as a result it is cost effective to deploy both from a CAPEX and truck-roll perspective.

• Software functions are hosted in the distributed data centers or super-POPs in an operator’s network. This is a highly scalable and resource-efficient approach as multiple clients can share expensive infrastructure elements.

• Trouble-shooting and service assurance is greatly facilitated as experts can gain quick and easy access to the virtualization infrastructure and its hosted components.

The Thin CPE is different depending on the market segment addressed.

One of the areas of focus for the Thin CPE is the Business Ethernet market. As today, the Ethernet Access Device (EAD) or Network Interface Device (NID) acts as the demarcation point between the carrier’s network and the customer premises wiring. What changes is the EAD/NID is managed using next-generation protocols such as NETCONF and OpenFlow or a combination of both. Additionally many, if not all of the network functions move from the customer premises to the

2 ‘Weight’ here is used to describe the amount of processing, memory and storage resources needed by a VNF3 Based on white-box CPE RFPs received by OneAccess and associated discussions with operators


carrier’s data center, either in a virtual private Cloud or directly managed and charged for by the carrier. Previously these network functions were provided by an enterprise router at the customer premises (often procured and managed directly by the customer). This provides a great opportunity for carriers that provide Business Ethernet services to increase wallet share at their customers by increasing the number of functions provided for and managed, or at least hosted, by the carrier. As an aside some of these Thin CPEs are actually light-weight Thick CPEs, where certain network functions can and need to be hosted on the EAD itself, e.g. tunneling, link management, OAM, etc.

A lot of attention has also been placed on the residential market segment where low cost delivery platforms can transport TV, Internet and voice services to consumers from the data center. The Broadband Forum has been active in this area, releasing in July 2016 its TR-317 document that specifies a Network Enhanced Residential Gateway architecture making the case to move network functions to the data center as well as accommodating both new and existing residential services (Internet access, IPTV, VoIP, VoD, WiFi). In essence the residential gateway is split into two components, a customer located Bridged Residential Gateway (BRG) and a network located virtual Gateway (vG), where in particular NAT and firewall services are placed. Other issues such as IPv6 migration, downstream QoS for high-value services and M2M are also addressed in the document.

The biggest issue to address for the Thin CPE deployment model is scalability. In order to realize the desired resource efficiencies at the data center, the maximum amount of resources needs to be shared. Yet the overhead of deploying one VNF per customer or even one container per customer leads to the need to build very large and thus expensive server farms to host customers. In short, resource efficiency is mitigated by the currently envisaged deployment models.

An approach OneAccess has demonstrated is to enable high-density multi-tenancy within a virtual machine (VM). Thus within the VM a large group of tenants share the same resources maximizing infrastructure usage. This however engenders its own set of problems:

• How do you manage service life-cycles for individual tenants within the VM?

• How do you implement service function chaining, i.e. ensure that different service maps and associated network flows are set up and managed for those tenants? The alternative is configuring routing rules for individual tenants, which quickly becomes unmanageable.

• How do you ensure service elasticity, i.e. the ability to move tenants or groups of tenants to different VMs on the same server or on other servers for maintenance, performance or load issues?

To address these issues, OneAccess is building high-density multi-tenant VNFs along with the appropriate handles to easily manage these tenants, i.e. create or stop individual tenants, deal with their specific service function chains by incorporating service function classification and forwarding functions, as well as the capability to migrate tenants across VMs without service interruption.


So far, our discussion on the Thin CPE model has focused on technical and specifically resource management issues. There still remain a large number of economic issues to address, which together have frankly stalled the Thin CPE model at many carriers. These can be summarized as follows:

TimingFor traffic engineering and latency reasons it makes sense to decentralize the data center and ensure customer proximity. The big question is can sufficient additional revenues and/or cost savings outweigh the high up-front costs.

Why Install a White-Box CPE and then also centralize network functionsSome operators are asking themselves the question that if they are obliged to install a generally more expensive white-box CPE anyway (thick or one of the other models discussed), what‘s the point of centralizing lots of network functions to a data center. In effect two new sets of compute resources have to be paid for.

White Box

Cost of Building Data Centers or Super-POPsGiven the scalability challenges and the immaturity of the NFV-MANO is this the right time to centralize. Many operators have openly stated: let’s see what the others (e.g. AT&T and Verizon) do first and then assess or copy. But AT&T and Verizon are going down the white-box CPE route first anyway.

What Network Functions to Locate ThereThere seems to be general agreement that the high processing requirements of some security functions require centralization. And then? Apart from some basic network services such as NAT, it is far from clear what else should be centralized. As enterprises embrace hybrid WAN deployments then the need to keep many network functions on the customer premises only increases.


Side-Car NFV Deployment ModelsTo help address some of the cost and legacy issues operators face, OneAccess has introduced the concept of side-car deployment models for NFV. Rather than deploy an expensive gray box or in order to avoid over-deployment of expensive but largely unused white box CPEs, these two-box approaches enable the most cost-effective deployment of CPEs, whilst delivering flexibility and next-generation APIs for NFV orchestrators.

Slim White Box for VNF Upsell

Despite a recent intensification of efforts to deploy fiber to the curb or premises, driven by falling fiber cabling and component prices and reduced installation times as result of new techniques, copper connections remain a large and often the majority connection media for businesses at most large operators.

A DSL-capable white-box CPE does not yet exist and in any case would be substantially more expensive than a classical CPE with a DSL interface. Realizing the DSL or 4G interface with an SFP dongle or add on card is possible but such a solution does not solve the underlying economic issue described immediately below.

The real problem though is that operators estimate that among their volume customers, most of which have large numbers of sites connected with DSL, only between 10 and 20% of them4 are likely to upgrade to add-on services from their VNF catalog. So the question that follows is: why equip the whole installed base with more expensive white-box CPE, with the extra compute, memory and storage capacity to host additional VNFs, when only a minority of their customers actually require that capability?

A cost-effective solution in this context is to deploy two boxes – a classical CPE that provides the DSL network interface, with optional 4G for resiliency, plus a small white-box CPE to host one or two modestly sized VNFs. The small white-box CPE operates in side-car mode to the classical CPE, but critically the two boxes can be self-installed and then managed as a single entity. This approach can realize significant savings as the 80% of customers that do not need VNFs are serviced with the most cost-effective solution and the 20% or so that select additional VNF-based services can be upgraded with an add-on capability with the required flexibility and resources.

There are three technology elements required to support the effective implementation of this approach:

1. A NETCONF-enabled classical CPE (see above) for seamless management.

2. A self-install procedure to associate the small white-box CPE with the classical one for ease of upgrade and install.

3. A management architecture that represents the dual-box solution as a single management entity.

4 Estimate provided by a leading European operator


NETCONF-enabled Voice Gateway

The push for NFV has been mainly driven by the incumbent local exchange carriers (ILECs) and they are still very much in the vanguard of testing and deploying this technology. On the other hand, the ILECs have the most legacy to deal with, where large numbers of their customers connect TDM voice equipment or analog systems to operator-provided CPEs. To accommodate this requirement, voice gateways or enterprise routers with a range of TDM interfaces have been extensively deployed by the operators, especially the ILECs.

Yet if supporting DSL in a white-box CPE environment can be described as problematic, it is even more so for TDM.

To address this issue OneAccess has also remodeled its software to support TDM and analog interfaces in a NETCONF environment with associated YANG objects and CLI command equivalence, as well as TR-069 support. In a ‘mirror-image’ of the dual-box approach with a slim white-box CPE, the NETCONF-enabled voice gateway can be operated in side-car mode to a white-box CPE. This means the fully abstracted approach for VNF deployment in a white-box CPE can be maintained and then combined with a cost-effective deployment model for legacy connections. The support of current and next-generation APIs ensures compatibility with current management systems and seamless migration to future NFV orchestrators via NETCONF.

Note that a key difference between the two side-car approaches is in where the routing function resides. In the NETCONF-enabled gateway the routing capability resides in the white-box CPE, either as a separate VNF or integrated into the hosting middleware to preserve resources for other VNFs (see above); in the ‘slim’ white-box approach the routing resides in the classical CPE.


ConclusionThis white paper has concentrated on the virtualized delivery of enterprise services and the diversity of solutions available for VNF and CPE deployments. It’s still early days in the journey to centralized network functions – AT&T (which has the most aggressive distributed data center program), DT and others are committed to building out distributed data centers but none are operational yet and field experience is scarce. What’s clear is that those operators that are looking for first-mover advantage (principally AT&T and Verizon) are focusing first on gray box (because that’s what is integrated into their systems already) and then white-box CPE-based service launches subsequently. What’s driving them in this direction is their ambition to increase wallet share at their large enterprise customers, many of whom build and manage their own networks today.

What is also clear is that there are now a variety of deployment options available to operators that will help them migrate to a full virtualized management and operations system with greater or lesser levels of virtualized delivery of network functions.

Economic pragmatism is the underlying driving factor behind the ultimate choices an operator takes and the speed at which they are implemented. Most, of course, will employ a mix of approaches. Rip and replace is an option open to few and a careful and calibrated migration path is needed, taking into account the following factors:

The age or size of the installed

base

The amount of DSL copper connections that need to be accommodated

The extent of TDM and analog legacy connections to be

accounted for

?

What all operators require is a large degree of operational flexibility, with the ability to flex their market offer to meet their own specific market requirements and to accommodate the introduction of new management systems (almost always a slow process), as well as their equipment refresh cycles to avoid unnecessary expense.


The value that OneAccess can offer in helping to operators to undertake

their journey to virtualization can be summarized as follows:

02

04

06

07

05

03

01

A genuinely pragmatic approach to service migration that in particular enables both the timing of the move to virtualized delivery of services to be chosen and its complexity to be minimized.

A range of pre-integrated CPE - virtualized, classical platforms and a combination of both - to accelerate the virtualized delivery of services and maximise connectivity options.

An open, multivendor approach that avoids vendor lock-in.

A broad choice of network functions to be deployed (VNF or PNF), which are compact, scalable and in the case of VNFs optimize use of data center and white-box CPE resources.

A wide choice of deployment options that enables the most economic path to be navigated depending on the type and amount of legacy connections to be accounted for.

An innovative approach to dealing with some of the scalability and service function chaining issues in the data center.

Ease of management with a wide range of classical and next-generation APIs: NETCONF/YANG, REST, SNMP, TR-069, GUI.


The AuthorPravin Mirchandani joined OneAccess Networks as Chief Marketing Officer in 2011 and currently leads the product strategy, product management and corporate communications functions for the company. Pravin has developed the company’s innovative SDN / NFV strategy based on service migration and introduced the concept to operators across the globe. In addition he regularly blogs on the subject of SDN and NFV and is often featured in thought-leading articles in the industry press.

A graduate of both the University of Edinburgh and the London School of Economics, Pravin has over 25 years’ experience working in key roles in major telecom equipment manufacturers and software vendors including Bay Networks, Nortel, Orchestream and Codima Technologies. Before joining One Access, Pravin was CEO at Syphan Technologies UK, an innovative organisation providing security services to managed service providers.

ABOUT USOneAccess, an Ekinops company, is a leading provider of physical and virtual network functions enabling the delivery of Cloud and other managed services to SMB and enterprise customers around the world.

Our programmable and highly scalable solutions enable the fast, flexible and cost-effective deployment of new services for virtualization-enabled managed enterprise services. OneAccess offers a wide choice of physical and virtualized deployment options for layer 2 and layer 3 network functions.

As service providers embrace SDN and NFV deployment models, OneAccess’ solutions enable them to deploy traditionally managed services today in the knowledge that they can seamlessly migrate to an open virtualized delivery model at a time of their choosing whilst avoiding vendor lock-in.

A global organization, with operations in 4 continents; Ekinops (EKI) - a public company traded on the Euronext Paris exchange - is headquartered in Lannion, France, and Ekinops Corp., a wholly-owned subsidiary, is incorporated in the USA. OneAccess is a wholly-owned subsidiary of Ekinops S.A.

Phone: +33 (0)1.77.71.12.00 Fax: +33 (0)1.77.71.13.00

OneAccess 13 avenue Morane Saulnier 78140 Vélizy - France [email protected]

www.oneaccess-net.com

Fast Network Virtualization

https://www.linkedin.com/company/oneaccess

https://www.youtube.com/user/OneAccessNet

https://twitter.com/oneaccess

http://www.oneaccess-net.com/blog

mailto:marketing%40oneaccess-net.com?subject=

http://www.oneaccess-net.com/

mailto:marketing%40oneaccess-net.com?subject=Request%20Information

http://www.oneaccess-net.com

white paper - oneaccessthe real market drivers for nfv the initial target of the first nfv white...

Documents