1. 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

2. The new business
of the network
The 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 Gillai
Senior Vice President/Chief Operations
Officer, HP Cloud and General Manager,
NFV, HP

3. 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. 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.

5. 5NFV Edition—Update
Openness,standards,
andchoice
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
applications
HP 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.

6. 6 NFV Edition—Update
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 management
To 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
services
There 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 Gillai
Senior Vice President/Chief Operations
Officer, HP Cloud and General Manager,
NFV, HP

7. 7NFV Edition—Update

8. 8 NFV Edition—Update
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
criteria
The 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.

9. 9NFV Edition—Update
Figure 1. Functions to virtualize—from easiest to hardest
Category Examples
Security 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
criteria
One 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
orchestration
NFV 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.

10. 10 NFV Edition—Update
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 first
Look 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 Edlund
CTO, Communications,
Media & Entertainment, HP

11. 11NFV Edition—Update

13. 13NFV Edition—Update
Why software-defined
networking matters
in network functions
virtualization
In 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 scenario
SDN 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.

14. 14 NFV Edition—Update
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.

15. 15NFV Edition—Update
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 more
For more information, visit hp.com/go/nfv.
Prodip Sen
CTO, Network Functions Virtualization,
HP
CPE Access
WAN
facing
ToR
switch
Server
ToR
switch
WAN
facing
Internet
access
router
Figure 3. The WAN network view

16. 16 NFV Edition—Update
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.

17. 17NFV Edition—Update
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

18. 18 NFV Edition—Update
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.

19. 19NFV Edition—Update
How HP can help
HP 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 started
It 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 Edlund
CTO, 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

20. 20 NFV Edition—Update
Network functions
virtualization use cases
Proof-of-concept projects
Commitment to
openness and
collaboration
The 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.
Over20 activeproof-
of-concept projects
Today 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

21. 21NFV Edition—Update
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 Saxena
Chief Architect, Network Functions
Virtualization, HP
Marie-Paule Odini
Chief Technologist Office,
Communications, Media & Entertainment,
HP
Figure 1. HP participation in ETSI-accepted PoCs
ETSI PoC Title Collaborators Status
PoC#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
Demonstrated at SDN & OpenFlow
World Congress, Oct. 2014.
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
Demonstrated at SDN & OpenFlow
World Congress, Oct. 2014.
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.

22. 22 NFV Edition—Update
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

23. 23NFV Edition—Update
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 Jarich
Vice President, Consumer and
Infrastructure, Current Analysis

25. A robust ecosystem
of partners
HP’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 Schaefer
Vice President, GTM, Network
Functions Virtualization, HP

26. 26 NFV Edition—Update
Accelerating the
delivery of services
with network functions
virtualization
To 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

27. 27NFV Edition—Update
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 Pimpalkhute
Senior Product Marketing Manager, A10 Networks
Prashanth Chittapuram
Senior Product Marketing Manager, A10 Networks

28. 28 NFV Edition—Update
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.

29. 29NFV Edition—Update
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 Barkai
Co-founder, ConteXtream

30. 30 NFV Edition—Update
A foundation for
SDN and NFV
Developing 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.

31. 31NFV Edition—Update
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 Schapfel
Senior Marketing Manager, Intel Corporation

32. 32 NFV Edition—Update
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.

33. 33NFV Edition—Update
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 Worlund
Technical Director, Strategic Alliances and
Product Management, KEMP Technologies Inc.

34. 34 NFV Edition—Update
A scalable solution to
meet the demands of
today and the future

35. 35NFV Edition—Update
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 Church
Senior Solution Architect, Mellanox Technologies

36. 36 NFV Edition—Update
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,

37. 37NFV Edition—Update
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 Seiler
Vice President, Networking Products, Wind River

38. Why HP?
Network functions virtualization
success factors
The 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 architecture
HP is fully
committed to
openness at all
layers of our NFV
architecture.
Standards
HP is actively
involved in ETSI,
CloudEthernet
Forum, Open
Daylight, ONF,
OPNFV, OpenStack,
TM Forum,
and more.
Partners
The HP OpenNFV
Partner Program
gives CSPs the
freedom of choice
to work with the
right vendors to
meet their needs.
Labs
HP OpenNFV Labs
provide a testing
center to make
sure applications
are ready to be
deployed in carrier
networks.

39. CSPs need a strong, carrier-grade foundation for NFV, leveraging OpenStack as a platform.
Building blocks
HP provides the
key ingredients for
NFV—standard
high-volume
Ethernet switches,
high-volume
storage, servers,
and software.
Orchestration
HP NFV Director
combines HP
capabilities
in OSS and IT
management for
comprehensive,
multivendor NFV
orchestration.
Carrier grade
HP Helion coupled
with Wind River’s
carrier-grade
Linux and KVM
will provide a
fully integrated
cloud solution
and carrier-grade
platform.
OpenStack
HP 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.
Services
Available at every
layer, HP OpenNFV
Services offer a
proven way to
navigate the NFV
transformation
of your network
functions.
NFV testing
and integration
services
Multi-point testing
and integration are
available at various
points across the
NFV stack, within
the different
layers, as well as
holistically.
Experience
We'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.

40. © 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