HP NFV ezine v2 dec 2014

1NFV Edition—Update

Industry EdgeNetwork Functions Virtualization Edition

Feature stories

What do I virtualize first and why?

Why SDN matters in NFV

What needs to happen in network/IT collaboration?

Plus: Analyst and partner views on the future of NFV

HP • 2015

The new business of the networkThe communications industry is at a point

where the early skepticism and “prove it

to me” attitude toward network functions

virtualization (NFV) has largely subsided.

Today, many of the fundamental aspects

of the architecture have been settled,

but the specifics are still being worked

out. Unprecedented industry efforts are

underway to resolve the outstanding issues

in a “standard’’ way, involving cooperation

between users and suppliers in both the

standards and the open source arena. And HP

is taking a leading role.

In this issue of Industry Edge: Network Functions

Virtualization, I invite you to learn about:

• What to virtualize first—how to get started

on your NFV journey

• How to bridge two worlds: your

legacy IT environment and your

new virtualized network

• Why software-defined networking (SDN)

matters in NFV

• HP’s NFV strategy and our role in proof-

of-concept projects around the world

We’ve also invited several guest authors—

including analyst Peter Janich of Current

Analysis, as well as several HP OpenNFV

Partners—to share their views on where NFV is

heading. Read what experts from A10 Networks,

ConteXtream, Intel®, KEMP Technologies,

Mellanox, and Wind River have to say.

Our interest is to make this journey to the

cloud with NFV as efficient as possible for our

customers. Our job is to be a partner to CSPs,

to be flexible, and to remove the barriers on

this NFV journey.

Saar GillaiSenior Vice President/Chief Operations

Officer, HP Cloud and General Manager,

NFV, HP

In this issue 4 HP in network functions virtualization

8 What do I virtualize first and why?

12 Why software-defined networking matters

in network functions virtualization

16 What needs to happen in

network/IT collaboration?

20 Network functions virtualization use cases

22 Current Analysis—NFV: What

needs to come next?

24 A robust ecosystem of partners

26 A10 Networks—Accelerating the delivery of

services with network functions virtualization

28 ConteXtream—Road to rack scale: The

optimization of virtualization technologies

30 Intel—A foundation for SDN and NFV

32 KEMP Technologies—Are SDN and NFV

on a convergence path?

34 Mellanox—A scalable solution to meet

the demands of today and the future

36 Wind River—NFV gets carrier grade

38 Why HP?

4 NFV Edition—Update

HP in network functions virtualization Network functions virtualization (NFV) is all about enabling communications service providers (CSPs) to create agility while reducing OpEx and CapEx. NFV makes it possible for CSPs to move network functions from traditional and proprietary, monolithic, hardware-centric architectures to open and agile architectures based on cloud technologies.


Openness, standards, and choice At HP, our strategy is to provide a reference

architecture, NFV infrastructure (NFVi)

platform, and rich partner ecosystem to enable

CSPs to make this transition. In addition, one of

the key tenets of the HP OpenNFV architecture

is that it’s based on open standards and

leverages open-source technology projects

(such as OpenStack).

For example, CSPs are looking for OpenStack

to play a role in the NFV platform; they want

the same advantages the enterprise has

experienced with open source. HP is well

positioned to support this. As a leader in

OpenStack, HP has been defining the next-

generation computing platforms, and we are

doing this again with HP Helion and the next-

generation open-source computing platform.

When you combine this with our operational

support system (OSS), service orchestration

capabilities, and broad hardware portfolio, you

get a very compelling solution for CSPs looking

to get going on NFV.

One of the benefits of this approach is the

ability to enable other players to bring in

new innovations. The HP OpenNFV Partner

Program allows carriers to choose the HP and

partner technologies they need for an end-to-

end NFV solution. And with our HP OpenNFV

Labs, we work with our partners to make

sure that all the pieces work together, so the

carriers don’t have to.

Network hardware to software applicationsHP has all the key ingredients for carriers to

start their NFV transition journey: standard

high-volume Ethernet switches, standard

high-volume storage, and industry-standard

servers, as well as software.

From a networking viewpoint, we have

standard high-volume Ethernet switches

compliant to OpenFlow 1.3 that can be

controlled by our HP standard SDN controller.

Our standard high-volume storage HP 3PAR

is well positioned in this space. We also have

industry-standard servers featuring extended

lifecycle, NEBS Level-3, and ETSI certifications,

and carrier-grade Linux® OS support. All of

these components provide the scalability and

performance required in a CSP environment.

We also support some of the applications

(ourselves or via partners), which were

traditionally in telecom appliances that can be

now implemented in virtual machines on top

of the industry-standard servers. This gives

One of the key tenets of the HP OpenNFV architecture is that it’s based on open standards and leverages open-source technology projects.


us the capability to cover the entire spectrum,

from the network hardware to the software

applications, to enable CSPs to deploy NFV.

And as orchestration is critical, the HP NFV

Director brings together HP capabilities

in OSS and IT management to provide

a comprehensive, multivendor NFV

orchestration solution.

Carrier-grade reliability, performance, and managementTo realize the full value of NFV, our customers

want the benefits of cloud computing, while

meeting rigorous reliability, performance, and

management requirements. And the HP Helion

platform—coupled with Wind River’s carrier-

grade Linux and kernel-based virtual machine

(KVM)—will provide a fully integrated and

supported cloud solution that brings a carrier-

grade platform that CSPs can put their trust

in and build upon.

Simplifying NFV rollout with servicesThere is a broad spectrum of NFV deployments,

from simple virtualized single applications

to complete geographically distributed data

centers. Some will be simple, requiring only

limited additional services, and some will need

integration and deployment services. We also

offer consulting and managed services for NFV.

We are actively building these solutions and

the services, skills, and offers to go with them.

Examples include:

• Our “Data Center Care” offer, already

available for enterprise cloud, is well

adapted to NFV support needs.

• The HP NFV Transformation Experience Workshop is a predefined NFV consulting

offer that we have already delivered to

customers around the world to help them

plan their NFV journey.

• OpenStack-related services are now

available through our growing OpenStack

professional services team.

We intend to simplify NFV rollout for our

customers with pre-integrated solutions and

prepackaged, well-defined services.

This is a historic point in time for the industry.

CSPs have a significant and critical opportunity

right now, and HP—with its technology, IT and

networking expertise, partners, services, labs,

and commitment to standards—is in a unique

position to help them succeed.

Saar GillaiSenior Vice President/Chief Operations

Officer, HP Cloud and General Manager,

NFV, HP


What do I virtualize first and why?As network functions virtualization (NFV) moves from the theoretical to proof of concept (PoC) to trial and implementation, carriers want to know how best to begin the journey to NFV and, specifically, which network functions to virtualize first.

The decision on what to virtualize first should be based on both technology and business criteria.

Technical decision criteriaThe European Telecom Standard Institute's

(ETSI) use cases, which are driven by carrier

requirements, are designed to examine the

following three criteria. We recommend using

these criteria to help drive your decision

on which functions to virtualize—from

a technology perspective.

1. Understand which network functions

require extensive CPU processing or

intensive bandwidth. Those functions that

require heavy CPU processing are good

candidates. Those that require a lot of

bandwidth are not.

2. Learn where in the network stack the

functions run. If they run in layer four

and above, they are low-hanging fruit for

virtualization because they will be more

easily ported into a virtualized model.

Most functions that run in layer four and

above are already software-based and are

less likely to be tied to a custom appliance.

3. Any new solution in the network is a

good candidate for virtualization. In

fact, moving forward, it’s a reasonable

policy to say that any entirely new

network function or service must have

a compelling business case to implement

in a custom appliance.

The table that follows lists categories of

network functions to virtualize—ranked from

easiest to hardest—based on these criteria.

All have been examined within the industry

and by ETSI, which has demonstrated that

they can be virtualized.


Figure 1. Functions to virtualize—from easiest to hardest

Category ExamplesSecurity functions Firewalls, virus and malware scanners, SPAM protection, intrusion protection

Application functions Caching, accelerators, load balancing, content distribution

Network functions Policy; authentication, authorization, and accounting (AAA); charging

Tunnels Secure sockets layer (SSL) virtual private network (VPN) gateways

Edge functions Customer premise equipment (CPE)—enterprise and consumer

Analysis functions Quality of experience (QoE) measurement, service-level agreement (SLA) management, deep packet inspection (DPI), test

Signaling functions IP multimedia system (IMS), session border control (SBC)

Mobile network functions

NodeB, evolved node B (eNodeB), radio network controller (RNC), serving GPRS support node (SGSN), gateway GPRS support note/packet data network gateway (GGSN/PDN-GW), mobility management entity (MME), home location register (HLR), home subscriber server (HSS)

Switching element functions

Broadband remote access server (BRAS), broadband network gateway (BNG), carrier-grade network address translation (CG-NAT), routing

Business decision criteriaOne of the biggest business issues for carriers

to evaluate is the disruption that may occur

in the operational support system (OSS) and

business support system (BSS) as a result

of implementing a part of the network as

virtualized functions. The OSS will be disrupted

because the system is designed to mostly deal

with resources that are physical.

For instance, when the OSS interacts with

a physical router, the router has a network

address, a position in the rack, a bay number,

etc. In a virtualized world, that router is a

piece of software running in a virtual machine

that could be in a shared infrastructure, and

it might have the ability to move around

within the infrastructure or completely move

to a different geographic location. To handle

services that are virtual and not physical, the

inventory management system and service

catalog must be modified.

Similar issues will take place for any function

that moves from a physical implementation

to a virtual one, and carriers must figure out

how to address this while mitigating or limiting

disruptions to the business.

The need for orchestrationNFV creates a new need within the network—

for resource management and orchestration.

Services running in the infrastructure must

play well together. Carriers can't afford to

have a virtual router go rogue and hog huge

amounts of memory, which could wreak havoc

on the network.


Instead, carriers need a buffer between the

virtual network functions (VNFs) and the old

OSS. For example, an event management

system (EMS) may expect to receive alarms in

a certain way from physical network functions.

But with VNFs, each service may have a

different way to present alarms. If the EMS

doesn't recognize the alarms, it could cause

problems for the legacy OSS. Orchestration can

provide the correlation—presenting alarms

to the legacy system in the way it expects

to receive them.

What to virtualize firstLook for targets in your network that can be

instantiated easily, will have minimal impact

to the customer base if a problem should

occur, and will have minimal disruption

to the OSS. Find functions that are CPU-

intensive but not bandwidth-intensive and

are already implemented in software. And

look at solutions that are new to the network

or on a capital refresh cycle.

Good initial targets for high ROI look to

be things like virtual customer premise

equipment for enterprise, virtualization of

processes such as service provisioning and

activation, virtualization of data mediation,

and virtualized CDN. All of these can produce

reasonable ROI while providing a safe place for

CSPs to get started in NFV.

For more information, visit hp.com/go/nfv.

Jeff EdlundCTO, Communications,

Media & Entertainment, HP

http://hp.com/go/nfv


Why software-defined networking matters in network functions virtualizationIn the data center world, the network is just a resource. In the communication service provider (CSP) world, the network is the business. This difference in mindset means that software-defined networking (SDN) has been effective at solving problems in the data center but has been a solution in search of a problem within the carrier network. Network functions virtualization (NFV) changes that by providing a compelling business case for SDN.

In the enterprise, SDN is used to virtualize

routing and switching, but it’s not clear that

carriers want or need that in their networks.

In the data center mindset, it's appropriate to

put the network controller under the authority

of the orchestrator. But for the carrier network,

it's more important to dynamically control the

network and to control it holistically rather

than element by element.

An NFV scenarioSDN is an enabler for NFV, and the best way to

understand this is with an example.

Let’s take an NFV scenario where we’re running

a virtualized broadband remote access server

(BRAS). In a carrier network, typically this

is a router at the edge of the network that

takes all the communication from an end user

and allows that user to get to the Internet

and other services. In this simple example

(figure 1), the NFV orchestrator has a span of

control over two central office locations and

owns some cloud resources in both central

office locations. The BRAS application is

running in Central Office 1, and the subscriber

is getting services from this office.


Figure 1. An NFV scenario, part 1

Now a problem occurs: The cloud node in Central Office 1 that was serving the subscriber crashes

(see figure 2). When this happens, the orchestrator should spin up virtual instances of the BRAS

application in Central Office 2, and everything should be fine to continue serving the customer. But

the subscriber needs to be connected to Central Office 2. In a typical carrier environment, there

may be transport connecting the two locations, but there may be no logical path. Something

needs to set up the connection.

The path that needs to be created needs to be carried out on wide area network (WAN) resources,

not data center resources. And the NFV orchestrator has no knowledge of the “underlay” network

and its current state. One possible solution is to use a network controller that knows the state of

the underlay to dynamically create the path.

Figure 2. An NFV scenario, part 2

Who establishes this?

Transport exists, but no logical path had been established.


To make the switch so that the path coming

from the subscriber goes to the new

location, the access router and the WAN-

facing router in the data center need to be

involved. Creating the new path requires

event-based, dynamic connectivity changes.

Therefore, we need an SDN controller. This

controller cannot be subservient to the NFV

orchestrator, which has no knowledge of

these resources.

With this simple example, since you may

still require SDN controllers within the mini

data centers (Central Offices) under the

orchestrator's purview, there is a case for

SDN controllers in the context of NFV, and

for at least two SDN controllers at different

levels. It's possible to think of additional

levels of SDN controllers, but it's at least

clear that it's more than one.

For CSPs, SDN is not necessarily about

network virtualization (as it is for most

data center and cloud operators), but about

dynamic network configuration and control,

and the ability for services to access and

manipulate network services holistically using

service-layer abstractions.

SDN is a natural enabler for NFV because

with network topology flexibility and

dynamic configuration, the full value of NFV

can be realized.

Learn moreFor more information, visit hp.com/go/nfv.

Prodip SenCTO, Network Functions Virtualization,

HP

CPE Access WAN facing

ToR switch Server ToR

switchWAN

facing

Internet access router

Figure 3. The WAN network view



What needs to happen in network/IT collaboration?As communications service providers (CSPs) make the transition to network functions virtualization (NFV), they face a major challenge. With NFV, the worlds of IT and the network must come together, which will force fundamental changes in carrier operations, processes, and systems.


Of the CSPs that are getting the best results in

this area, we see three common best practices:

1. Break down the firewall between the network and IT.

It's not just about the technology;

organizational dynamics matter. To help

bridge the IT and networking groups, we

recommend organizational changes. In IT,

instead of having distinct groups managing

storage, servers, and switches, eliminate

those delineations and create a shared

infrastructure team. On the network side,

instead of having people solely dedicated

to specific network functions, organize

people into a network applications or

service specialist team. In addition, a new

set of skills will need to emerge in resource

management and orchestration. As the

service delivery model becomes more

“cloudy,” the necessary people skills will

need to become “cloudy” as well.

2. CMOs can accelerate innovation and agility.

Until now, the chief marketing officer (CMO)

and product marketing organization have

had a somewhat adversarial relationship

with IT and networking, always asking

for new services that will take at least

18 months to deliver. But with the move

to NFV and the ability to bring services

to market faster, product marketing—in

collaboration with the CMO—can drive the

rest of the business to strive for greater

innovation and agility. With NFV, CSPs

will be able to deliver new services just


by loading new software; no truck rolls or

hardware installations required. This shift

means that carriers can take more risks

to see what works for their customers. If

a new service works, they can add more

resources to the shared infrastructure to

expand it. If the new service doesn't take

off, they can just delete the software. With

NFV, the cost of failure goes way down,

which will empower product marketing

to pursue innovative ideas for new

revenue streams—with cooperation, not

resistance, from the rest of the business.

3. Executive sponsorship is required.

None of these organizational changes will

come naturally. Commitment from the

top will help inspire acceptance of these

changes. While we used to see CSP chief

technology officers (CTOs) leading the

charge for NFV, we're now seeing chief

information officers (CIOs) rapidly emerging

to provide a great deal of value. CIOs have

decades of experience with commercial

off-the-shelf (COTS) hardware, and they’ve

been working with orchestration in IT

for the better part of 7 to 10 years. We

expect to see a much higher chance of

success when the CIO and CTO join forces

to implement these changes.


How HP can helpHP is in a unique position to help shepherd

this transformation and help CSPs on their

journey to NFV. At HP, we have proven solutions

throughout the “stack” and expertise across

the board for NFV: in IT, networking and the

communications industry.

HP OpenNFV Services offer a proven way to

navigate the NFV transformation of network

functions. Our services team supports carriers

at all stages of the NFV transformation,

providing a complete lifecycle of services

from consulting to implementation to

managed services. HP OpenNFV Services are

available at each layer of our architecture

from NFV infrastructure to management

and orchestration.

How to get startedIt is imperative that IT and networking come

together to effectively design and run an NFV-

enabled network. To make this happen, leverage

and build on what you have, and don’t proceed

in isolation. CSP IT departments—and HP—

have a great deal of experience in virtualization.

Leverage this skill into your core network

teams, and enlist partners to help you on your

journey. HP, for example, has delivered the

industry-leading COTS architecture for IT for

at least a decade and has been a leader in core

network services like home subscriber server

(HSS), providing an industry-leading 99.9999%

availability. Few companies bring together these

capabilities to address the needs of the NFV-

enabled CSP of the future.

For more information, visit hp.com/go/nfv.

Jeff EdlundCTO, Communications,

Media & Entertainment, HP

OSS lifecycle

VNF lifecycle

Management and orchestration lifecycle

NFV platform lifecycle

NFV support and operations

NFV consulting and project services

NFV Managed Services



Network functions virtualization use casesProof-of-concept projects

Commitment to openness and collaborationThe HP approach to network functions

virtualization (NFV) is built around

completeness, openness, standards, and

expertise. One of the benefits of this approach

is the ability to enable other players to bring

in new innovations, and with the HP OpenNFV

Labs, we provide an environment to validate

that the pieces work together. To this end, HP

is actively involved in more than 20 proof-of-

concept (PoC) projects around the world.

We’ve been involved in software-defined

networking (SDN) and NFV since day one,

before OpenFlow and before the European

Telecommunications Standards Institute

(ETSI) was working on NFV. Back then,

we worked with a large communications

company on different use cases such as

Internet Protocol Security (IPsec) and

virtual content delivery networks (vCDN),

proving that telco network functions could

run on commodity hardware and sustain

performance by properly designing and

tuning hardware configurations. We also

worked on virtualization use cases, such as

virtual customer premises equipment (vCPE),

including NFV orchestration more recently.

With another large communications company,

the focus started with end-to-end services,

combining SDN with NFV, working on service

chaining and traffic steering use cases

spanning multiple SDN controllers and some

virtualized functions. At the time, nobody was

talking about service chaining yet, but now it is

a popular topic.

Over 20 active proof-of-concept projectsToday HP is involved in more than 20 active

NFV use cases covering areas including

voice/video, mobile private networks, IP

routing and transport, telco cloud, NFV

orchestration, virtual evolved packet core

(vEPC), multiservice proxy (MSP), vCPE,

and IP multimedia subsystem (IMS). HP

proves with these PoCs that we have the

broadest range of capabilities, including


hardware, networking (including SDN), cloud

infrastructure, orchestration and virtual

functions. Multivendor and distributed around

the globe, these PoCs are in all three regions:

Europe, Americas and Asia.

In addition, HP is currently involved in seven

ETSI-accepted NFV PoCs. Four of these were

demonstrated at SDN World Congress in

Dusseldorf in October 2014 (see figure 1).

Vinay SaxenaChief Architect, Network Functions

Virtualization, HP

Marie-Paule OdiniChief Technologist Office,

Communications, Media & Entertainment,

HP

Figure 1. HP participation in ETSI-accepted PoCs

ETSI PoC Title Collaborators StatusPoC#2 Service chaining for NW

function selection in carrier networks

NTT Communications, Cisco Systems, and Juniper Networks

Completed. Demonstrated at NTT R&D Forum, Feb. 2014.

PoC#6 Virtualized mobile network with integrated DPI

Telefonica, Intel®, Tieto, Qosmos, and Wind River Systems

Phase I completed. Demonstrated at Mobile World Congress, Feb. 2014.

PoC#13 SteerFlow: Multi-layered traffic steering for Gi-LAN

Telefonica, Radware, and Mellanox

Demonstrated at SDN & OpenFlow World Congress, Oct. 2014.

PoC#15 Subscriber aware SGi/Gi-LAN virtualization

Telenor Group, ConteXtream, Skyfire Networks, Guavus, and Red Hat


PoC#22 Demonstration of high reliability and availability aspects in a multivendor NFV environment

AT&T, KDDI R&D Laboratories, Brocade, and Wind River Systems

Demonstrated at Intel Developers’ Forum, Sept. 2014.

PoC#23 E2E orchestration of virtualized LTE core-network functions and SDN-based dynamic service chaining of VNFs using VNF FG

SK Telco, Samsung, and Telcoware


PoC #27 VoLTE service based on vEPC and vIMS architecture

ZTE Corporation and China Unicom

To be demonstrated at China Unicom R&D Lab, Beijing, China, Jan. 2015.

These NFV PoCs have been developed according to the ETSI NFV ISG Proof of Concept Framework. NFV PoCs are intended to demonstrate NFV as a viable technology. Results are fed back to the NFV Industry Specification Group. Neither ETSI, its NFV Industry Specification Group, nor their members make any endorsement of any product or implementation claiming to demonstrate or conform to NFV. No verification or test has been performed by ETSI on any part of this NFV PoC.


NFV: What needs to come next?In late 2013, Current Analysis set out to take the pulse of the market for software-defined networking (SDN) and network functions virtualization (NFV) solutions. What were operators buying? What were they looking to buy going forward? Why were they investing in SDN and NFV? What were they looking for from their solution providers? What did they think of the current supplier community?

While the concept of surveying service

providers about technology evolutions wasn’t

novel, the goal was to be comprehensive and

global, while seeking to input from actual

decision-makers. More than 100 network

operations executives from around the globe

were included in the panel.

The results: Progress, but room for improvement Broadly, it was clear that the market was in

need of some education. On one hand, SDN and

NFV were being viewed as a single concept; the

diverse value propositions and deployment

considerations behind them simply weren’t

being recognized. Somewhat puzzling, then,

was the finding that NFV deployment was, for

many operators, a secondary priority to SDN.

And while the hope of many was that SDN and

NFV (either on their own or together) would

help usher in new service opportunities, more

than two-thirds of the operators surveyed

saw CapEx and OpEx as the primary business

drivers behind them.

With SDN and NFV solutions still maturing

and trials (much less proofs of concept and

commercial deployments) just getting under

way, these perspectives weren’t particularly

surprising. Fast forward a year, and it’s now clear

that the “needed education” has taken place.

Updated survey results

This year, Current Analysis again set out to

survey service providers about their thinking

around SDN and NFV. Again, the goal was to

obtain comprehensive, global, and meaningful

results. The hope was also to see an evolution

in operator thinking and priorities. To that end,

it was encouraging to see that service support

(scaling existing services and launching new


ones) topped OpEx and CapEx concerns by

more than a two-to-one margin in terms of

SDN/NFV business drivers. It was equally

encouraging to see a near-term (12- to

18-month) to medium-term (24- to 36-month)

deployment time horizon planned for most

NFV use cases.

Of course, it wasn’t all good news. As with

last year, primary NFV deployment obstacles

focused on unclear ROI, uncertain use cases,

and technology immaturity. The split between

these issues and everything else (organizational

challenges and management and orchestration

[MANO] prerequisites, for example) actually

widened from last year.

As deployments move forward, concerns around

technology immaturity should dissipate. Proving

out NFV use cases, and the ROI associated

with them, should follow. Of course, for all of

this to actually happen, it’s incumbent on NFV

solution vendors to help carrier customers

understand that NFV truly is ready for prime-

time deployment (i.e., that it’s carrier grade).

Peter JarichVice President, Consumer and

Infrastructure, Current Analysis

A robust ecosystem of partnersHP’s approach to network functions virtualization (NFV) is built around openness and standards. This gives us the ability to enable other players to bring in new innovations, including network equipment providers (NEPs), independent software vendors (ISVs), and system integrators (SIs).

Communications service providers (CSPs) want to choose their applications from anywhere

and everywhere, regardless of vendor. They need speed and agility, which means their network

environment must be open, flexible, and unconstrained. They also need to be able to collaborate

on technology with third parties. To support this degree of flexibility and openness, adhering to

standards is critical. An NFV platform with a standards-based open architecture enables a robust

ecosystem of vendors whose products work well together, but to ensure their interoperability,

they should be tested in a multivendor environment before CSPs bring them into production.

The HP OpenNFV Partner Program enables CSPs to choose the technologies they need to best serve

their customers—from HP or our partners. And the HP OpenNFV Labs give our partners a place to

test multivendor solutions to make sure all the pieces will work together in the carrier network.

In the section that follows, we’ve asked several HP OpenNFV Partners to write about how we’re

collaborating to help operationalize NFV solutions. Working together, we help CSPs customize

services for their markets’ needs and bring new services to market faster—with lower risk and

greater confidence.

Werner SchaeferVice President, GTM, Network

Functions Virtualization, HP


Accelerating the delivery of services with network functions virtualizationTo remain competitive, carriers must address increasing network and service demands while reducing the overall costs of their ongoing operations. Adding capacity is simply not enough; carriers need to create an agile infrastructure that can support innovative and cost-effective service delivery models and fluctuating traffic volumes.

Ripping out and replacing existing

infrastructure to achieve this more agile

environment is often impractical and cost

prohibitive. As a result, carriers are looking

for ways to evolve their networks to leverage

the efficiencies and scale attainable with more

virtualized environments. When they can

use network functions virtualization (NFV) to

virtualize and automate network functions

on commodity hardware, they can start to

consolidate equipment and take advantage of

much more cost-effective, standards-based,

high-volume storage and switching servers.

To attain a more virtualized environment,

however, requires the support of an open,

standards-based ecosystem that can deliver

the performance and scale customers expect

from their carrier. It also depends on the

interoperability of the solutions; physical

and virtual appliances must be able to

seamlessly run within the same environment

to ensure the carrier doesn’t incur significant

setup and ongoing management costs. As

this new ecosystem comes into existence,

a programmatic interface that easily allows

communication with other devices and network

entities, through application programming

interfaces (API), will be a critical design tenet

for any solution that wants to participate.

Lastly, to ensure that the many benefits

from these virtualized network services are

realized, carriers will also need a consistent


management and orchestration architecture.

For example, when Deutsche Telekom was

looking to build its next-generation networks,

it partnered with A10 Networks to develop the

NFV offering. Deutsche Telekom was able to

differentiate and scale its cloud offering and

leverage A10’s pay-as-you-go licensing and

dynamic service insertion to deliver elastic,

tiered services to their customers.

HP’s new software-defined networking (SDN)

architecture, coupled with innovative network

virtualization technologies, such as A10

Networks aCloud Services Architecture, is well

positioned to give carriers what they need to

reduce TCO and increase their agility. Benefits

of such integrations include the rapid scaling

of services, the ease of provisioning and

automation, and the ability to provide tailored

services for a multitenant environment.

These benefits can be compounded with pay-

as-you-go licensing models that can deliver

the flexibility carriers need when dealing

with dynamic workloads and provisioning

on-demand virtualized services. Together,

A10 Networks and HP can offer carriers the

comprehensive, high-performance, cost-

effective, and agile service delivery models

they need to accelerate the adoption of an NFV

ecosystem to start reaping its benefits.

Harshal PimpalkhuteSenior Product Marketing Manager, A10 Networks

Prashanth ChittapuramSenior Product Marketing Manager, A10 Networks


Road to rack scale:The optimization of virtualization technologies

Today, we’re progressing toward the virtualization of evermore computing, networking, and storage resources. By doing so, we increase the concurrency, programmability, and utilization of IT solutions through elastic and dynamic allocation. There is an old adage that states, “All problems in computer science can be solved by another level of indirection...” In this case, it’s true. Developers can now program and scale solutions by leveraging programmable network virtualization indirections. These new abstractions, inserted seamlessly between known interfaces, are essentially using the network to scale and customize solutions en masse.


When deployed individually, however, these

indirections come with a high cost. They

can add extra steps for packets to travel,

causing latency, the need for additional

processing, and costs that can threaten the

viability of virtualization especially in carrier

environments. We may get very flexible

solutions to operate at high utilization but with

an overall poor total cost-to-benefit ratio. By

consolidating these indirections, many of these

costs can be mitigated. Aggregating packaged

features enable us to gain the full value of

virtualization at a fraction of the expense.

In network virtualization we typically look for

three main indirections:

1. The virtualization construct that allows

resource identities to show up anywhere

in the network without IP "zip-code-

zoning" constraints; is the identity-

location indirection.

2. The construct that allows the network to

logically chain functions based on service

identity regardless of source destination

routing rules; is the subscriber-service

chaining indirection.

3. The construct that translates virtual

addresses to specific physical addresses

to provide seamless scalability and

load balancing; is the class-instances

indirection.

If we tackle these three constructs separately,

we’d end up with roughly 10-times more steps

for packets to take than necessary. That would

add significant cost and latency not just to the

network but to the entire IT solution leveraging

the network for scaleout and programmability.

In contrast to this, SDN virtualization

indirections can be implemented in aggregate.

Consolidation is both in terms of functionality

and physical rack scale aggregation. This

10-times efficiency step can be accomplished

through an integrated approach, which takes

into account mobility, chaining, and load

balancing. In this approach, the compiled

logic would be programmed to flow only

once, taking into account the compiled

requirement, and programmed strategically

for the consolidated rack or on top of the rack

switch itself. The foundations for globally

aware overlay flow mapping that can achieve

this have been developed by ConteXtream

for the OpenDaylight SDN stack. The model-

driven and declarative intent principles at the

heart of this architecture are being jointly

pursued in collaboration with HP. As a leading

switch-server vendor, HP is in an excellent

position to promote this consolidation effort

with ConteXtream. The compelling economic

benefits provide excellent incentive to fuel

the adoption of virtualization and NFV cloud

by tier 1 carriers worldwide.

Sharon BarkaiCo-founder, ConteXtream


A foundation for SDN and NFVDeveloping solutions for implementing software-defined networks (SDN) and network functions virtualization (NFV) remains a big challenge for enterprise and communications service providers (CSPs). Rapid evolution of standards and open-source software for network nodes, network control, and network orchestration burden organizations, which are evaluating how to implement these next-generation networks.

Intel® is a leading founder and contributor

to various open standards communities:

OpenStack, Open Daylight, Open vSwitch,

and OPNFV. Intel aims to be a catalyst for

transforming the network to a more flexible,

scalable and cost-effective model. And for

NFV to succeed, an industry-standard server

platform is a needed foundation for delivering

the economies of scale for both development

and deployment.

Intel’s open network platform (ONP) for servers

offers a solution by defining an open software

framework based on open-source software. The

Intel ONP is a test bed to integrate various open

community projects: OpenStack (orchestration),

Open Daylight (control), and Open vSwitch

(virtualization of network functions on a

server). Integrating multiple open-source

streams has tremendous challenges—and

requires participating with and contributing

to all the open standards communities. Intel

has a unique technical system and networking

understanding to contribute to the development

of these standards. Since these are open-

community initiatives, the SDN and NFV

solution implementations are as varied as the

contributors to the communities.

“Intel and HP share a common vision and

commitment to enable a rich ecosystem of

SDN/NFV solutions based on open source

and open standards,” said Rose Schooler,

vice president, Data Center Group, general

manager, Communications Storage and

Infrastructure Group, Intel Corporation. “HP’s

Linux® implementation and HP Helion are prime

examples of innovation optimized on Intel’s Open

Network Platform Server Reference Design.”

Intel and HP share a common vision and commitment to enable a rich ecosystem of SDN/NFV solutions based on open source and open standards.


So, what value can customers derive from ONP?

• Intel ONP is based on high-volume, industry-

standard servers, which deliver predictable

performance updates.

• Periodic server platform improvements

follow Moore’s Law, resulting in platforms

with more cores, better memory bandwidth

and efficiency, and a range of performance

options. Therefore, ONP becomes a strong

foundation for predictable, continuous system

performance improvements in the future.

• Virtualization (i.e., compute and IO)

optimizations yield more efficient use

of existing and future server platforms.

• Periodic microarchitecture and instruction

set improvements deliver better networking

workload performance.

• Trusted compute platform support creates

a stable, secure, physical and virtual node

for SDN and NFV deployments.

• ONP for server reference architecture

is a foundation for NFV developers.

– Open software and open standards

yield flexible implementation

options as delivered by key

operating system providers.

– Optimizations via Intel DPDK, Intel

QuickAssist Technology, and Ethernet

IO workload balancing on the packet

processing layer provide a common

platform architecture that can be used

at all three levels of SDN (orchestration,

control, and node).

– A roadmap for continuous open-source

contributions address the latest solutions

for SDN and NFV use conditions.

• ONP is delivered by an open community

of solutions.

– Intel Network Builders NFV building

blocks—OS, VMM, VNF—which offer

a range of implementation choices.

Delivering the ONP for servers through the

established industry ecosystem gives CSPs a

strong foundation to develop and implement SDN

and NFV solutions. Intel and HP are collaborating

to support CSPs in their network transformation

by creating an ecosystem of solution providers

that are joining us in delivering qualified network

workloads on HP’s Intel-based reference

platforms. An example of this is the Intel ONP

that shows significant performance improvement

in HP ProLiant Servers and Blades. HP has taken

these key learnings in collaboration with Intel

and has integrated key optimizations across

Open vSwitch to deliver HP Helion to provide

commercial solutions targeting ETSI Network

NFV use cases.

HP and Intel’s collaboration delivers

development platform solutions today.

Together, Intel and HP are developing a

credible future roadmap for CSPs to get

the most out of their deployed servers. We

are ready today to work together with the

ecosystem and customers to deploy customer

trials on these solutions.

Frank SchapfelSenior Marketing Manager, Intel Corporation


Are SDN and NFV on a convergence path? The IT industry’s evolution toward total virtualization is in high gear. We can’t read any IT publications today without coming across front page articles on “SDN this” and “NFV that.” However, most of what the vendors are doing today is very focused on either one or the other. And, maybe that’s for the best initially, to get solid solutions that solve real business challenges and not just technology for technology’s sake.

Fact is, most vendors focused on building

solutions around each of these are so focused

that they aren’t considering the logical

integration and inevitable infusion of the two

together into environments such as enterprises

and data centers. Today, software-defined

networking (SDN) is primarily focused on data

center applications only, with discussions

around use at communications service

providers (CSPs) only recently beginning to

happen. On the contrary, network functions

virtualization (NFV) has been exclusively

CSP-focused with no discussion around its

application in the data center, nor other

enterprise environments.

KEMP Technologies and HP see the eventual

integration of these technologies for very

logical reasons. First, SDN is primarily focused

on optimizing how routing and switching

technology in the data center can be better

utilized for traffic-specific optimization

and automation through separation of

the data plane and control plane. This

gives the network operator and network

controller a much broader view of the overall

infrastructure, rather than a view of just the

hardware on which the functions reside. By

implementing SDN technology and creating

the operational efficiencies around it, there

are very promising CapEx and OpEx savings

on the horizon.

KEMP and HP have already demonstrated this

business case with the KEMP SDN adaptive

application in which the KEMP LoadMaster

product utilizes the layer 2 information from

the switches in the infrastructure that is

collected by the HP VAN controller to make more

intelligent application load-balancing decisions.

This was not possible prior to SDN because

load balancers had no awareness of what was

happening in the switching infrastructure.


NFV is more focused on the network

application services that would normally run

within the infrastructure, more specific to the

applications, or users. Services seen today

in hardware appliances like load balancers,

firewalls, intrusion prevention, SSL, caching,

web application firewalls, and even VPN

services are being created in software. Now,

in this technology it is very important to

note that simply porting from hardware to

software is not enough. The vendors must

also include the functions that really make

virtualized network functions valuable: their

ability to be provisioned, configured, scaled,

and deprovisioned through automation

compliant with specific business and security

policies. Then, all of these services must also

be “open” enough that they can integrate and

interoperate with other third-party services,

management, and orchestration tools. HP

and KEMP proved this functionality recently

at the Intel® IDF event in San Francisco where,

using the HP NFV Director, OpenStack, and the

virtual LoadMaster product from KEMP, we

were able to automate the workload creation

of a virtual load-balancing instance in the

NFV infrastructure.

For an enterprise, CSP, government, or any

other organization to have the ability to not

only manage, program, and set policy for their

routing and switching infrastructure but also

automate provisioning, scale and movement

of network services—all through automation

associated with their business needs—is an

absolute triumph for all involved. That is what

the integration of SDN and NFV promises for

the future of IT. That is what both HP and KEMP

are investing heavily in today and in the future.

Michael WorlundTechnical Director, Strategic Alliances and

Product Management, KEMP Technologies Inc.


A scalable solution to meet the demands of today and the future


Increasing costs due to high bandwidth processing in remote locations, as well as the placement of duplicate services in each location are driving consolidation to regional data centers. Consolidation enables telecom providers to reduce cost through virtualization and maximize performance while reducing latency. Pools of centralized baseband processing connected with high-performance, low-latency platform interconnects are now possible. HP is a leading provider of high-performance C-class x86 blade servers and blade interconnect solutions from Mellanox supporting 40 Gb Ethernet adapter and switching solutions. The combined power of 40 Gb Ethernet, HP blades, and network functions virtualization (NFV) reduces subscriber costs and enables a scalable solution to meet the demands of both today and the future.

Together Mellanox and HP have demonstrated

a successful Tier 1 carrier proof of concept

(PoC) running more than 50 servers with

40 GbE interconnect using SR-IOV, and

delivering bare metal performance to virtual

machines (VMs) in an OpenStack environment.

In this article we will share the details of

the PoC, and why HP servers with high-

performance Mellanox interconnect deliver the

best application performance with hardware-

based acceleration for messaging, network

traffic, and storage.

Performance can be extended with the

Mellanox Poll Mode Driver (PMD) combined

with a high-performance open virtual

switch (OVS) supporting VM acceleration.

Solutions based on this technology can reach

throughput performance receive rates near

195 Gbps and 16 million packets per second

(Mpps). HP and its partners demonstrated

maximum performance available on blade and

rack mount X86_64 server platforms using

Mellanox PMD drivers and the open source data

plane development kit (DPDK).

Using HP NFV solutions based on Mellanox

technologies allows service providers to

create cloud services that offer virtually

limitless growth and capitalize on their

broad range of distributed data center and

network resources. By building HP NFV carrier

clouds, service providers can meet stringent

service-level agreements (SLAs) and deliver

the performance, access, and security that

enterprises and consumers demand.

Glenn ChurchSenior Solution Architect, Mellanox Technologies


NFV gets carrier grade For the past few years, the telecommunications industry has been frantically working to accelerate the development and deployment of network functions virtualization (NFV). Many of the existing proof-of-concept projects utilize technologies leveraged from the IT industry to solve various technical use cases of building a virtualized infrastructure. This has been useful for proving that NFV can work, but deploying virtualized services in a carrier network requires much more consideration.

The telecommunications industry has built the

critical communication infrastructure our world

has come to rely on. Economies, governments,

emergency agencies, and the public expect the

network to be “always on,” with immediate

access to voice, data, and services. For NFV

to be successful in telecommunications, it

must be built on a foundation of carrier-grade

software that ensures 99.9999% service

availability, allowing no more than 32 seconds

of downtime per year for any server or service.

For decades, the telecommunications

industry has engineered an extensive

range of sophisticated functionality

in their networks to keep them up and

running. Typically, this functionality can

be categorized into four key areas:

• Availability: A telecom network must provide

high levels of redundancy, even over a

geographic range of 500 kilometers, to allow

continued operation in the event of a natural

disaster, such as a hurricane or earthquake.

When faults occur, the virtual machine (VM)

infrastructure must recover in less than 500

milliseconds. The network should not drop

calls or lose data during failovers.

• Security: All observable traffic in a 4G

network must be encrypted, and visible user

data cannot be stored in the system. For

an NFV data center or cloud deployment,

operators will need to implement multitenant

isolation and security to ensure that

subscribers can’t access one another’s traffic

or data. Among other things, the network

must also fully implement authentication,

authorization, and accounting (AAA) security

protocols to prevent unauthorized access,

hacking, or attacks.

• Performance: A carrier-grade network must

achieve both high throughput and very low

latency for critical real-time applications. In

an NFV architecture, throughput depends on

the performance of the host virtual switch

(vswitch), which determines the bandwidth

delivered to virtual machines. For latency,


the platform must ensure a deterministic

interrupt latency of 10 microseconds or

less to ensure virtualization’s feasibility

for the most demanding customer premise

equipment (CPE) and access functions.

• Network management: A carrier-grade

system must eliminate any unscheduled

downtime for network maintenance. To

prevent this downtime, it must support

hitless software upgrades and hitless

patches. The backup and recovery

system must be fully integrated with the

platform software. Also, support must be

implemented for “northbound” APIs that

interface the infrastructure platform to the

operations support system (OSS)/business

support system (BSS) and NFV orchestration

software, including SNMP, Netconf, XML,

REST APIs, and ACPI.

Because many types of software elements

used across the architecture must meet

these requirements, an NFV platform must

be designed from the ground up to succeed—

and you can’t achieve these requirements by

starting with technology originally designed for

IT-class reliability.

In an effort to accelerate NFV deployments in a

telecommunication network, HP and Wind River

are collaborating to deliver the industry’s most

comprehensive, open standards-based carrier-

grade NFV software platform. Leveraging

HP’s legacy of cloud innovation, OpenStack's

leadership with the telecom experience and

proven carrier-grade technologies of Wind

River, the two companies will deliver a scalable

off-the-shelf NFV infrastructure platform that

provides six nines (99.9999%) reliability and

the performance required for carrier networks.

Now, customers can leverage a single software

platform, fortified with carrier-grade capability,

to build and deploy new virtualized services.

Glenn SeilerVice President, Networking Products, Wind River

Why HP?Network functions virtualization success factorsThe HP OpenNFV Program provides CSPs and their suppliers the

foundation upon which to build a dynamic service and network

environment. HP’s OpenNFV platform accelerates the design,

proof-of-concept, trial, and deployment of new cloud-enabled

network services while lowering CapEx, OpEx and risk.

An open, standards-based system enables CSPs to work with a variety of vendors to introduce innovative new services.

Open architectureHP is fully committed to openness at all layers of our NFV architecture.

StandardsHP is actively involved in ETSI, CloudEthernet Forum, Open Daylight, ONF, OPNFV, OpenStack, TM Forum, and more.

PartnersThe HP OpenNFV Partner Program gives CSPs the freedom of choice to work with the right vendors to meet their needs.

LabsHP OpenNFV Labs provide a testing center to make sure applications are ready to be deployed in carrier networks.

CSPs need a strong, carrier-grade foundation for NFV, leveraging OpenStack as a platform.

Building blocksHP provides the key ingredients for NFV—standard high-volume Ethernet switches, high-volume storage, servers, and software.

OrchestrationHP NFV Director combines HP capabilities in OSS and IT management for comprehensive, multivendor NFV orchestration.

Carrier gradeHP Helion coupled with Wind River’s carrier-grade Linux and KVM will provide a fully integrated cloud solution and carrier-grade platform.

OpenStackHP has been a consistent leader in contributions to OpenStack, defining the next-generation computing platforms.

Moving to NFV is a huge transformation, and carriers may need some help along the way.

ServicesAvailable at every layer, HP OpenNFV Services offer a proven way to navigate the NFV transformation of your network functions.

NFV testing and integration servicesMulti-point testing and integration are available at various points across the NFV stack, within the different layers, as well as holistically.

ExperienceWe've been building carrier-grade network solutions for 30 years, and we have a rich heritage in both the carrier network and the IT environment.

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Intel is a trademark of Intel Corporation in the U.S. and other countries. Linux is a registered trademark of Linus Torvalds in the U.S. and other countries.

4AA5-6075ENW, November 2014

Rate this documentShare with colleagues

Sign up for updates hp.com/go/getupdated

https://hpresearch.az1.qualtrics.com/SE/?SID=SV_6EuQKOr2Ku1CUzH&CMG=197&Pubnumber=4AA5-6075ENW&BU=Cloud&Doctype=INBrochure

http://www.facebook.com/sharer.php?u=http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA5-6075ENW.pdf

http://twitter.com/home/?status=Industry%20Edge:%20Network%20Functions%20Virtualization%20Edition+%40+http%3A%2F%2Fh20195.www2.hp.com%2FV2%2FGetDocument.aspx?docname=4AA5-6075ENW

http://www.linkedin.com/shareArticle?mini=true&ro=true&url=http%3A%2F%2Fh20195%2Ewww2%2Ehp%2Ecom%2FV2%2FGetDocument%2Easpx%3Fdocname%3D4AA5-6075ENW&title=Industry+Edge:+Network+Functions+Virtualization+Edition+&armin=armin

http://www.hp.com/go/getupdated

HP NFV ezine v2 dec 2014

Technology

Transcript of HP NFV ezine v2 dec 2014