state of virtualization 9

7/23/2019 State of Virtualization 9

http://slidepdf.com/reader/full/state-of-virtualization-9 1/20

Evaluating

“The State of the State”

of Virtualization



3

Welcome to “The State of the State” – a special report from Light Reading and

Heavy Reading providing original insights into the changes taking place as

CSPs plan their migration to next-generation communications infrastructure.

We know that the entire communications industry is entering a period of

incredible disruption – one driven by virtualization, open-source standards,

white-box deployments and OTT service delivery.

The information in this package provides both qualitative and quantitative

analysis of how these technology change agents are impacting CSPs,

including changes to the way they are planning their network configuration,

the impact to their investment and supplier choices and how service

providers’ specific procurement criteria is changing in the face of new

service requirements.

As Patrick Donegan, Heavy Reading’s chief analyst, points out in his report,

“New Requirements for Network Equipment Vendors,” many of the attributesof next-gen CSP networks already exist in high-end “cloudified” enterprise

networks. This is prompting CSPs to look for new attributes in their

equipment suppliers, including both IT and systems integration experience.

Our survey of more than 130 service providers contains some genuinely

fascinating insights into their plans. For example, we now know from the

service provider survey that more than half of all CSPs are still at the stage of

researching virtualization, but 100% of them know they have no choice other

than to make the move to NFV eventually.

The payoff for doing so will be agile, virtualized networks that allow them to

reinvent themselves as services innovators, building and launching profitablenew applications and services at will. And the pressure is on them to make

this move before their last-generation networks and business models are

rendered obsolete by new competitors. At the same time, our report shows

that CSPs clearly recognize the migration must be made in an orderly fashion,

and in a way that doesn’t disrupt or destroy existing revenue streams.

Disruptors come in various sizes and forms – and some from perhaps

unlikely places. I’m hoping these findings start some very interesting

conversations this week.

Steve Saunders

Founder & CEO, Light Reading



4

New Requirements for Network Equipment Vendors

Communications service providers (CSPs) have wrestled with the problem of flattish revenues and rising costs

for many years. As colossal increases in data traffic, particularly video, have laid siege to the CSP network

infrastructure, waves of technology innovation in optical networks, L2 and L3 IP/ Ethernet technologies, high-speed

broadband, as well as 3G and 4G mobile networks, have repeatedly succeeded in averting looming crises on the cost,

as well as the revenue side of the equation.

But however critical these and other technology innovations have been in the fortunes of CSPs over the last decade,

management in these companies, as well as investors, are keenly aware that, for the most part, what they have

done is enable CSPs to avoid a marked decline in their financial performance. Generally speaking, these innovations

have enabled CSPs to sustain their mainly flat business trajectories. These innovations typically have not served as

a platform for CSPs to accelerate their way out of their current predicament and onto a significantly higher level of

financial performance.

In the meantime, over-the-top (OTT) providers have captured the lion’s share of new revenue from new content and

applications. Bearing a fraction of the huge capital costs and regulatory obligations that the CSPs are shackled with,

these companies have enjoyed very much better revenue and margin performance.

A New Trajectory for CSPs

Hopes of breaking free from the current at trajectory are increasingly being pinned on a root and branch

transformation in the way that CSPs use the communications hardware and software that supports their businesses.

CSPs are looking to leverage software-dened networking (SDN) and network functions virtualization (NFV) to provide

a sharp and sustainable uplift to revenues via greater service agility. They also expect SDN and NFV to radically reduce

network costs via commodity hardware and software-driven automation. Some leading CSPs go as far as to describe

this NFV and SDN-led transformation in their business as nothing short of “becoming a software company.”

Figure 1: Status of NFV Deployments in CSPs Worldwide (December 2014)

Proof -of-concept

(PoC) stage

In trials

Alreadydeploying NFV Not interested in NFV 0%

Early stages oflearning aboutNFV (pre-PoC)

54%

10%

19%

17%

Source: n=79 service providers. Heavy Reading Survey on Carrier SDN, December 2014



5

The Opportunity to Build on Trends & Achievements in Enterprise IT

In the past when CSPs have started plotting the course of new network transformations, they have tended to do

so largely amongst themselves, within their own frame of reference and according to their own assumptions and

beliefs largely isolated from the rest of the global ICT community.

This time around, with the transformation to SDN and NFV, there is a huge body of experience and an ecosystem of

equipment vendors for CSPs to draw on in the form of the enterprise IT sector. The transformation that has taken

place in the enterprise data center in the last few years, sometimes referred to as the “cloudification” of enterprise

IT, has been, and continues to be, based on essentially the same architectural principles and software-driven

building blocks that CSPs are now looking to incorporate into their SDN and NFV strategies.

Virtualization of IT applications on commodity compute and storage hardware has been com-monplace in the IT

industry for years. And SDN, the physical separation of control and forwarding planes, enabling the control plane

to control multiple devices with open programmability at multiple layers, is already widely commercial deployed,

notably by some of the big Internet companies like Google and Facebook.

While there’s a whole ecosystem of IT vendors with a breadth experience in building enterprise clouds, and a wholeecosystem of telecom vendors with a breadth of experience in building telecom networks, the number of vendors

with substantial experience in both these worlds is relatively small. Therefore, some of the best among them

have the potential be key strategic partners as CSPs look to SDN and NFV to provide a bridge between the IT and

communications worlds.

The Beginning of a Journey

This paper sets out to highlight some of the key new requirements that CSPs are formulating for their equipment

vendors as they undergo this transformation. As CSPs seek to understand and navigate how much of the enterprise

IT model they can port directly into their network architecture and operating model, and how much of it requires

adaptation and fine-tuning to their unique requirements, several challenges arise for CSPs.

One of the key things that is quite well, although still imperfectly, understood about this transfor-mation is that itwill have a knock-on transformative effect on the relationship between CSPs and their network equipment vendors.

It will transform what CSPs buy from their vendors, how and on what terms; and it will transform opportunities, risks

and relationships across the entire ecosys-tem of vendors.

The opportunity for vendors is substantial. According to our December 2014 NFV Market Tracker, Heavy Reading

estimates that the market in NFV equipment and software will grow from a base of $485 million in 2014 to $12.7 billion

in 2019. This paper provides Heavy Reading’s guidelines for what CSPs should be looking for from their equipment

vendors, and thus how vendors can best position themselves for success in this emerging market opportunity.

To give a most basic example, it’s no longer sufficient for vendors to deliver networking functions as discrete

software modules onto their own hardware platforms. They must be able to demon-strate the ability for their

virtual network functions (VNFs) to run – and perform well – on the NFV infrastructure (NFVI) of other vendors. And

vice versa, a vendor’s own NFVI needs also to be able to support the VNFs of other vendors, including independent

software vendors (ISVs).

The communications industry as a whole is only at the beginning of this long-term transformation toward software-

centric networking. As shown in Figure 1 (above), very few CSPs claim to have NFV up and running on a meaningful

scale today. Other than a small handful of large industry leaders that are at the leading edge, the vast majority of

CSPs are still at an early stage of trialing SDN and NFV technologies.



6

Nevertheless, the outlook of some of these leaders shows the level of commitment they have to this transformation

– and just how driven they are to execute on it as rapidly as possible. As shown in Figure 2 (below), for example,

AT&T’s CTO, John Donovan, told the Mobile World Congress event in Barcelona in March 2015 about AT&T’s plans for

NFV. He stated that AT&T plans to migrate 5 percent of its 150 relevant network functions from a classic hardware-

based architecture to VNFs running on virtualized hardware by the end of 2015. He foresees this rising to no less

than 75 percent of these network functions by 2020. Telefonica has comparable objectives, targeting being able to

run 30 percent of its new deployments on its virtualized “UNICA” execution environment by 2016.

Figure 2: AT&T’s Plans for Virtualizing 150 Network Functions

N etwork Functions Running on Classic Hardware N etwork Functions running VN Fs

-10

10

30

50

70

90

110

130

150

2014 2015 2016 2017 2018 2019 2020

Source: Heavy Reading

In the sections that follow we identify some of the critical capabilities and competencies that vendors will needto demonstrate if they are to succeed in capturing a share of this emerging opportunity. At first glance, these

requirements have a very familiar, almost motherhood-and-apple-pie, ring to them. But this paper will soon dispel

that impression. What each of the following terms means from a CSP perspective in the modern era, and how the

requirements associated with each one differs fundamentally from what they have meant to CSPs up until now, is

then discussed in detail throughout the remainder of this paper.

• Modularity

• Openness

• Innovation

• Availability

• Analytics

• Network Integration

New Requirements for Software-Driven Modularity

Modularity is a well-established key principle in IT, as well as in networking. Making a function modular reduces the

complexities of large, multi-functional products so that CSPs need only buy the functions they want, adding to these

as and when needed. Upgrading can be done at a modular level, which is potentially faster as regression testing is

easier: There is no need to re-test the entire product, for example. The same also applies in the case of new function

develop-ment.



7

Evaluating, buying and deploying modular solutions from vendors is one of the core competen-cies of planners,

engineers and operations teams in the CSPs – not to mention their procurement teams. Hence, designing products

that fulfil changing requirements around modularity is one of the core competences of the vendors serving them.

As well as hardware-based modularity, CSPs are increasingly looking for software-driven modu-larity because it is

much faster to add functions or capacity as software modules rather than as hardware modules. Software modules

can be instantly and programmatically on-boarded rather than needing a long procurement and (physical) installation

cycle. In itself, however, even software-based modularity doesn’t protect a CSP from being “locked-in” to a specic

vendor’s product line. After all, it’s possible to have a modular product and still be locked into a particular vendor.

As discussed further below, software-driven modularity also needs to be supported by openness – i.e., the

functionality must be clearly scoped and exposed through an open (i.e., published) application programming

interface (API). This allows the functionality to be integrated with other modules, not necessarily from the same

vendor. Only if these APIs are standard will the modules that are written to them be truly “plug and play.” And this

will help drive the cost reductions and service agility that the CSPs are targeting.

A New Definition of Openness for a New EraRequirements for openness are undergoing a profound transformation. The term features prominently in many

of the new multi-vendor organizations and ecosystems that are driving NFV and SDN forward, such as OpenStack,

OpenDaylight and Open Platform for NFV (OPNFV).

Compliance to Industry-Standard Open Network Interfaces

As far as openness is concerned, there was a time, until recently, when all a vendor had to do to win favor with a

CSP was to be at the forefront of promoting and implementing open network interfaces as specified by industry

standards bodies – 3GPP-specified SGi, S1 and X2 interfaces in the case of 4G LTE, for example. A vendor that put

a lot of effort into standardization, and was among the first to support those standards in commercial product and

then demonstrate interop-erability with other vendors, could legitimately claim to be at least in line with – if not a

leader – in supporting “open standards” consistent with the conventional definition.

That kind of openness at the level of the network interface is still a key requirement in the new era of software-

driven communications services, but it now represents little more than the most basic table stakes. It’s no longer

enough for a vendor to deliver a black box that delivers functionality and provides a standards-compliant pipe out

into the rest of the network and for that approach to be considered “open.”

There are at least two other proof-points relating to openness that CSPs are increasingly looking for from their

vendor partners, and they are every bit as important as a commitment to open network interfaces. These are a

commitment to open APIs and a commitment to open source software.

Open (APIs)

Providing open APIs is an increasingly core aspect of openness against which CSPs are going to rank their vendor

partners. It’s a key enabler of the service agility that CSPs are targeting with the transformation to more software-

centric networking. Rather than just transmitting and receiving data in compliance with the protocols and procedures

mandated by industry standards, vendors now need to expose large parts of the data that underlies those functions.

This is so that end customers – be they the CSP itself, the CSP’s customers or a network integrator or managed

services partner – can better understand, manipulate and modify the product’s configuration to meet their

requirements. There is no longer much point in a vendor delivering a software programmable product if it can only

be programmed by the vendor’s own employees – it now needs to be openly programmable by third parties, as well.



8

While this is undoubtedly the direction that CSPs need their vendors to go in to drive service agility, there are

also aspects of opening up APIs to third parties that are contentious – both for vendors and for the CSPs. An

important corollary of investing in open APIs is therefore that the right security logic has to be built into the API

from the outset so as to protect against abuse. Depending on the use case, additional layers of security can also be

considered, such as a monitoring solution on the interface or a means of enforcing specific access rights for specific

third parties.

A Commitment to Open Source Software

Vendors need to demonstrate a commitment to open source software as they position them-selves for CSP business.

OpenStack is perhaps the most obvious example of an open source software community that is featuring at the

heart of the transformation toward a more software-centric network architecture and operating model for CSPs. It

is now the fastest-growing open source project in history, involving thousands of developers keen to create an open

source alternative to commercial programmable infrastructure managers, such as AWS and VMware. With so much

support within the CSP community for leveraging OpenStack for NFV, it is now rapidly becoming the clear favorite of

all possible candidates for the virtualized infrastructure manager (VIM) in the NFV management and orchestration

(MANO) stack.

What CSPs like about open source software is that it transforms their relationship with their vendors, making the

relationship a lot more transparent and further loosening the vendor’s grip on the CSP’s network infrastructure.

Traditionally, telecom equipment vendors have built product using proprietary software. Those same products

may have been deployed across multiple other CSP networks, but many of their individual CSP customers have also

invested in proprietary extensions to that code – either to accommodate unique aspects of the network or local

market requirements or for competitive differentiation.

This model has served CSPs well enough for the last 20 years, but it’s no longer t for purpose. This is because it

results in the vendor developing a monopoly-like position in the network, rendering it ever more diicult to displace

and ever more diicult to negotiate pricing with, with every additional proprietary extension to the code that is added.

In this traditional model, of course, the vendor’s software starts out as proprietary and remains proprietary until itreaches end of life. Throughout that time, the CSP is entirely reliant on that vendor extending its software roadmap in

a direction that complies with the company’s strategy. They are also reliant on that vendor pricing those proprietary

extensions reasonably in the absence of any direct competition from other vendors, which just isn’t practicable.

The only alternative to this unhealthy dependency is usually the threat of a large scale rip and replace exercise. The

problem with that is that it can sometimes be very expensive and is always very disruptive to the CSP’s operations.

The open source model is wholly different in that software extensions developed by vendors get integrated into the

trunk code by the community and become open standard over time. So what Vendor A brings to the open source

code can be freely replicated by Vendor B down the line. This is how open source development ensures openness

with respect to the long-term availability at reasonable cost of software developed by vendors that use it. Because

“community edition” code can be freely downloaded, it’s worth noting that open source software isn’t truly free

to the CSP. There will always be a cost involved in implementing and maintaining it. Users pay either for in-house

expertise to do this or for a vendor implementation that guarantees a reliable, supported code base.

Because of the transparency of the open source community, CSPs are also assured of unparal-leled, real-time insight

and proof-points of a vendor’s long term strategic intent as regards their software development roadmap. Open

source software also gives them the opportunity to see and experiment with code early in the process. This allows

them not only to see the quality of the code, but also to anticipate potential integration challenges early on, which

helps drive service agility.



9

Due to the transparent way in which the contributions of participants into an open source devel-oper community

can be viewed, CSPs can monitor the extent to which specific vendors are truly committing themselves to the open

source model rather than just offering token participation to give the appearance of a commitment.

There is a world of difference between a vendor that merely downloads and scripts in open source software, while

making a few contributions, and another vendor that contributes substan-tially to the common source pool. One

merely demonstrates a willingness to use what’s there, whereas the other demonstrates greater willingness to

invest a substantial part of its own code – therefore its whole strategic direction – to the open source model with the

result that whatever the vendor contributes will be re-usable by others over time.

Vendors Still Innovate in an Open, Modular Environment

It’s a misconception that a more open, modular ecosystem necessarily means nothing but the commoditization of

telecom software in which vendors have little or no scope left to differentiate. What actually happens is that the

model for competition between vendors’ changes.

Open source communities may have the merit of being open, but the highly democratic process of reviewing

contributions and up-streaming contributions into the core code inevitably and necessarily takes a lot of time. Inpractice, therefore, what is already being seen in the early stages of NFV roll-out is that vendors using open source

software are already competing fiercely to be first to market with leading edge software. Many of the largest CSPs

are happy to take these products on the basis that they want to get something that is not yet standardized into the

network now rather than wait 12 months or more for the code to be reviewed and accepted as part of the core code.

In other words, and consistent with best practices in the IT industry, vendors still have the cherished and much

needed ability to innovate and differentiate based on proprietary software – and to be rewarded for that innovation.

It’s just that by embracing the open source model, the window of opportunity for vendors becomes much more

front-ended.

Vendors now derive a competitive advantage for the duration of the time that their code isn’t formally accepted into

the community’s code – once it is, the differentiator expires. And CSPs can then be comfortable that when they arebuying proprietary extensions of software, they are doing so in the knowledge that while it may be proprietary at

the time of purchase they, and others, can participate in the upstreaming process so that the software subsequently

becomes standardized over time. So, in an open source environment, today’s premium-priced, competitive

differentiator becomes tomorrow’s “free” software.

Availability: Neither Holy Grail nor Dispensable Baggage

The new requirements surrounding end-to-end network availability and performance in an NFV/ SDN environment

are multifaceted. Solutions do need to be found to harden cloud platform implementations so that they are capable

of stepping up and meeting conventional CSP require-ments for carrier-grade availability and performance, which

have not been factored into enterprise cloud deployments.

Experience in building enterprise cloud platforms certainly has inherent value to CSPs. But vendors also need to

demonstrate development activity in building carrier-grade performance into CSP-ready NFVI platforms and VNF

software. As discussed further on, trusted integrators also need to demonstrate an ability to support CSP service-

level agreement (SLA) requirements across a decomposed multi-vendor environment that is home to more –

potentially many more – different vendors across the network than has traditionally been the case.

At the same time, however, a truly agile service creation environment, driven by opening APIs to third parties,

mandates that conventional CSP standards of performance and availability no longer need to be upheld for every



10

single application or every single service running across the CSP’s infrastructure. CSPs need to get comfortable

with making responsible compromises on performance or availability metrics in the case of those applications and

services that don’t need them.

Consistent with that, they need to learn how to be able to isolate those applications and services from others

that do require conventional standards of performance and availability. Unless CSPs make that leap from the

well-entrenched telco tradition of universal availability and performance requirements to requirements that are

tailored per service or per application, they will fail to capture all of the opportunities of the shift to software-

centric networking. The onus is also on vendors to help CSPs differentiate those use cases that do require five-nines

availability from those that don’t; for example, where a VNF has been architected in a highly available way or where

a lag in performance won’t affect customer experience significantly, such as in the case of a free voice service.

As depicted in Figure 3, in the coming years, CSP networks will become less reliant on platform hardware and more

reliant on both platform software and network application software to meet their requirements for network or

service availability. The traditional approach with network equipment used in the CSP infrastructure has been to rely

on availability being guaranteed in terms of approaches such as 1+1 hot standby of the chassis; 1+N failover so that

a pool of hardware platforms picks up the load from any platform that fails; and card-based resiliency so that if acard fails another card picks up its traffic instantly.

Figure 3: The Road From Hardware-Defined to Software-Defined Availability

Classic/LegacyOne vendor delivers

all & provides SLA

Proprietary network

application SW

(All Vendor A)

Proprietary hardware

platform

(Vendor A)

SLA provided by Vendor

A o r a n i n t e g ra t or

Reliability is HW driven

NFV State Of The ArtSLAs provided by - and for -

ecosystem partners

SLA provided by – and

fo r - e co sy st e m pa rtn e rs

Vendor A’s VNFsEcosystem partner

of Vendor C

Open NFVI platform

(Vendor C)

Reliability is HW driven & SW driven

Ecosystem partner of Vendor A & Vendor B

Vendor B’s VNFsEcosystem partner

of Vendor C

NFV Future TargetArchitecture

SLAs supported for all VNFs

Open NFVI platform

(Vendor X)

SLAs are supported

fo r al l V NF s

Any Vendor’s VNFs

Reliability is SW driven

Source: Heavy Reading

As shown in Figure 3, the conventional model in the CSP environment assumes a hardware-driven SLA guaranteed

either by the vendor, by the vendor acting as a broader network integrator or by an independent integrator. There’s

no question that standard servers have nowhere near the internal redundancy and failover capabilities built into

them that purpose-built telecom equipment have. So to capture the cost saving and revenue generating potential of

SDN and NFV, CSPs have to embrace new ways of achieving traditional objectives, albeit in a way that allows more

granular variability in the unique performance attributes required to support different applications and services.



11

What that requires of vendors is to design network platforms and applications that evolve so that they no longer

rely on the hardware providing the reliability but instead are designed to assume the probability of hardware

failures and perform failover in software instead. Hence when a server fails, the cloud management software is

intelligent enough to determine that the network function that was running on it just gets moved onto another

platform elsewhere in the cloud quickly enough to maintain network or service availability targets. Consistent

with this, section 4.2, “Network Function Virtualisation Resiliency Objectives,” of the ETSI Group Specification NFV

Release 001 V1.1.1 published in January 2015, states: “The key objective is to ensure service continuity, rather than

focusing on platform availability.”

Software-Based Failover Isn’t New

Software-based failover isn’t new and is widely used in the IT environment. The unique challenge in the CSP

environment, however, is that most CSP applications are stateful so if there is a failure in failover, connections

are lost together with other state information, such as whether the user is logged in and where they are. There

is certainly still a lot of work to be done here, but there is little doubt that this is the direction CSP networks are

wanting to head in where assuring availabil-ity is concerned. Hence there is also little doubt also that vendors that

demonstrate strong commitment to delivering failover in software – either through their own development activity

or by bringing in high availability software modules from third parties – will find favor with CSPs.

Uncertainty does remain with respect to the optimal balance between extending the capability of network

application software to support failover on the one hand and extending the capability of network platform software

on the other. Work in both areas is clearly required, but the jury is out as to exactly where that balance will fall.

There is also uncertainty with respect to how quickly, and in what stages, different CSPs are going to be able to

migrate their approach to availability from a highly hardware-centric to a highly software-centric model.

The procurement teams in the CSPs are used to performing quality assurance on network equipment according to

their own conventional model. They must undergo a profound overhaul in the way that they evaluate and approve

vendor solutions from an availability or reliability stand-point in order to become comfortable with a highly

software-centric model.

Figure 3 points to an intermediary phase in the evolution of the NFV roadmap, whereby unique ecosystem partners

join forces to guarantee performance of one another’s products, such as one vendor’s VNF operating well on another

vendor’s NFVI. This is largely in accordance with much the same principles as conventional integrator models in the

CSP space, albeit in a far more modular, multi-vendor environment.

We define this phase as “state of the art” because we see evidence of this approach taking hold in the market today.

We view it as a very important interim phase of the market’s development, pending a future, fully mature state of

the market, when carrier-grade requirements, including availability, have been fully developed across the vendor

ecosystem and any and all applications can deliver good performance on any infrastructure.

Advanced Analytics for Performance & Monetization

Advanced analytics – both network analytics and customer analytics – will play an increasingly important role in

networking equipment in conjunction with the roll out of SDN and NFV. A significant part of the value proposition of

a more software-centric network is that it enables CSPs to respond much more rapidly to both network conditions

and customer demands. As CSPs increasingly understand, the insight provided by advanced analytics is critical in

enabling deci-sions to be taken and action taken. Network analytics provide CSPs with a view of how the network is

performing and, hence, what decisions to take in software with respect to optimal routing, for example.



12

Customer analytics are equally important. They enable better understanding of what applications and services

customers are using as a means of automating the generation of customer profiles as a platform for offering them

new capabilities that are customized to their unique behaviors and requirements. Vendors that demonstrate an

ability to appropriately compose the right kind of advanced analytics – either in house or from third parties – into

their products will also be well positioned for emerging CSP requirements.

Integration of a Multi-Vendor Network in the New Era

One of the biggest challenges in a multi-vendor network based on SDN and NFV is integrating multiple vendors. As

already alluded to, this isn’t a new requirement for CSPs. But in addition to being a lot more rewarding in terms of

revenue generation and cost reduction, the network integration requirements in the SDN and NFV era also become a

lot more complex, and thus challenging.

This is because of the greater variety of different vendors, the separation of hardware and software functions

and the transformation required in the CSP’s organization and business processes to take full advantage of

the new operating model. Further, each CSP will also have its own unique requirements – not just with the new

infrastructure, but also with respect to integra-tion with their legacy infrastructure.

Ultimately, the responsibility for fulfilling all of the requirements and opportunities outlined above – modularity,

openness, innovation and availability – all rests with the integrator. The integrator’s ability to pull all these

elements and requirements together in a way that aligns optimally with the CSP’s business objectives will be critical

in determining the success or failure of this transfor-mation.

Figure 4: The Network Integration Preferences of CSPs With NFV

Integrate a mix of vendor solutions

using a specialist integrator

Integrate a mix of

vendor solutions ourselves

Integrate a mix of vendor and

in-house solutions ourselves

Integrate a single-vendor

solutions ourselves

Use a turnkey single-vendor solutions

integrated by that vendor

43%

34%

19%

2%

2%

Source: Heavy Reading survey of 57 mobile operators on virtual EPC, October 2014

As shown in Figure 4 (above), there is strong Heavy Reading survey evidence that CSPs are also very interested in

having an independent, specialist integrator bring together the mix of hardware and software components in the

emerging software-oriented network. In Heavy Reading’s October 2014 survey on virtual EPC, 43 percent of CSP

respondents stated that they will likely prefer a mix of vendor solutions using a specialist integrator to bring them

all together, while 53 percent had in mind carrying out the integration role themselves. Tellingly, only 4 percent of

respondents have in mind a single-vendor solution.



13

Heavy Reading believes that the role of network integrator will be highly sought after in the vendor community. We

expect many of the Leading Lights in telecom and IT worlds to prioritize the network integrator as a key strategic

platform for their own future growth in the networking hardware and software businesses. There aren’t many

vendors that can demonstrate core competencies in building cloudified enterprise IT network, as well as capabilities

in the telecom networking space. Those that can will be well positioned for this type of integrator business.

Summary

Heavy Reading believes that the criteria against which vendor selections are made in the CSP environment are

undergoing a significant transformation. While many of the same terms will continue to be used, what these terms

actually mean and the requirements for how vendors will deliver on them is becoming markedly different.

Vendors that support modularity, openness, innovation and availability according to the increas-ingly software-

defined requirements of CSPs as already driven in the IT market will succeed. Those that don’t, or those that are

behind the curve, will lose out. Analytics will play an increas-ingly important role, too. And we believe that the role

of network integrator will be highly sought after among vendors because of the strategic relationship it will bring

with CSP customers in navigating both the challenges and the opportunities in front of them.

About HP

HP’s objective is to help CSPs thrive in this disruptive environment by accelerating their journey to NFV. Its OpenNFV

Program which includes an open standards–based NFV reference archi-tecture, HP OpenNFV Labs, and the HP

OpenNFV partner ecosystem, helps CSPs speed interoperability and time-to-market of new services.

One of the key tenets of the OpenNFV architecture is that it’s based on open standards and leverages open source

technology projects such as OpenStack® and OpenDaylight (ODL). This approach gives other ecosystem players the

ability to bring in new innovations. We do not believe that NFV is an environment where one vendor will “do it all.”

For more information follow @hpnfv and visit www.hp.com/go/nfv.



14

Light Reading CSP Technology Investment Survey

Methodology: In May 2015, Light Reading undertook an online survey of CSPs as part of a package of research into

how the need to deploy next-generation communications technology is impacting service provider investment

strategies. We received 139 valid responses from service providers around the world.

Light Reading’s recent survey of CSP investment strategies reveals many telling insights into the state of flux that

the communications industry currently finds itself in.

The survey data makes it clear that the need to upgrade networks to support agile, open, virtualized services is

already forcing the majority of CSPs to make sweeping changes to their procurement processes. Over 90% of survey

respondents said that their approach to procurement has changed over the last three years; 46% report that it has

changed “a lot” (see figure 1).

Not surprisingly, the purchasing criteria that have increased most dramatically in importance relate to software

agility; specifically, virtualization and support for open source code. Seventy percent of survey respondents said

that software has increased in importance for their organization over the last three years (see table 2).

The two other purchasing criteria that have increased most in importance over the last three years are

interoperability and integration – a clear sign that CSPs are looking to move away from the single vendor “lock-in”

model that has prevailed in telecom for the last 30 years, where CSPs pay one or two dominant manufacturers to

design and install their products end-to-end (including proprietary features that locked the service provider into

those vendor’s manufacturers solution in the long term).

Open standards-based white box networks leveraging open software free up CSPs from having to engage in this model

by allowing them to mix and match products from dierent vendors; 62% of CSPs expect to spend more on open source

software and 37% expect to increase spending on white box hardware over the next three years (see table 7).

The advent of open, virtualized, white box networks will increase the need for CSPs to pay for systems integrationservices to manage and maintain their networks (services they get today from their single vendor suppliers). This

fact is also reflected in the survey results, with almost 40% of respondents reporting that they will increase their

spending on SI over the next three years (see table 8). Almost three quarters of CSPs say they will buy these services

from existing hardware vendors rather than new or independent SI organizations (see table 9).

The increasing importance of IT skills in building telecom networks is also clear in several places within the survey.

Thirty-five percent of CSPs expect to add more IT experts than network/telecom experts over the next three years

(table 10). Almost half say that their CIO is now more involved in technology procurement than they were three

years ago (table 3).

It’s not surprising to see a newfound recognition of the value of IT in the survey, since many CSPs have now realized

that many of the challenges that they face in creating large-scale virtual cloud services have already been overcome

in the cloud networks that exist in large enterprise IT networks.

Overall, the Light Reading CSP Technology Investment Survey shows that CSPs plan to invest heavily in next-

gen communications infrastructure over the next few years. Sixty percent expect to be spending more, vs. 10%

who hope to spend less (table 4). By far the largest increase will take place in software spending; almost 70% of

respondents see their software spending increasing (table 6).



15

1. How much have your company’s technology procurement processes changed over the

past three years?

Value Percent Count

A lot 46.4% 64

A little 44.2% 61

Not at all 9.4% 13

Total 138

2. How has the importance of these criteria changed in your company’s technology

procurement decision-making over the past three years?

Has become more

important

Has become less

important

No change in importance Responses

Hardware performance

(capacity, data rates)84 62.7 % 23 17.2 % 27 20.1 % 134

Reliability

(MBTF, SLAs)83 62.4 % 18 13.5 % 32 24.1 % 133

Software agility

(virtualization, open-

source support)

91 70.0 % 17 13.1 % 22 16.9 % 130

Delivery and

integration timeframe89 68.5 % 17 13.1 % 24 18.5 % 130

Energy consumption 79 59.8 % 22 16.7 % 31 23.5 % 132

Physical size of

deployed hardware

6046.2 % 26 20.0 % 44 33.8 % 130

Interoperability with

technology from othersuppliers

83 64.3 % 16 12.4 % 30 23.3 % 129

46%

44%

9%



16

3. How has the level of involvement of the following C-level executives changed in your

company’s technology procurement process over the past three years?

Has become more

involved

Has become less

involved

No change in

involvement

Responses

CEO 31 23.3 % 25 18.8 % 77 57.9 % 133

CFO 43 31.9 % 23 17.0 % 69 51.1 % 135

CIO 61 45.5 % 17 12.7 % 56 41.8 % 134

CMO 36 27.1 % 26 19.5 % 71 53.4 % 133

CTO 73 53.7 % 17 12.5 % 46 33.8 % 136

4. Overall, how do you expect your company’s technology spending to change over the next

three years?

Value Percent Count

Our spending will increase by 5% or

more each year32.1% 44

Our spending will increase by less

than 5% each year27.0% 37

Our spending will remain relatively

at31.4% 43

Our spending will decrease by less

than 5% each year5.1% 7

Our spending will decrease by 5%

or more each year 4.4% 6

Total 137

5. How do you expect your company’s spending on hardware to change over the next

three years?

Value Percent Count

Spending on hardware will

increase34.3% 47

Spending on hardware willdecrease

38.7% 53

Spending on hardware will remain

roughly the same27.0% 37

Total 137

32%

27%

31%

4%5%

34%

39%

27%



17

6. How do you expect your company’s spending on software to change over the next

three years?

Value Percent Count

Spending on software will increase 67.2% 92

Spending on software will

decrease11.0% 15

Spending on software will remain

roughly the same21.9% 30

Total 137

67%11%

22%

7. How will your company’s spending on the following change over the next three years?

Spending will

increase

Spending will

decrease

Spending will remain

the same

Responses

Proprietary hardware 41 31.1 % 57 43.2 % 34 25.8 % 132

White-box hardware 50 37.3 % 35 26.1 % 49 36.6 % 134

Proprietary software 39 29.1 % 53 39.6 % 42 31.3 % 134

Open-source software 84 62.2 % 19 14.1 % 32 23.7 % 135

SDN 84 63.6 % 17 12.9 % 31 23.5 % 132

Virtualization

(VNFs, NFV)99 76.2 % 8 6.2 % 23 17.7 % 130

Security 102 76.7 % 9 6.8 % 22 16.5 % 133

Analytics 84 64.6 % 15 11.5 % 31 23.8 % 130



18

8. How will your company’s use of systems integrators change over the next three years?

Value Percent Count

We will use systems integrators

for more projects37.2% 51

We will use systems integrators

for fewer projects19.7% 27

Our use of systems integrators

won’t change much34.3% 47

We haven’t used systems

integrators in the past, and we

don’t plan to use them in the

future

8.8% 12

Total 137

9. How does your company source its systems integration partners?

Value Percent Count

We work mainly with SI teams

from our technology suppliers71.3% 97

We work mainly with SI

organizations outside of our

technology suppliers

28.7% 39

Total 136

10. How do you expect your company’s internal technology expertise to change over the

next three years?

Value Percent Count

We will add more network

experts than IT experts24.1% 33

We will add more IT experts thannetwork experts

35.0% 48

Our mix of network and IT

experts will remain about where

it is now

40.9% 56

Total 137

37%

20%

34%

9%

71%

29%

35%

41%

24%



19

11. What type of communications service provider do you work for?

Value Percent Count

Wireline network operator 14.4% 20

Mobile network operator 25.9% 36

Converged network operator

(wireline and mobile)40.3% 56

Cable network operator 11.5% 16

OTT service provider 2.2% 3

I don't work for a CSP 0.0% 0

Other (please specify) 5.8% 8

Total 137

11. In what region is your company headquartered?

Value Percent Count

U.S. 70.5% 98

Canada 6.5% 9

Central/South America

(including Mexico & the

Caribbean)

5.0% 7

Western Europe 10.1% 14

Central/Eastern Europe 0.0% 0

Middle East 1.4% 2

Africa 0.0% 0

Asia/Pacic

(including Australia)6.5% 9

Total 139

40%

12%

2%

6%

14%

26%

71%

6%

5%

10%6%

state of virtualization 9

Documents