NFV For Dummies PDF

These materials are © 2016 John Wiley & Sons, Inc.
Any dissemination, distribution, or unauthorized use is strictly prohibited.

Network Functions
Virtualization
Hewlett Packard Enterprise

Special Edition
by Balamurali Thekkedath
These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Network Functions Virtualization For Dummies®, Hewlett Packard Enterprise Special Edition
Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030‐5774
www.wiley.com
Copyright © 2016 by John Wiley & Sons, Inc., Hoboken, New Jersey
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the
prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com,
Making Everything Easier, and related trade dress are trademarks or registered trademarks of John
Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used
without written permission. All other trademarks are the property of their respective owners. John
Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE

NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR
COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL
WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A
PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR
PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE
SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE
PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL
SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT
PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR
SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION
OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE
OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER
ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR
RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET
WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN
THIS WORK WAS WRITTEN AND WHEN IT IS READ.
ISBN 978‐1‐119‐14992‐7 (pbk); ISBN 978‐1‐119‐14993‐4 (ebk)

Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
For general information on our other products and services, or how to create a custom For
Dummies book for your business or organization, please contact our Business Development
Department in the U.S. at 877‐409‐4177, contact info@dummies.biz, or visit www.wiley.com/
go/custompub. For information about licensing the For Dummies brand for products or s ervices,
contact BrandedRights&Licenses@Wiley.com.
Publisher’s Acknowledgments
Some of the people who helped bring this book to market include the following:
Development Editor: Elizabeth Kuball Production Editor: Siddique Shaik

Copy Editor: Elizabeth Kuball Special Help: Elizabeth Palmer,
Acquisitions Editor: Katie Mohr Scott Lindsay, Daniel Montesanto,
Melody Howard Yuhn, CEH, CISSP;
Editorial Manager: Rev Mengle Andreas Krichel
Business Development Representative:
Karen Hattan
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About This Book......................................................................... 1
Foolish Assumptions.................................................................. 2
Icons Used in This Book............................................................. 2
Beyond the Book......................................................................... 3
Where to Go from Here.............................................................. 3
Chapter 1: Telecommunications Industry

Challenges and Opportunities . . . . . . . . . . . . . . . . . . . . 5
Industry Challenges and Opportunities................................... 5
The Origins of NFV...................................................................... 7
Chapter 2: What Is NFV?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

NFV Defined................................................................................. 9
ETSI NFV Framework................................................................ 10
NFV Business Goals and Challenges....................................... 12
Business goals enabled by NFV.................................... 12
NFV challenges................................................................ 13
Chapter 3: NFV Components: Network Functions

Virtualization Infrastructure. . . . . . . . . . . . . . . . . . . . . 17
Hardware Resources................................................................ 17
Virtual Resources and the Virtualization Layer.................... 18
Chapter 4: NFV Components: VNF and EMS. . . . . . . . . . 21

Virtual Network Functions....................................................... 21
Element Management System................................................. 23
Chapter 5: NFV Components: Management

and Orchestration (MANO). . . . . . . . . . . . . . . . . . . . . . 25
The Virtualized Infrastructure Manager................................ 25
VNF Manager............................................................................. 27
NFV Orchestration.................................................................... 28
iv Network Functions Virtualization For Dummies
Chapter 6: Complementing NFV with OSS

Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Driving OSS Transformation.................................................... 32
Getting Started with OSS Transformation............................. 33
Chapter 7: NFV Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 35

Virtualization of Mobile Core Network and
IP Multimedia Subsystem..................................................... 35
NFVIaaS...................................................................................... 36
VNFaaS....................................................................................... 37
VNPaaS....................................................................................... 37
VNF Forwarding Graphs........................................................... 38
Virtualization of Mobile Base Station..................................... 38
Virtualization of the Home Environment............................... 39
Virtualization of Content Delivery Networks........................ 39
Fixed‐Access NFV...................................................................... 40
NFV and Software‐Defined Networking.................................. 41
Chapter 8: HPE’s Approach to NFV. . . . . . . . . . . . . . . . . . 43

HPE OpenNFV Reference Architecture.................................. 45
A New Vision for OSS................................................................ 47
The HPE OpenNFV Partner Program...................................... 49
HPE OpenNFV Labs................................................................... 50
NFV Proof‐of‐Concept Projects............................................... 50
Transformation Services.......................................................... 51
Chapter 9: Things to Consider When Transforming

to an NFV‐Enabled CSP Infrastructure . . . . . . . . . . . . 55
Financial and Business............................................................. 55
Technology and Architecture................................................. 56
Operations and Processes....................................................... 57
Organization.............................................................................. 57
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Introduction
C ommunications service providers (CSPs) are evolving
their infrastructures at a rate rarely seen since the
industry’s transformation from analog to digital — and much
faster than the shift from time‐division multiplexing (TDM) to
Internet Protocol (IP).
This transformation is profound and holds a lot of promise —

it’s impossible to ignore the implications. CSPs have an oppor-
tunity to move from disrupted to disruptor — and return to
the epicenter of the telecommunications ecosystem.
To do so, CSPs must embrace “IT‐ification” — the application

of mainstream IT technologies and techniques that have been
developed and adopted by enterprise segments to increase
their efficiency, customer responsiveness, and agility. While
managing this transformation, they must bridge their current
view of the network to the new network — there is no such
thing as “greenfield” here. And, because no single vendor can do
it all — CSPs must leverage an open, multivendor ecosystem.
Network functions virtualization (NFV) offers a new way for

CSPs to design, deploy, and manage networking services. By
decoupling the network functions from proprietary hardware
appliances and embracing virtualization and cloud technolo-
gies and techniques, CSPs can accelerate the introduction of
new, compelling services quickly and cost‐effectively. NFV
enables CSPs to reset the cost base of their network opera-
tions and create the flexible service delivery environments
they need to innovate more quickly and drive revenue.
About This Book

This book provides an in‐depth examination of NFV, including
the individual components of the NFV Reference Architecture
and Hewlett Packard Enterprise’s vision for the future of NFV.
2 Network Functions Virtualization For Dummies
Throughout the book, you’ll find lots of acronyms. In the

interest of readability, I don’t spell out every acronym. These
terms are defined in the Glossary at the end of the book. So, if
you come across an acronym you’re unfamiliar with, just turn
to the Glossary to find out what it means.
I would like to acknowledge the use of ETSI NFV Working

Group documents as a reference for many sections of this
book.
Foolish Assumptions
It has been said that most assumptions have outlived their
uselessness, but I assume a few things nonetheless:
✓✓You work in the telecommunications industry. Perhaps

you work for a CSP, a network equipment provider
(NEP), an independent software vendor (ISV), or a
service integrator (SI). As such, you’re broadly familiar
with telecommunications and networking concepts,
fundamentals, and terminology.
✓✓You’re somewhat familiar with virtualization technol-
ogy. You don’t experience anxiety attacks and hyperven-
tilate when someone starts talking about hypervisors.
✓✓You’re a business or technical decision maker in your
organization and you’re interested in learning about
NFV. If that’s the case, then this is the book for you!
Icons Used in This Book

Throughout this book, I use special icons to call attention to
important information. Here’s what you can expect:
This icon points out information that may well be worth com-
mitting to your nonvolatile memory, your gray matter, or your
noggin — along with anniversaries and birthdays!
You won’t find a map of the human genome in this book, but
if you seek to attain the seventh level of NERD‐vana, perk up!
This icon explains the jargon beneath the jargon!
Introduction 3
Thank you for reading. Hope you enjoy the book. Please take
care of your writers! Seriously, this icon points out helpful
suggestions and useful nuggets of information.
Proceed at your own risk . . . well, okay — it’s actually nothing

that hazardous. These useful alerts offer practical advice to
help you avoid making potentially costly mistakes.
Beyond the Book

Although this book is chock‐full of information, there’s only
so much I can cover in this book! So, if you find yourself at the
end of this book, thinking, “Gosh, this was an amazing book!
Where can I learn more?,” just go to www.hpe.com/csp/nfv.
There, you can learn more about NFV.
Where to Go from Here

With my apologies to Lewis Carroll, Alice, and the Cheshire Cat:
“Would you tell me, please, which way I ought to go from

here?”
“That depends a good deal on where you want to get to,” said
the Cat — err, the Dummies Man.
“I don’t much care where . . . ,” said Alice.
“Then it doesn’t matter which way you go!”
That’s certainly true of Network Functions Virtualization For

Dummies, which, like Alice in Wonderland, is also destined to
become a timeless classic!
If you don’t know where you’re going, any chapter will get you
there — but Chapter 1 might be a good place to start!
However, if you see a particular topic that piques your interest,

feel free to jump ahead to that chapter. Each chapter is indi-
vidually wrapped (but not packaged for individual sale) and
written to stand on its own, so you can start reading anywhere

and skip around to your heart’s content! Read this book in any
order that suits you (though I don’t recommend upside down
or backward).
I promise you won’t get lost falling down the rabbit hole!
Chapter 1
Telecommunications
Industry Challenges
and Opportunities
In This Chapter
▶▶Recognizing current challenges and opportunities
▶▶Looking back at NFV’s beginnings
I n this chapter, you explore several telecommunications

industry trends that are driving NFV and how it evolved.
Industry Challenges
and Opportunities
We are living in an increasingly hyperconnected world —
and it’s not just humans that are connected anymore —
the Internet of Things (IoT) is creating new connectivity
requirements and scenarios for our world! The CSPs who
are responsible for providing this connectivity are facing
an exponential rise in traffic and the number of subscribers
on their networks. Today, CSPs are facing challenges on mul-
tiple fronts:
✓✓Exploding demand: Analysis Mason forecasts that global

mobile data traffic will reach 60,427 petabytes (PB) in
2016, an increase of 54 percent from 2015. The rapid
growth is set to continue through 2020, when mobile data

levels are estimated to reach 228,491 PB.
✓✓Shifting landscape: Increasing relevance of applications
over pure connectivity and a new breed of competitors
with new business models — for example, from over‐
the‐top (OTT) players, such as Hulu and Netflix, who are
agile, flexible, and able to roll out revenue‐generating
services much faster. Changing and ever‐increasing con-
sumer expectations for personalized services and experi-
ences also up the ante for CSPs.
✓✓Inability to offer new services to users rapidly and
dynamically: Current CSP networks are built on mono-
lithic, largely proprietary infrastructures. Manual
management and workflow processes prevent CSPs
from quickly adapting and delivering the innovative new
services and applications that consumers demand.
✓✓Growing capital expenditures (CAPEX) and operating
expenses (OPEX) and stagnant or declining revenues:
With applications and OTT services capturing wallet
share, CSPs are experiencing flat or declining revenues
from existing residential consumers. However, traffic
growth is continuing unabated and CSPs are forced to
invest CAPEX and OPEX to keep up with rising demand.
Traditionally, CSPs have not been able to optimize their

resource usage because they have to engineer their networks
for peak traffic rates. Their new competitors have been using
a more efficient way to manage delivery of multiple networked
applications and maximize resource utilization by deploying
shared, virtual infrastructure — technology that has been
prevalent in enterprise IT organizations for more than a
decade now.
Network functions virtualization (NFV) applies virtualization

technologies to the traditional network functions and the
associated value‐added applications or service functions that
CSPs use in their network infrastructure, enabling them to
reduce cost and improve time‐to‐market.
NFV is transforming the way that CSPs architect and design

parts of their networks. Using standard IT virtualization tech-
nologies, NFV allows a CSP to consolidate the plethora of
applications and specialized network equipment they use in
their network onto industry‐standard high‐volume servers,
Chapter 1: Industry Challenges and Opportunities 7
switches, and storage. NFV ensures that CSPs will automati-
cally benefit from any major advances and disruptive innova-
tions that appear in IT.
NFV enables significant benefits through deployment of

virtualized network functions and applications on a shared
infrastructure:
✓✓Creating new revenue opportunities: New applications

that target specific market needs or specific market seg-
ments can be quickly tested and deployed at the scale
required. With NFV, the CSP network can become a plat-
form on which an ecosystem of independent software
vendors can quickly bring new applications and innova-
tions to market.
✓✓Increasing flexibility and agility with cloud-style fulfill-
ment models: Applications and services can be readily
updated and deployed without unnecessary delays,
speeding time‐to‐market.
✓✓Simplifying the planning and scaling of the network:
New hardware can be quickly added, allowing CSPs to
add or delete application or service capacity on demand
to meet the elastic needs of the traffic, without long net-
work equipment procurement cycles.
✓✓Reducing CAPEX and OPEX: Improved utilization of
equipment and wider adoption of industry standard
servers for core telecom applications in a shared
compute/storage infrastructure enable significant CAPEX
savings. CSPs can run their networks more efficiently,
with a high level of automation, and reuse a shared pool
of compute/storage resources for various functions.
Additionally, having a uniform infrastructure produces
operational savings by reducing management complexity
and its associated cost. This frees up valuable resources
to innovate and create truly differentiated service offer-
ings for consumers and businesses.
The Origins of NFV

Capitalizing on the technology advances that emerged from the
software‐defined networking (SDN) movement, and the move
to virtualization and the cloud in data centers, the NFV concept
emerged as a call to action by a global group of t elecom

industry operators in 2012. The Industry Specification Group
on NFV (NFV ISG) forum was formed under the European
Telecommunications Standards Institute (ETSI) to address this
issue. The group published the first formal definition of NFV —
the “NFV Architectural Framework” — in 2013.
The NFV industry movement began with the goal of saving

capital equipment costs by transferring network functions
from expensive proprietary platforms to commodity servers.
Over time, network operators have become more interested
in other benefits, starting with improved operations efficiency
and moving to building new service revenues through agile
service creation.
Chapter 2
What Is NFV?
In This Chapter
▶▶Understanding NFV
▶▶Building a framework for NFV
▶▶Recognizing NFV business goals and challenges
I n this chapter, you learn about network functions virtual-

ization (NFV) — what it is, how the different architectural
components work together, how it’s used, and how organiza-
tions can benefit from NFV.
NFV Defined
Today’s telecom networks are primarily built using specialized,
often proprietary, equipment. (In the telecom industry,
proprietary often means a technology or solution that is owned
by a single company.) Some examples of typical telecom
equipment are routers, switches, base stations, firewalls,
voice gateways, and IMS and Mobile Packet Core. These types
of equipment are typically monolithic in design; that is, they
consist of hardware, software, and associated management
systems.
This type of architecture often leads to silos of operations,

vendor lock-in, and the inability to respond to changing
demands in an agile way.
NFV redefines the way typical network functions are delivered

and operated in a CSP network. Using standard IT virtualization
and cloud technologies, NFV defines an architecture where
the network functions and applications are implemented
as software-only entities and are designed to be independent
of the hardware. These software entities use standard
off-the-shelf compute and storage elements as the hardware
platform.
This new architecture provides CSPs with an open platform

on which innovative software functions and applications
from a diverse vendor ecosystem can be implemented. NFV
provides a way for CSPs to increase their service and busi-
ness agility and provide innovative services to their customer
base. NFV also helps CSPs optimize resource usage and thus
reduce both capital and operating expenses.
ETSI NFV Framework

The European Telecommunications Standards Institute (ETSI)
is a recognized regional standards body made up of CSPs
working together to define frameworks for solutions used in
their networks. These standards and frameworks are used as
a base by vendors when creating their offerings, ensuring that
they are addressing the carriers’ requirements.
The ETSI NFV Industry Specification Group (ISG) has defined

a high‐level functional architectural framework for NFV
(see Figure 2‐1). Note: The figure includes references for
interfaces between the different architectural components.
Explanation of these interfaces is beyond the scope of this
book.
Chapter 2: What Is NFV? 11
Figure 2-1: High‐level NFV architectural framework.
The ETSI NFV framework consists of three major components:
✓✓Network Functions Virtualization Infrastructure (NFVI):

A subsystem that consists of all the hardware (servers,
storage, and networking) and software components on
which Virtual Network Functions (VNFs) are deployed.
This includes the compute, storage, and networking
resources, and the associated virtualization layer
(hypervisor).
✓✓Management and Orchestration (MANO): A subsystem

that includes the Network Functions Virtualization
Orchestrator (NFVO), the virtualized infrastructure
manager (VIM), and the Virtual Network Functions
Manager (VNFM).
✓✓Virtual Network Functions (VNFs): VNFs are the
software implementation of network functions that are
instantiated as one or more virtual machines (VMs) on
the NFVI.
The NFV framework proposes virtualized, software‐only

entities referred to as VNFs running on virtual assets c reated
by a virtualization layer from a pooled set of physical
hardware resources that comprise the NFVI.
NFV Management and Orchestration (MANO) provides

orchestration and lifecycle management of the virtualized
software resources of the NFVI and the VNFs, as well as
any virtualization‐specific management tasks in the NFV
framework.
NFV Business Goals

and Challenges
NFV is a radical shift in the design and use of telecom infra-
structure and will no doubt have a significant impact on the
way services are offered by CSPs and the way we, as consum-
ers, experience these services.
Business goals enabled by NFV

NFV transformation promises to bring major business, tech-
nology, and operational benefits to increase carriers’ competi-
tiveness. By adopting NFV, carriers can expect
✓✓Greater business agility: The ability to offer new serv

ices to cater to changing consumer demands, rapidly
scale applications up or down, and move applications in
the network as desired (for example, closer to the cus-
tomer, centralized, or distributed).
✓✓New opportunities and more innovation: Innovative
new business opportunities are possible with virtualiza-
tion technologies and a platform that can host appli-
cations developed in a collaborative ecosystem. NFV
encourages innovation by enabling CSPs to adopt a fast
fail approach to introduction of new services. Since
the cost and effort in introducing and rolling out new
services is much lower, new services that were consid-
ered too risky to try out can now be experimented with
in a controlled manner.
✓✓Faster time‐to‐market: Rapidly introduce new services
by reducing the time it takes to deploy and validate new
software applications (from months to minutes).
✓✓Improved business processes: Virtualization enables
applications to be decoupled from their underlying infra-
structure. This creates opportunities for automation and
business process management (BPM) re‐engineering
initiatives.
✓✓Optimized OPEX: Dedicated telco hardware requires
specialized skills to support and maintain. Virtualization
on industry‐standard platforms that are more readily
supported by IT personnel helps to reduce operating
expenses. The higher level of automation enabled by NFV
also reduces the amount of manual effort required in con-
figuration and service creation and consequently reduces
the operating expenses.
✓✓Lower CAPEX: Moving from dedicated telco appliances
sized for peak demand to virtualization on industry‐
standard IT infrastructure enables better capacity utiliza-
tion and on‐demand scalability, which helps to eliminate
or delay further investments in expensive, specialized
infrastructure.
These benefits will provide CSPs with a unique opportunity to

be more efficient by leveraging virtualization to improve their
operational capabilities from end‐to‐end.
NFV challenges
Although NFV offers many benefits for service providers, it
will impact future organizations and create challenges for
operations and operations support systems (OSS). Unless
addressed appropriately, these challenges can impact a
s uccessful transformation. They can be classified into three

categories: infrastructure, operations, and services.
Infrastructure challenges
The infrastructure challenges with NFV transformation come
from the introduction of new types of components in the
network, originating from the IT world and based on industry‐
standard platforms. These components need to provide
telco‐grade availability and high performance, and meet the
stringent SLAs that are typical in the CSP world.
Additionally, there is large installed base of legacy telco

equipment. Although much of this current infrastructure will
eventually be replaced by virtualized entities, either through
an NFV transformation initiative or normal lifecycle manage-
ment, a hybrid environment will always exist. Virtualization
of certain telco equipment won’t necessarily be feasible or
desirable in every deployment situation.
Operations challenges
A significant operational challenge of the NFV transformation
is how to maintain the customer and services views that are
tied to the underlying infrastructure. This requires integration
within existing OSS/business support systems (BSS) environ-
ments and end‐to‐end automation to enable agility and faster
service velocity.
NFV, by decoupling functions from the infrastructure, war-

rants new procedures for testing/validation/acceptance and
troubleshooting. Purchasing and planning processes and com-
petencies also need to change to be more oriented to the way
the IT domain works.
Another important operational challenge is to manage opera-

tions costs while deploying NFV. Factors contributing to this
challenge include the following:
✓✓Complexity associated with managing a hybrid environ-

ment of virtualized and legacy equipment
✓✓Complexity of managing functions implemented by a
distributed set of software entities
NFV creates an elastic relationship between services and
resources that makes SLAs and problem resolution more
difficult.
Other operational challenges that exist include the need to

restructure organizations and retool organizational competen-
cies to be able to work in an IT environment.
Service challenges
The transformation to NFV (and SDN) will eventually create
a CSP infrastructure that is programmable in real‐time and
highly automated. In order to take full advantage of the
investments in the infrastructure, CSPs will have to revamp
the way they offer services to their customers. The existing
models of a fixed number of service offerings that are ordered
from a catalog and need time to be deployed will have to
be transformed into a model that allows customers to have
self‐care portals from which they will be able to personalize
their service offers. This transformation to a personalized,
on‐demand service delivery will require changes in the way
services are created and billed. The “catalog” of services that
can be offered to a customer will need to be dynamic and
policy based. The challenges in the service domain will mainly
be in the area of managing a dynamic service offering and
its integration to the underlying infrastructure and real‐time
analytics.
Chapter 3
NFV Components: Network
Functions Virtualization
Infrastructure
In This Chapter
▶▶Recognizing the physical components of NFVI
▶▶Building a virtual infrastructure
I n this chapter, you learn the basics of the NFVI. The NFVI
is the infrastructure on which the VNFs are hosted and
executed. This infrastructure consists of hardware (compute,
storage, and networking) and software resources (like the
virtualization layer or the hypervisor that creates virtual
compute, storage, and networking resources).
Hardware Resources
Hardware that comprise the NFVI include compute, storage,
and network resources (see Figure 3‐1). These are the shared
resources that a VNF uses (through a virtualization layer) for its
processing, storage, and connectivity needs. Commercially avail-
able servers form most of the computing hardware. Storage can
either be direct‐attached storage in the servers or shared network‐
attached storage (NAS) and storage area networks (SANs).
Network resources include switching functions, such as routers
and wired (or wireless) links. Together, they can form an
NFVI point-of‐presence (NFVI PoP). An NFVI PoP is defined as
a location where a VNF can be deployed. An NFVI PoP n etwork
interconnects the compute and storage resources within a
NFVI PoP.
Figure 3-1: Hardware resources in NFVI include compute, storage, and

network.
Where a geographically distributed NFVI is required, several

NFVI PoPs might exist in many different locations. In such a
scenario, the transport networks that interconnect NFVI PoPs
are also considered to be part of the NFVI.
Virtual Resources and the

Virtualization Layer
The entire pool of physical hardware resources are
abstracted into logically partitioned, independent virtual
resources by the virtualization layer in NFVI (see Figure 3‐2).
These virtual resources are presented as an independent
entity for each VNF.
Chapter 3: NFV Components: NFVI 19
Figure 3-2: Virtual resources and the virtualization layer in NFVI.
The virtualization layer (commonly referred to as a hypervi-

sor) decouples the hardware resources of the NFVI from the
VNFs so that different software can be deployed across the
pooled hardware resources.
Virtualization technology emulates physical compute, storage,

and network resources.
A hypervisor allows one or more VMs to run on a single

host. The VM runs on the host operating system (OS) and is
allocated resources by the hypervisor.
The virtualization layer is responsible for abstracting the

underlying physical resources (compute, storage, and
network) and presenting them to the VNFs as independent
resources.
The NFV specifications do not specify a particular virtualiza-

tion layer solution for the NFV infrastructure. Instead, it just
specifies the use of virtualization technologies with standard
features and open reference points for executing the VNFs.
Besides virtualization, other cloud resource sharing techniques

like containers are also being considered for NFV. The choice
will depend on requirements for performance, security,
density, and other characteristics.
Chapter 4
NFV Components:
VNF and EMS
In This Chapter
▶▶Virtualizing physical network devices and functions
▶▶Managing network elements
I n this chapter, you learn the basics of the Virtual Network

Function (VNF) and the associated Element Management
System (EMS).
Virtual Network Functions

In traditional networks, network functions are typically imple-
mented as purpose‐built hardware appliances running pro-
prietary software. Examples of network functions are mobile
Evolved Packet Core (EPC) and its components like Mobility
Management Entity (MME), Packet Gateway
(PGW) and Service Gateway (SGW), Provider Edge (PE)
routers, firewalls, and others.
The core concept behind NFV is to implement these network

functions as pure software that runs over the NFVI. A VNF is
a virtualized version of a traditional network function, such
as a router or firewall. This concept is radically different from
the traditional implementation in many ways. Decoupling
of the software from the hardware allows the lifecycle and
development of each of these network functions in separate

cycles. Also, the decoupling allows for a model in which the
hardware/infrastructure resources can be shared across
many software network functions.
A VNF implementation (like a virtual router or virtual switch)

doesn’t usually change the essential functional behavior and
the external operational interfaces of a traditional Physical
Network Function (PNF), like a traditional router or a switch.
The VNF (see Figure 4‐1) can be implemented as a VM, mul-

tiple VMs, or a function implemented within a shared VM.
Figure 4-1: VNF in an NFV reference architecture.
Chapter 4: NFV Components: VNF and EMS 23
Running a VNF across multiple VMs may be desirable for fault
tolerance, load balancing, and scalability.
Here are a few factors to keep in mind while developing a VNF

implementation of a traditional network function:
✓✓Design for interoperability with different hypervisors.

(Hypervisors provide VNFs access to shared storage,
compute, and networking resources.)
✓✓Ensure that the process of virtualization does not create
new security threat vectors.
✓✓Ensure that the performance of the VNF is not negatively
impacted by virtualization.
Element Management System

An EMS is the management entity for network elements. It
helps to configure the network element; collects, analyzes,
and takes action on fault and performance information; and
manages security and accounting aspects of the network ele-
ment. These functions are commonly referred to as fault, con-
figuration, accounting, performance, and security (FCAPS). An
EMS performs management functions for one (one‐to‐one) or
more (one‐to‐many) VNFs (see Figure 4‐2). An EMS may itself
be a VNF in the NFV architecture.
The EMS has integration points with the following:
✓✓The VNF Manager (VNFM; see Chapter 5), to support

the VNF lifecycle management (for example, to trigger
scale‐out/‐in).
✓✓The Operations Support System (OSS, discussed in
Chapter 6), to support application configuration and
management and activation of customer services served
by that VNF.
The OSS may also be used to configure the VNF without

an EMS.
Figure 4-2: EMS in an NFV reference architecture.
Chapter 5
NFV Components:
Management and
Orchestration (MANO)
In This Chapter
▶▶Managing resources and data with the Virtualized Infrastructure
Manager
▶▶Performing lifecycle management
▶▶Managing end‐to‐end network services with the NFV Orchestrator
I n this chapter, I discuss the various components that form

the MANO subsystem.
This new mode of operation with virtualization introduces

the need for a multi-tiered and distributed management layer.
The MANO subsystem within the NFV framework is designed
to address this mode of operation.
The Virtualized Infrastructure

Manager
The VIM is the management system used to control and
manage the compute, storage, and network resources of the
NFVI (see Figure 5‐1). Multiple VIMs may be deployed in an

NFVI. Here are the key functions of the VIM:
✓✓Resource management
•• Software inventory, including hypervisors, virtual
compute, storage, and network resources
•• Resource allocation
•• Infrastructure management, including dynamic
resource assignment, power management, and
resource reclamation
✓✓Operations management
•• Visibility and management of the NFVI
•• Root cause analysis of NFVI performance issues
•• Data collection for fault, performance, capacity, and
optimization
Figure 5-1: VIM in NFV MANO.
Chapter 5: NFV Components: Management and Orchestration 27
Resource management and allocation in a virtualized environ-
ment is a complex task. Given the nature of the architecture,
all resources are shared between multiple tenants or appli-
cations, and the VIM needs to take care of the competing
requests and constraints in real‐time.
VNF Manager
The Virtual Network Function Manager (VNFM) is the
entity that manages the virtualized network functions (see
Figure 5‐2). Traditionally, the management component
of a network function focuses on Fault Management,
Configuration Management, Accounting Management,
Performance Management, and Security Management (FCAPS).
With the introduction of virtualization, additional aspects
of managing the lifecycle of the VNF become a key function
of the management component. The VNFM and the Element
Management System (EMS) are closely aligned in providing
overall management support for the VNF.
Figure 5-2: VNFM in an NFV architecture.
The key role of a VNFM is lifecycle management of the VNF.

Lifecycle management includes the following key functions.
A VNFM can perform many of the same functions as an EMS,
so the division of responsibilities between the EMS and VNFM
may be different for various network functions.
✓✓Instantiating a VNF (create a VNF) using predetermined

or prepopulated templates and parameters
✓✓Scaling up or scaling down VNFs (increase or reduce the
capacity of the VNF)
✓✓Updating and/or upgrading VNFs (support VNF software
and/or configuration changes)
✓✓Terminating VNFs (including releasing VNF‐associated NFVI
resources and returning them to the NFVI resource pool)
NFV Orchestration
While the VNF Manager is responsible for the management
and operation of individual VNFs, the NFV Orchestrator is
responsible for managing network services that span multiple
VNFs (see Figure 5‐3). The NFVO is responsible for creating
end‐to‐end services across multiple VNFs. The NFVO is also
responsible for managing the lifecycle of Network Services (NS).
The key activities in VNF lifecycle management include the

following:
✓✓Onboarding an NS — for example, registering an NS in

the service catalog (the inventory of services that can be
used to create a product offering to the customers), and
ensuring that all the required parameters and associated
rules are registered as well.
✓✓Instantiating an NS — for example, creating an NS using
the predetermined parameters or templates.
✓✓Scaling up or scaling down an NS — for example, growing
or reducing the capacity of the NS.
✓✓Updating an NS by supporting configuration changes,
such as changing inter‐VNF connectivity or the VNF
instances that are part of the service.
Chapter 5: NFV Components: Management and Orchestration 29
Figure 5-3: NFVO in NFV MANO.
✓✓Creating, deleting, querying, and updating the forwarding

rules and sequence (VNF Forwarding Graph) of an NS.
✓✓Terminating an NS — for example, terminating all the VNF
instances and requesting the release of NFVI resources
associated to the NS and returning them to the NFVI
resource pool.
In order to fulfill its responsibilities, the NFVO consumes serv

ices exposed by other functions (such as VIM functions for
orchestrating interconnection between VNFs). Similarly, the
services provided by NFVO can be consumed by other func-
tions that are authenticated and properly authorized (such
as Operations Support System (OSS) and Business Support
System (BSS).
Chapter 6
Complementing NFV with
OSS Transformation
In This Chapter
▶▶Increasing business agility with automation
▶▶Choosing an OSS transformation strategy
D espite the expanding interest in deploying NFV

and software‐defined networking (SDN) solutions,
communication service provider (CSP) networks will likely
have to contend with their existing infrastructure for a long
time. The introduction of NFV will also require the creation
of a unified management, orchestration, and operations layer
that can support the vision of service and business agility that
NFV promises — over a hybrid infrastructure. CSPs will not be
able to fully realize the agility and efficiency benefits of NFV if
they do not transform their OSS and operational processes.
Hybrid infrastructure in the context of this book means a com-

bination of virtual and physical network functions or a combina-
tion of NFV enabled and traditional network implementations.
In this chapter, you learn how NFV is driving fundamental

changes in operations systems support (OSS), by requiring
a more comprehensive service and resource management
layered approach, and impacting fulfillment and assurance
processes.
Driving OSS Transformation

Today’s OSS often consists of siloed structures with a strong
technology orientation that are rigid in their capability to
incorporate new services or bundle them together — much
like the proprietary, monolithic CSP infrastructure that, for
the most part, exists today. Service creation and delivery
within a CSP is handled by the following major components
of an OSS:
✓✓Service Fulfillment Functions that handle the service

design (idea to implement), service activation (order to
activate), and resource provisioning (plan to provision)
processes
✓✓Service Assurance Functions that cover the assurance
processes (trouble to resolve)
Today, CSPs’ operations typically view fulfillment and assur-

ance business processes individually, as silos. The people,
processes, and technology base of service onboarding to
activation (or fulfillment) is often a separate silo distinct from
service problem event generation to resolution (or assurance).
This makes it difficult to provide an end-to-end operational
perspective.
The processes implemented in today’s OSSs are also not

designed for the type of rapid instantiations and provisioning
processes that technologies like NFV and SDN bring to the
infrastructure.
The NFV management and orchestration (MANO) layer

(described in Chapter 5) takes into account management
of the NFV Infrastructure (NFVI), the Virtualized Network
Functions (VNFs), and the creation of Network Services (NSs).
However, NFV MANO does not extend the scope to creating
services across both physical (legacy telecom) and virtual
(NFV‐based) infrastructure — which will be the near‐term
reality for most CSPs.
The NFV MANO layer does, however, provide a framework for

agile service creation, which can be leveraged and adapted
as part of the transformation of the existing OSS layer to
Chapter 6: Complementing NFV with OSS Transformation 33
s upport both physical (traditional) and virtual (NFV enabled)
infrastructure — with the agility characteristic of virtual and
cloud‐based deployment models.
The NFV Framework not only provides a new set of manage-

ment components, but also supports new business models.
Both of these use cases are described in Chapter 7. Thus, the
OSS layer must evolve to support these new business models
and enable greater supplier/partner integration.
For OSS to fully leverage the agility and flexibility of NFV,

it needs to be
✓✓Automated: Manual processes should be automated

wherever possible to make operations more agile
✓✓Catalog driven: Modular and intuitive with self‐care
capabilities that empower consumers and enterprises
✓✓Intent based: Abstracting workflows to expose only the
final result
✓✓Data focused: Harnessing analytics to provide personal-
ized service offers
Getting Started with OSS

Transformation
To exploit its maximum benefits, NFV requires new thinking
around the OSS that will offer opportunities to gain additional
operational benefits. Depending on their individual strategy,
some CSPs will want to evolve their OSS incrementally to
accommodate NFV, while others will want to exploit NFV intro-
duction to make a step change in their systems. For those who
want to take the incremental path, it can be introduced in a
way that minimizes the impact on existing OSS and operations
models. For those on the step change path, NFV could provide
an opportunity to leverage NFV MANO to transform the cur-
rent OSS into a more efficient system.
Two key aspects of NFV MANO that can be leveraged to trans-

form the current OSS architecture are
✓✓Automated provisioning and configuration: NFV derives

agility from its capability to provision services in an
automated fashion. This is enabled by many underlying
aspects such as abstraction of the complex topologies,
intent‐based configuration, use of SDN controllers to be a
single point of configuration and management for certain
domains, among others. Cloud‐based approaches can tie
the relevant systems together and provide capabilities
such as zero‐touch commissioning, flow‐through provi-
sioning, and network optimization for a more efficient
development environment.
✓✓Close relationship between assurance and fulfillment
processes: NFV architecture allows for real‐time insight
into the state of the network components and inventory.
This information is invaluable to fulfillment processes as
they create new service instances.
Many current OSS infrastructures cannot support these two

key aspects of NFV MANO because the relationship between
the fulfillment and assurance domains is relatively static, with
significant latency in synchronizing inventory information
between the two domains.
Without OSS transformation, the full benefits of NFV cannot

be realized.
Chapter 7
NF V Use Cases
In This Chapter
▶▶Looking at use cases proposed for NFV
▶▶Understanding the relationship between NFV and SDN
N FV fundamentally changes the way that networks are

built, using standard IT virtualization technologies
to consolidate various types of network equipment onto
industry‐standard servers, switches, and storage. Some
possible use cases proposed for NFV by the ETSI NFV ISG
are described in this chapter.
Virtualization of Mobile Core

Network and IP Multimedia
Subsystem
Mobile networks today use many proprietary hardware
appliances and specialized equipment.
The Evolved Packet Core (EPC), which is comprised of several

specialized components, is the latest core network architec-
ture for cellular systems. NFV enables elasticity and flexibility
within the EPC. By virtualizing certain network functions, such
as the Serving Gateway (SGW), Packet Gateway (PGW), and
Mobile Management Entity (MME), these functions can scale
independently according to their specific resource require-
ments. For example, there may be cases in which data plane
resources (data intensive) need to be increased, but not nec-

essarily control plane resources (compute intensive), or vice
versa. There may also be cases where only some EPC func-
tions can be virtualized while others remain physical, or some
functions can be centralized while others are distributed. A
virtualized implementation of the EPC provides the flexibility
to achieve these efficiencies.
The IP Multimedia Subsystem (IMS) provides the service

control functions to support the provisioning of multimedia
services over EPC and other IP‐based networks, both fixed
and mobile, and is also composed of several specialized com-
ponents. Independent scaling of the various component func-
tions provides efficiencies in implementation for various use
cases like Internet of Things (IoT), smart homes, connected
cars, and many other emerging applications.
These customized implementations can run on common

shared hardware resources resulting in lower‐cost, highly
customizable, and rapidly deployable systems that can scale
dynamically. These features are ideal for the rapidly emerging
and competitive IoT marketplace.
NFVIaaS
Many CSPs today offer both cloud computing and network
services to their customers. The NFVI‐as‐a‐Service (NFVIaaS)
use case is a scenario in which a service provider can offer
its NFVI resources (such as physical compute, net‐work, and
storage) as a service on which other CSPs can run their VNFs.
In an NFVIaaS model, the tenant CSP is responsible for install-

ing, configuring and maintaining its VNFs running on the ser-
vice provider’s virtualized infrastructure.
Running VNF instances inside an NFVI operated by another

service provider is one way that service providers can meet
the service‐level agreements (SLAs) and regulatory require-
ments of their global enterprise customers, without actually
maintaining a physical presence around the globe.
Chapter 7: NF V Use Cases 37
VNFaaS
VNF‐as‐a‐Service (VNFaaS) is a model in which CSPs can
provide network functions as a service to their enterprise
without having to ship them a physical appliance.
The two most common examples of VNFaaS are Enterprise

virtualized Customer Premises Equipment (vCPE) and virtual-
ized Provider Edge (vPE) routers.
Modern enterprises are migrating ever more services and

applications to their data centers and to the public cloud
in order to support branch offices and remote locations,
enterprise mobility, and bring‐your‐own‐device (BYOD) poli-
cies. Standalone purpose‐built appliances installed at branch
offices are cost prohibitive, slow to deploy, and difficult to
maintain. At the opposite end of the spectrum, all‐in‐one
devices provide severely limited functionality. Neither of
these solutions provides enterprises with the flexibility and
agility they require. In an enterprise vCPE model, the CSP can
offer the enterprise a basic connectivity device on premises
and offer all the value‐added network functions (like firewalls
and load balancers) as a service, hosted on the CSP cloud.
vPE is an example where routing functions in a PE can

be implemented as virtual functions and offered to other
applications (like virtual private network [VPN] services) in
an “as‐a‐Service” model.
In a SaaS model, the customer typically has little to no control

of the underlying infrastructure, operating system, databases,
or middleware. SaaS providers typically offer their customers a
specialized cloud‐based application, such as ADP or Salesforce.
VNFaaS extends the SaaS model to virtualized network func-
tions, but unlike physical CPE and PE routers, customers will
typically not have full control or visibility of CPE or PE routers
in a VNFaaS.
VNPaaS
NFV enables opportunities like Virtual Network Platform as a
Service (VNPaaS) for the CSP to make available to its enter-
prise customers a suite of infrastructure and applications as
a platform on which they can deploy their own workloads or

network applications. This is a very helpful use case that can
enable enterprise customers to develop their own network
services, suited to their business needs, while providing a
new business opportunity for CSPs.
As an example, enterprises are increasingly using dedicated

Access Point Names (APNs) to enable mobile access to the
corporate network for their employees. Typical services
might include caching, communications, IP address assign-
ment (DHCP), name resolution (DNS), email, and firewall
and/or proxy services. By deploying these services onto a
virtual platform close to the APN, enterprises can reduce the
backhaul of data to the corporate network and significantly
improve the performance of these services over the network.
VNF Forwarding Graphs

A network function (NF) forwarding graph defines the
sequence of NFs that network packets traverse. Similar to
connecting physical network appliances together with cables,
VNF forwarding graphs (VNF‐FG) provide logical connectivity
between virtual appliances. VNF forwarding graphs provide
greater agility in deployment and upgrades compared to
physical forwarding configurations. In addition, VNF forward-
ing graphs augment the flexibility that VNFs have in terms of
scaling to meet changing capacity requirements.
Virtualization of Mobile
Base Station
Large numbers of radio access network (RAN) nodes in
mobile networks account for a significant portion of a mobile
operator’s capital and operating expenses. RAN nodes, includ-
ing the base stations that connect directly to subscribers’
mobile devices, are typically built on proprietary hardware
and have long development, deployment, and operational
lifecycles. By virtualizing at least some part of the RAN nodes
onto industry standard IT servers, storage, and switches,
mobile operators can achieve a lower footprint and lower
energy costs. In addition, software‐based implementation can
enable dynamic resource allocation, better load balancing,
and easier configuration and management. Another advan-
tage is the ability to foster a competitive environment where
smaller, innovative application providers can be onboarded
onto an open platform provided by the NFV architecture.
Virtualization of the Home

Environment
CSPs typically provide dedicated customer‐premise equip-
ment (CPE) devices for their residential customers. A CPE
is a telecommunications equipment located at the home or
business of a customer. These devices may include a residen-
tial gateway (RGW) or router for Internet and Voiceover‐IP
(VoIP) services, and a set‐top box (STB) and/or digital video
recorder (DVR) for media services. Although these devices
are relatively inexpensive compared to enterprise CPE, the
volume of residential customers requires a significant CAPEX
and OPEX investment by service providers.
Virtualization of the home environment provides for lower

capital expenditures (CAPEX) by replacing dedicated CPEs
at residential premises with low‐functionality access devices.
These devices can have longer lifecycles, so they require less
maintenance and fewer upgrades. All the value‐added func-
tionality is implemented in software and offered in the VNFaaS
mode. Additionally, CSPs can also introduce new services
without reliance on rolling out new CPE hardware to support
the service, enabling customers to benefit from always having
access to the latest functionality offered by the CSP, without
bothering to upgrade their devices at home.
Virtualization of Content
Delivery Networks
The ever‐increasing demand for rich multimedia content,
such as on‐demand video, streaming (high‐definition) audio
and video, and Internet Protocol television (IPTV), creates
major bandwidth and storage challenges for communica-
tions service providers. Integrating content delivery network
(CDN) nodes into operator networks can be an effective and

cost‐efficient solution to these challenges. Delivering content
from compute and storage nodes that are closer to the end
customer reduces network backhaul and enables higher‐
bandwidth, better‐quality content streams.
Currently, many CDN cache nodes are built on dedicated,

purpose‐built physical appliances and software. Virtualization
of CDN nodes offers service providers the flexibility to adapt
to new market conditions and opportunities. The field of
content delivery is characterized by rapid innovation in for-
mats, protocols, and compression techniques. Implementing
software‐based functions allows easy migration and upgrades
of functionality. Additionally, it’s much simpler to maintain by
virtue of the use of industry‐standard hardware. Virtualization
also enables dynamic resource allocation and the ability to
avoid over‐engineering.
Fixed‐Access NFV
Broadband digital subscriber line (DSL) access is widely
deployed today for residential and small‐to‐medium business
(SMB) Internet service. However, hybrid fiber‐DSL and very‐
high‐bit‐rate DSL 2 (VDSL2) access technologies are quickly
replacing these deployments. Fixed access NFV addresses the
high costs and bottlenecks often associated with broadband
network access.
Newer access technologies require equipment to be placed in

remote street cabinets or in multi‐occupancy buildings. These
systems need to be highly energy efficient and need to be as
simple as possible to have a long service life. Virtualization
addresses these issues by moving complex processing to
the head end instead of the remote nodes. Current access
network equipment is usually owned and operated by a
single entity. Virtualization allows multi‐tenant operation
of this infrastructure and enables new business models.
Virtualization of fixed access network elements also enables
synergies from co‐location of wireless access assets on a
common NFVI point‐of‐presence (PoP) or platform.
NFV and Software‐Defined

Networking
Software‐defined networking (SDN) and NFV are highly
complementary technologies and mutually benefit each other.
While I won’t go into details of SDN in this book, the following
section highlights the close relationship between these tech-
nologies. SDN virtualizes network resources for consumption,
similar to the way storage and compute resources are virtual-
ized for consumption in an NFV implementation. Through the
use of a common, centralized control plane, SDN can abstract
complex topologies of the underlying network infrastructure
and enable a high level of automation and programmability.
Decoupling the way services are created and consumed from
the implementation and topologies of the physical infrastruc-
ture is key to driving agility in service creation and efficiency
in utilization of network resources and operational processes.
There is a lot of ongoing work within many forums to

identify how SDN resources (SDN‐enabled hardware, SDN
controllers, and SDN applications) fit into the European
Telecommunications Standards Institute (ETSI) architecture.
Many ETSI proofs‐of‐concept (PoCs) have used SDN resources.
In a CSP network, SDN is key to operationalizing NFV deploy-

ments. Here are a few examples of the complementary role of
SDN and NFV:
✓✓In order to ensure that VNF capacity is optimized, it’s

essential that only the right traffic flows are directed
to the appropriate VNFs. SDN techniques like Service
Function Chaining (the ability to define an ordered list
of network services for a set of packets) are essential
for dynamically steering traffic flows to the right VNFs.
SDN‐enabled VNF Graphs are perhaps one of the most
common use cases that combine SDN and NFV.
✓✓One of the key benefits of NFV is the ability to VNFs
instantiate in datacenters closest to where they would be
consumed. SDN is essential to ensure that when VNFs are
migrated across datacenters, the network connectivity
parameters and service‐level agreements (SLAs) are
enforced and secured.
✓✓SDN controllers also play a major role in service orches-

tration across a hybrid (virtualized and nonvirtualized
infrastructure). Service orchestration is the aspect of
the network that manages the creation and delivery of
services. SDN provides a single point of configuration
and management for the underlying heterogeneous
network elements.
Chapter 8
HPE’s Approach to NFV
In This Chapter
▶▶Exploring the HPE OpenNFV reference architecture
▶▶Looking at HPE’s new vision for OSS
▶▶Working with HPE OpenNFV partners
▶▶Testing solutions in the HPE OpenNFV labs
H ewlett Packard Enterprise believes that CSPs that are on

the quest for higher agility, innovation, and efficiency
should embrace the notion of the Telco Cloud. Telco Cloud is
the idea of transforming infrastructure to be programmable
and operations to be automated so that CSPs can deliver per-
sonalized and on-demand services to their customers.
The adoption of NFV and SDN technologies and related evolu-

tion of the OSS/BSS are a critical part of the transformation to
a programmable infrastructure and automated operations.
NFV is about enabling communications service providers to

be agile while reducing OpEx and CapEx. NFV makes it pos-
sible for CSPs to move network functions from traditional and
proprietary, monolithic, hardware‐centric architectures to
open and agile architectures based on cloud technologies.
At HPE, the strategy is to provide a reference architecture,

the NFVI and MANO platforms, a rich partner ecosystem, test
facilities to validate solutions, and world-class transformation
support services to enable CSPs to make the transition to NFV.
The four phases of NFV evolution

Hewlett Packard Enterprise (HPE) sees NFV technology evolving in four
stages (see the figure):
✓✓ Decouple: This is where the ✓✓ Decompose: In this final stage,

software is separated from the monolithic network functions
underlying hardware. The goal are decomposed into elemental
is to enable virtualized network building blocks. Services are
functions (VNFs) to run on stan- recomposed as microservices.
dardized, open platforms. Network, compute, and storage
resources are geographically
✓✓ Virtualize: In this stage, network
distributed. CSPs can compose
functions are deployed on hyper-
new and improved services from
visordriven, virtualized infra-
the building blocks, through use
structure resources. This lets
of serviceaware interfaces that
you achieve higher utilization,
provide seamless integration of
better cost efficiencies, and the
network, compute and storage
ability to scale up/down rapidly.
resources.
✓✓ Cloudify: In this stage, widearea
Each phase in this evolution delivers
network is operated as part of
incremental benefits, from reduced
the cloud, holistically aligned
OPEX to facilitating an agile ser-
and consumed with compute
vices environment that encour-
and storage pools. Enables
ages speedy development of new
CSPs to achieve consistently
and innovative applications and
efficient networkwide resource
services.
utilization, respond dynamically
to shifting traffic patterns and There may not be a need to complete
customer demand, and instanti- each phase of this evolution. Individual
ate services dynamically through deployments can start/jump ahead
the use of automation. to any phase as appropriate.
Chapter 8: HPE’s Approach to NFV 45
HPE’s initiative to create an open platform and open ecosystem
around NFV is called OpenNFV. The OpenNFV program pro-
vides CSPs the foundation to build a programmable infrastruc-
ture and run automated operations. It also provides an easy
way for the CSPs’ suppliers — network equipment providers
(NEPs), independent software vendors (ISVs), and system
integrators — to pre‐test and integrate multi‐vendor solutions.
The primary goal of the OpenNFV program is to accelerate the
design, proof‐of‐concept, trial, and deployment of new cloud‐
enabled network services and innovations built on carrier‐
grade systems, while lowering capital expenditures, operating
expenditures, and risk.
In this chapter, you learn about the four essential elements of

HP’s OpenNFV Program: an open standards‐based Reference
Architecture, the HPE OpenNFV Partner Program, HPE
OpenNFV Labs, and Proof‐of‐Concept (POC) Projects. HPE
also provides a comprehensive transformation service offer-
ing to help CSPs on their journey to the Telco Cloud.
HPE OpenNFV Reference

Architecture
The move to NFV enables the disaggregation of the network
and allows CSPs to choose different parts of the system from
different vendors to best meet their needs. This enables CSPs
to optimize the system — for flexibility, time‐to‐market, and
cost — and they can innovate and scale each component
independently with separate development timelines for each
piece. However, the reality is that once the system is disaggre-
gated into separate pieces, the multitudes of interdependen-
cies make changes and reconfiguration challenging — both
time‐consuming and expensive.
The only way to make such a system work is with an open,

standards‐based architecture. Components must have open
interfaces with a well‐understood architecture and clear
boundaries. Everyone across the ecosystem has to agree
on how the components will talk to each other and work
together.
But this is not about standards. The telecommunications

industry has historically been very standards driven. Many
standards take a long time before all the details are worked
out and the final version is published. This safe, but long
process of implementation to final standards is perhaps not
the most conducive for the current competitive environment
that CSPs find themselves in. Open source is becoming a new
approach to standards. With open source, a framework is
established for the standard without defining all the detailed
specifications. Then, as development progresses, a de‐facto
standard emerges. With open‐source development around the
defined interfaces, there’s an agreed‐upon implementation
standard. OpenStack and other such open‐source technolo-
gies have evolved in the data center, and a large portion of the
cloud deployments today are based on open‐source projects.
The same approach is under way for CSPs in NFV.
HPE is actively involved and has leadership roles in many

standards organizations, making significant contributions to
European Telecommunications Standards Institute (ETSI),
Open Networking Foundation (ONF), Open Network Function
Virtualization (OPNFV), TM Forum, and open‐source initia-
tives like OpenStack and OpenDaylight.
The HPE OpenNFV reference architecture (see Figure 8‐1)

is a blueprint for how NFV components can be combined to
create robust NFV solution suites. Using the ETSI Reference
Architecture (see Chapter 2) as a starting point, it includes
processors, cache, operating systems, storage, networking,
switching, hypervisors, middleware, management systems,
orchestration, applications, and other components optimized
for NFV processing.
Figure 8-1: The HPE OpenNFV reference architecture.
The reference architecture is scalable, ranging from a base
design to extreme performance configurations that can
accommodate even the largest CSP network traffic volumes.
HPE provides the building blocks or selected subsystems and
components according to CSP requirements. And because the
reference architecture is open, there is always a choice to use
HPE‐provided components or the ones that are preselected
by the CSP. HPE’s MANO framework, which includes the NFV
Director and E2E Service management capability provided by
the HPE Service Director, is designed to integrate operations
of NFV‐enabled and legacy telecom infrastructure, and can
integrate “old” with “new”, and HPE subsystems and compo-
nents with others. This gives CSPs the freedom to build an
NFV solution to meet their needs — without vendor lock‐in.
HPE provides CSPs the industry’s most reliable, fully inte-

grated and tested carrier‐grade NFV solution. These c arrier‐
grade capabilities are packaged as HPE Helion OpenStack
Carrier Grade releases.
A New Vision for OSS

Hewlett Packard Enterprise (HPE) offers a new approach
to architecting the OSS layer to take advantage of the prin-
ciples that NFV MANO solutions bring to the table. HPE’s
vision for the new OSS centers around an end‐to‐end Service
Management layer that can create services across the NFV‐
enabled infrastructure, as well as traditional telecommunica-
tions infrastructure (see Figure 8‐2).
Figure 8-2: HPE’s vision for OSS transformation.
This approach uses a new way of modeling and designing

services. At the core of this approach are two key ideas:
✓✓Using a common information and data model for describ-

ing the behavior and requirements of the traditional and
virtualized operations
✓✓The concept of dynamically declaring a service, its rela-
tionships and behavior (policies)
This approach replaces the current workflow‐based approach

to orchestration, in which a lot of the behavior and steps
are hard coded. In this new approach, the OSS can use these
dynamic declarations of state to create a run‐time list of
actions as opposed to sequential workflows. The service
descriptors are able to describe how the service should
behave in an exceptional scenario, such as the failure of a
component. This opens the door to self‐healing — the OSS
listens to the network health and reconfigures it to circum-
vent the problem.
The key capabilities that HPE provides in this end‐to‐end

Service Management layer are
✓✓Agile service building: A model‐based design approach

that can create dynamic service models and update
relationships in real‐time. This provides the ability to
implement an industrialized system for creating dynamic
services across Physical Network Functions (PNFs) and
Virtual Network Functions (VNFs).
✓✓End‐to‐end service analytics: Provides real‐time and
long‐term analytics to be used for determining changes
that need to be made to service offers in real‐time. This
also helps to unify operations across service assurance
and service fulfillment.
✓✓Automated self‐healing: Uses analytics to provide real‐
time detection and correction for errors during opera-
tions across hybrid infrastructure.
✓✓Flexible integration: Real‐time application programming
interfaces (APIs) provide integration with the broader
OSS ecosystem.
With the new OSS architecture, CSPs have a single‐pane‐of‐
glass view of operations across their entire infrastructure —
traditional or NFV‐enabled. The resulting visibility will enable
Operations teams to proactively detect customer‐affecting
problems and speed up the investigation and resolution
of complex issues. HPE’s approach to OSS tranformation
enables CSPs to embark on this transformation at a pace of
their choosing. The HPE Service Director, with its capabil-
ity to bridge current and new operations, enables a smooth
transition.
The HPE OpenNFV Partner

Program
The OpenNFV Partner program is a very important part of
the move to create a rich, vibrant, and open ecosystem of
partners. The goal for HPE’s OpenNFV program is to create
a platform on which CSPs have the freedom to choose
applications from their vendor of choice.
To support this degree of flexibility and openness, the HPE

OpenNFV Partner Program includes younger, more agile,
smaller ISVs along with the leading NEPs, technology vendors,
and service providers.
The HPE OpenNFV Partner Program consists of three partner

categories:
✓✓Technology partners: Select technology companies and

vendors, including network equipment providers (NEPs),
original equipment manufacturers (OEMs), and CSPs that
collaborate on technology innovation, integration and
support for the HPE OpenNFV infrastructure stack.
✓✓Application partners and network equipment providers
(NEPs): These are ISVs that conduct testing, character-
ization, and validation of their applications and telecom
functions on the HPE OpenNFV infrastructure stack.
✓✓Service partners: Systems integrators using the HPE
OpenNFV infrastructure stack as a platform for their
offerings.
HPE OpenNFV Labs

With the approach of encouraging open‐source development,
it’s critical to test and share information about different
vendor implementations. Proof‐of‐concept (PoC) projects can
demonstrate key capabilities that can be implemented, but
are often customer‐specific and built in whatever facilities are
available for testing.
To truly enable a robust NFV ecosystem, dedicated labs

are needed, where multiple vendors can come together to
test end‐to‐end solutions. These labs are meant to provide
an accurate representation of a slice of the network, which
allows carriers to try things out before implementing them in
production. The labs are also a service development environ-
ment where carriers can test the integration between ven-
dors’ products. CSPs can see what is being developed and can
get involved to set direction — without investing as much of
their own resources. The primary goal of HPE NFV Labs is to
assure CSPs that solutions being proposed to them from mul-
tiple vendors are pretested and integrated — thereby saving
them valuable time and effort in network validation during
deployment.
HPE OpenNFV partners test applications in the HPE OpenNFV

Labs to make sure they run as expected on HPE’s reference
architecture.
NFV Proof‐of‐Concept Projects

HPE has been involved in developing a number of active NFV
use cases together with partners and international standards
organizations in Europe, the Americas, and Asia. These PoC
projects include the following use cases:
✓✓Voice/video
✓✓Mobile private networks
✓✓IP routing and transport
✓✓Telco cloud
✓✓NFV orchestration
✓✓Virtual evolved packet core (vEPC)
✓✓Multi‐service proxy (MSP)
✓✓Virtualized customer premise equipment (vCPE)
✓✓Virtualized IP Multimedia Subsystem (IMS)
Transformation Services
NFV deployments are a step in the CSP journey to a cloud‐
based infrastructure (Telco Cloud). As with any transforma-
tion, there are multiple paths to reach the final desired state
and there are multiple aspects to be evaluated.
1. Evaluate your business priorities.

2. Decide on an approach that aligns with the organiza-
tion’s goals.
3. Evaluate all aspects (if possible).
These include
•• Technology
•• Application
•• Organization and processes
4. Adapt, execute, and govern.
HPE offers a comprehensive transformation offering that

covers evaluation of strategic choices and planning, executing,
and lifecycle management of the entire process.
The HPE perspective:

NFV and the Telco Cloud
It’s rare to identify a sea change are talking about the how. So I think
while the sea change is under there’s an embrace of this need to
way. But with a development like move to the cloudification and soft-
NFV, the transformation is so ware model, and that, over the last
profound — and holds so much year, has really taken off. People
promise — that it’s impossible to now are talking about, “How do I do
ignore the ramifications. it?” and “How do I move forward?”,
where as last year was more about
“NFV is the biggest change for com-
the, “Why should we do this?”
munications service providers since
IP showed up,” says Saar Gillai, Q. What is HPE’s point of view on the
HPE’s senior vice president and evolution?
general manager of Communications
A. A few years back, we saw this
Solutions Business, and the per-
coming along, and realized that for
son responsible for the company’s
the communications service pro-
overall telecommunications strat-
viders (CSPs) to move from this
egy. “Remember when we moved
connectivity business to become a
from dedicated lines and circuit
digital service provider, they need
switching to IP? That’s the level of
to embrace this change. One of the
change we’re seeing here.”
things that we looked at is that the
Gillai recently talked about how NFV world is moving from where every-
is moving entire networks from pro- thing is based on specs to more eco-
prietary, dedicated metal boxes to system plays, because that’s how
open, flexible services optimized this world works. So we launched
for the cloud, and why in the new our OpenNFV program to start build-
telecom paradigm, agility and nim- ing out the ecosystem for that.
bleness trump the old standards of
More generally, our view is that the
stability and capacity.
CSPs need to embrace what we call
Q. How has the communications “the Telco Cloud,” to become full
landscape evolved over the past 12 digital service providers, and we can
months? help them drive that manner by going
through an organized process of get-
A. There have been a lot of changes
ting there. So we think that they need
in terms of software‐ization and net-
to embrace that, and there are many
work virtualization, but to summarize
facets of doing it.
it, 2014 was about the what. What is
it? 2015 was about the why. Why are They need to focus on implement-
we doing this? And now in 2016, we ing and cloudifying programmable
infrastructure. They need to address A. So we saw this a few years ago,

the orchestration piece because and we’ve been pushing that direc-
they need to move from the very tion. As the only vendor who is a
manual‐based operation to full auto- leader in IT and cloud, and also
mation. Lastly, they have to have a has a lot of telco history, with our
better way of managing their data. CMS portfolio, and our HSS, and
our orchestration, we’re in a unique
In the bigger picture, it is essential
position to help them on this journey,
to understand the importance of
because you need a combination
culture, business case, and getting
of both in this hybrid environment.
early successes. If you are going to
HPE has solutions across all the dif-
do some virtualization or NFV, you
ferent levels here. We’ve launched
need to figure out “What can you
solutions, enabled network virtual-
do that’s going to give you a quick
ization based on open source, with
return?”
our leadership in OpenStack. NFV
For example, what we did with System, as an integrated system,
Swisscom was to develop their vir- allows you to deploy NFV quickly.
tual Customer Premise Equipment We launched NFV Director, which
(vCPE) solution. So you figure out really enables you to manage this
a way to do agile services, and go new virtual environment by leverag-
from months to configure a service, ing the capabilities that are impor-
to minutes. Because the initia- tant in the OSS. We’ve recently
tive was well defined in scope and launched, the Service Director. This
limited in complexity, Swisscom allows you to tie the current system,
expects to see the immediate return. all the way from the service, down
to the infrastructure. Because if you
And while you see that, also, you
make your infrastructure run really
can drive the culture of adopting
fast, but the service is still very slow,
some agility, and getting the orga-
it’s not going to help you.
nization comfortable with this model
before you take on very large things. And we’re obviously driving this
So, that’s really an important piece big OpenNFV ecosystem, which we
of the “how,” while always focus- believe is really the way forward.
ing on what the value proposition is It’s not going to be a one‐vendor silo
going to be at the top line, not just, environment, it’s going to be an eco-
“Okay, this is going to save me a lot system play. Also, in order to move
of money,” but “How do I increase this forward, it’s a lot about doing
agility by d riving some of these PoCs (proofs of concepts), getting
services? the CSPs comfortable that this really
is something that’s important.
Q. How and where has Hewlett
Packard Enterprise played a role in We’re also working very heavily
this evolution? on driving the business aspects of
(continued)
(continued)
this evolution. One of the key things to move. It’s interesting to talk about
that’s important here is the focus all these new technologies, but
on the business. The technology really, the most important thing is to
is an enabler, but you have to say, understand is that moving to these
“Okay, what do I need to do?” And technologies means to move to a
now, moving forward, speed is the different culture, a more devops ori-
most important thing. And to under- ented, horizontal culture, and that’s
stand, “How do I move faster?”, not easy because the CSPs have
maybe I need to virtualize, maybe spent the past 20 years being very
I could do something else. “How do successful in very organized, struc-
I move faster from service require- tured environments, and they’re good
ment, to service creation, to service for what they were doing, but they’re
monetization?” not good for speed. And today the
winning plan for everything is speed.
And finally, a key element that’s
really important is culture. We have
Chapter 9
Things to Consider
When Transforming to
an NFV‐Enabled CSP
Infrastructure
In This Chapter
▶▶Looking at financial and business considerations
▶▶Identifying technology and architecture considerations
▶▶Considering operations and processes
▶▶Weighing organizational considerations
M ost CSPs are aware of the benefits of moving to a new

type of infrastructure where they can run applications
in a virtualized environment and create services in an agile
manner. However, many aren’t sure how to go about the jour-
ney to NFV. In this chapter, you get a brief overview of some
important considerations for planning your NFV deployment!
Financial and Business

Although CSPs are convinced of the need to migrate to NFV,
many questions remain about which applications to move and
how the expected operational expenditures (OPEX), capital
expenditures (CAPEX), and agility benefits will be achieved
over the short and longer terms.
One of the key considerations when embarking on an NFV

transformation journey is to evaluate the business cases
for the different use cases. Consider not only the OPEX and
CAPEX aspects, but also the value of faster time-to-market and
new services that are made possible through an NFV infra-
structure. In many cases, multiple use cases may make sense
when they’re evaluated and implemented together.
An HPE NFV Transformation Workshop is a simple way to

start your NFV journey!
Technology and Architecture

Having an architecture blueprint of what the network would
look like after the transformation is critical to the NFV trans-
formation journey. This process of coming to an agreement on
the strategic vision of how the network will look and be oper-
ated is key to defining the steps in the journey. Of the many
considerations are the evaluation of the maturity of applica-
tions that are planned for virtualization and agreement on
how these functions will be deployed.
Where you deploy your NFV architecture (for example, point

of purchase, switching center, datacenter) is an important
consideration. Benefits can be gained by consolidating appli-
cations into specific locations, but careful consideration
needs to be given to traffic patterns and interaction between
applications. It’s also important to nail down the scale‐out and
performance requirements for different applications. This will
help in planning and sizing the NFVI design.
Other aspects of architecture include transforming the OSS to

support the new breed of infrastructure while continuing to
operate traditional infrastructure. To fully realize the benefits
of NFV, a common orchestrator that understands resource
needs for services across a hybrid infrastructure and can trig-
ger changes based on predefined policies is required. With
the right orchestration engine, zero‐touch or near‐zero‐touch
activation can be supported. These features ensure that the
agility, OPEX, and even CAPEX benefits of NFV can be realized.
The choice of integrating best‐in‐breed applications on an

open platform will also bring forth decisions to be made on
system integration and validation.
Chapter 9: Things to Consider When Transforming to an NFV 57
Operations and Processes

The decision to deploy NFV and embark on a transformation
will have major impact on the current operational processes
that are in place and perfected at most CSPs. Some examples
of this are the process of procurement, validation, system
acceptance, and troubleshooting.
Procurement organizations have historically relied on a single

vendor to provide the hardware, software, and management
functionality associated with a particular product or solution.
In the new world of NFV, these components are decoupled
from each other and may have different vendors providing
different parts. In such a scenario, the procurement process,
the process of validating, and the process of acceptance
testing for a product/solution also need to be revisited.
Troubleshooting and responsibility of service assurance
within the CSP will also need to be revamped to meet the real-
ity of the way the new infrastructure operates.
Organization
Last but not the least is the organizational consideration
when moving to an NFV‐based architecture. NFV drives the
CSP infrastructure to be more open, more virtualized, and
more IT‐centric. This has profound impact on the competence
required for the personnel who operate and manage this
infrastructure.
The expertise for managing the different parts of the network

in this new architecture may reside in different organizations.
For example, the NFVI layer in the new network architecture
will be highly influenced by the CSP’s cloud and datacenter
strategies and the organizations within the CSPs that manage
it, while the competence and expertise for most of the VNF
layers may reside in the network operations team.
One of the key considerations in NFV deployment is to rethink

the best way to design organizations so that the processes
associated with running the new infrastructure are optimized.
Glossary
3GPP: See 3rd Generation Partnership Project (3GPP).
3rd Generation Partnership Project (3GPP): The standards

organization for defining the network architecture and network
function specifications for mobile and converged networks.
ABE: See Aggregate Business Entity (ABE).
Access Point Name (APN): The name of a gateway between

a carrier’s GPRS, 3G, or 4G mobile network and another net-
work, such as the Internet.
Aggregate Business Entity (ABE): A well‐defined set of infor-

mation that characterizes a highly cohesive set of business
entities that are loosely coupled with entities in other ABEs.
Alliance for Telecommunications Industry Solutions (ATIS):

A standards organization that develops technical and opera-
tional standards and solutions for the information and com-
munications technology industry.
APN: See Access Point Name (APN).
ATIS: See Alliance for Telecommunications Indusry

Solutions (ATIS).
BRAS: See broadband remote access server (BRAS).
broadband remote access server (BRAS): A device that

routes traffic to and from broadband remote access devices
such as digital subscriber line access multiplexers (DSLAMs)
on an Internet service provider’s network.
bring your own device (BYOD): A policy in which employees

are permitted to use their personal mobile devices, such as
smartphones and tablets, in the workplace for both work‐
related and personal business.
BSS: See business support system (BSS).
business support system (BSS): A computer system used by a

telco to run its customer‐facing business operations.
BYOD: See bring your own device (BYOD).
CDN: See content delivery network (CDN).
CFS: See customer‐facing service (CFS).
cloud service provider: A company that provides cloud services,

such as IaaS, PaaS, or SaaS to subscribers.
CloudEthernet Forum: An industry organization of market‐

leading cloud service providers, network service providers,
equipment manufacturers, system integrators, and soft-
ware developers that are focused on development of cloud
Ethernet technologies through open standards development.
communications service provider (CSP): A service provider

that transports information electronically — for example, a
telecommunications service provider.
content delivery network (CDN): A network of servers that

cache and distribute static web pages in order to optimize
delivery of content to web browsers around the world.
CPE: See customer premises equipment (CPE).
CSP: See communications service provider (CSP).
customer‐facing service (CFS): An abstraction that defines the

characteristics and behavior of a particular service, as seen
by the customer.
customer premises equipment (CPE): Telecommunications

equipment — such as telephones, routers, switches, and
gateways — that is physically located at a customer site and
connected to a carrier’s telecommunications equipment at the
demarcation point.
DHCP: See Dynamic Host Configuration Protocol (DHCP).
digital video recorder (DVR): Hardware or software that

records video in a digital format to a storage device. Also
known as a personal video recorder (PVR).
Glossary 61
DNS: See Domain Name System (DNS).
Domain Name System (DNS): A hierarchical naming system

for computers, services, or any resource connected to
the Internet or a private network that provides a mapping
between IP addresses and domain names.
DVR: See digital video recorder (DVR).
Dynamic Host Configuration Protocol (DHCP): A network

protocol that dynamically assigns IP addresses and other
network parameters to devices connected to a network.
eNodeB: See Evolved Node B (eNodeB).
EPC: See Evolved Packet Core (EPC).
ETSI: See European Telecommunciations Standards

Institute (ETSI).
European Telecommunications Standards Institute (ETSI):

An independent, European organization for standardization in
the telecommunications industry.
Evolved Node B (eNodeB): Hardware that is connected to

the mobile phone network that communicates directly with
mobile handsets, such as a base transceiver station (BTS) in
GSM networks.
Evolved Packet Core (EPC): The latest core network architec-

ture for a cellular system.
general packet radio service (GPRS): A packet‐oriented

mobile data service on 2G and 3G cellular communication
systems.
GPRS: See general packet radio service (GPRS).
home subscriber server (HSS): Functions as a location server

and authentication, authorization, and accounting (AAA)
server in the IMS, and serves as a single provisioning point for
IMS subscribers and their services.
HSS: See home subscriber server (HSS).
hypervisor: Software or firmware that runs between the com-

puter operating system and the hardware kernel, and allows
multiple “guest” operating systems (or virtual machines
[VMs]) to run concurrently on a single physical “host” com-
puter. Also known as a virtual machine monitor (VMM).
IaaS: See Infrastructure as a Service (IaaS).
IMS: See IP Multimedia Subsystem (IMS).
independent software vendor (ISV): An organization special-

izing in making or selling software.
Infrastructure as a Service (IaaS): A cloud computing model

in which the service provider hosts hardware, software, stor-
age, and other infrastructure components for its subscribers.
IP Multimedia Subsystem (IMS): A session control architec-

ture to support the provisioning of multimedia services over
EPC and other IP‐based networks.
ISV: See independent software vendor (ISV).
Long‐Term Evolution (LTE): A standard for high‐speed wire-

less communication for mobile phones and data terminals.
LTE: See Long‐Term Evolution (LTE).
Management and Orchestration (MANO): A framework

for automating the management and provisioning of NFV
resources. MANO functional blocks in NFV include the NFVO,
VNFM, and VIM.
MANO: See Management and Orchestration (MANO).
MME: See Mobility Management Entity (MME).
Mobility Management Entity (MME): The key control node for

the LTE access network.
MSP: See multiservice proxy (MSP).
multiservice proxy (MSP): A multipurpose, multi‐technology

network node that enables differentiation, control, and mon-
etization in relation to data traffic.
Glossary 63
NAT: See network address translation (NAT).
NEP: See network equipment provider (NEP).
network address translation (NAT): A method for mapping

one IP address to another — for example, mapping a public IP
address to a private IP address.
network equipment provider (NEP): A company that sells

products and services to communications service providers,
such as fixed or mobile operators, as well as to enterprise
customers.
network functions virtualization (NFV): A network architec-

ture concept that proposes using IT virtualization technolo-
gies to virtualize entire classes of network node functions into
building blocks that may be connected, or chained, to create
communication services.
network functions virtualization infrastructure (NFVI): The

totality of all hardware and software components that build
up the environment in which VNFs are deployed.
network service (NS): As defined by ETSI, a composition of

network functions defined by its functional and behavioral
specifications.
NFV: See network functions virtualization (NFV).
NFVI: See network functions virtualization infrastructure

(NFVI).
NFV Orchestrator (NFVO): One of the functional blocks in NFV

MANO.
NFVO: See NFV Orchestrator (NFVO).
NS: See network service (NS).
OCS: See online charging system (OCS).
OEM: See original equipment manufacturer (OEM).
OFCS: See offline charging system (OFCS).
offline charging system (OFCS): A system allowing a com-

munications service provider to charge its customers without
affecting real‐time services.
ONF: See Open Networking Foundation (ONF).
online charging system (OCS): A system allowing a communi-

cations service provider to charge its customers in real‐time,
based on service usage.
Open Networking Foundation (ONF): A nonprofit organization

focused on improving networking through SDN and standard-
izing the OpenFlow protocol and related technologies.
Open Platform for Network Functions Virtualization

(OPNFV): An open‐source project focused on accelerating
NFV’s evolution through an integrated, open platform.
OpenDaylight: A collaborative open‐source project hosted by

The Linux Foundation, with the goal of accelerating the adop-
tion of SDN and creating a solid foundation for NFV.
OpenStack: A free, open‐source cloud computing software

platform.
operations support system (OSS): A computer system used by

a telco to manage its networks.
OPNFV: See Open Platform for Network Functions

Virtualization (OPNFV).
original equipment manufacturer (OEM): A company that

makes a part or subsystem that is used in another company’s
end product.
OSS: See operations support system (OSS).
OTT: See over the top (OTT).
over the top (OTT): A third‐party service provider that deliv-

ers audio, video, and other media content over the Internet to
an end‐user device using the Internet service provider (ISP)
network for transport.
PaaS: See Platform as a Service (PaaS).
Glossary 65
Packet Data Network Gateway (PGW): The gateway that
terminates the SGi interface (the reference point between the
PGW and the packet data network) toward the packet data
network.
PCRF: See Policy and Charging Rules Function (PCRF).
P‐CSCF: See Proxy‐Call Session Control Function (P‐CSCF).
personal video recorder (PVR): See digital video recorder

(DVR).
PGW: See Packet Data Network Gateway (PGW).
physical network function (PNF): A physical network device,

such as a router or a switch.
Platform as a Service (PaaS): A cloud computing model in

which the service provider hosts and manages infrastructure
and software components for its subscribers, in order for its
subscribers to develop and deploy custom applications on a
standard computing platform.
PNF: See physical network function (PNF).
Policy and Charging Rules Function (PCRF): Responsible for

policy control in the IMS core network.
Proxy‐Call Session Control Function (P‐CSCF): An SIP proxy

that functions as an SBC and is the first point of contact for
the IMS terminal.
PVR: See personal video recorder (PVR).
QoE: See quality of experience (QoE).
quality of experience (QoE): A measure of a customer’s expe-

riences with a service.
radio access network (RAN): Equipment, such as base sta-

tions (Node Bs), which connects mobile devices to the public
telephone network or the Internet.
RAN: See radio access network (RAN).
resource‐facing service (RFS): An abstraction that defines the

characteristics and behavior of a service that supports a CFS
but is not seen or purchased directly by the customer.
RFS: See resource‐facing service (RFS).
SaaS: See Software as a Service (SaaS).
SBC: See session border controller (SBC).
S‐CSCF: See Serving‐Call Session Control Function (S‐CSCF).
SDN: See software‐defined networking (SDN).
service‐level agreement (SLA): Formal minimum performance

standards for systems, applications, networks, or services
established between a service provider and customer.
Serving‐Call Session Control Function (S‐CSCF): The registrar

server in an IMS core network.
Serving Gateway (SGW): The gateway that terminates the

interface toward evolved UMTS Terrestrial Radio Access
(E‐UTRA), the air interface of 3GPP’s LTE upgrade path for
mobile networks.
session border controller (SBC): A Voice over Internet

Protocol (VoIP) network device that controls signaling and
the media streams involved in setting up, conducting, and
tearing down telephone calls or other interactive media
communications.
Session Initiation Protocol (SIP): A communications proto-

col for signaling and controlling multimedia communication
sessions.
set‐top box (STB): A hardware device that contains a TV tuner

and connects to a TV and external signal source. Also known
as a set‐top unit (STU).
set‐top unit (STU): See set‐top box.
SGW: See Serving Gateway (SGW).
Glossary 67
Shared Information/Data (SID) Model: A unified reference
data model providing a single set of terms for business
objects in telecommunications.
SI: See systems integrator (SI).
SID Model: See Shared Information/Data (SID) Model.
SIP: See Session Initiation Protocol (SIP).
SLA: See service‐level agreement (SLA).
Software as a Service (SaaS): A cloud computing model in

which the service provider hosts and manages software for its
subscribers.
software‐defined networking (SDN): An approach to com-

puter networking that allows network administrators to
manage network services through abstraction of lower‐level
functionality.
STB: See set‐top box (STB).
STU: See set‐top unit (STU).
systems integrator (SI): A company that specializes in bring-

ing component subsystems together into a whole and ensur-
ing that those subsystems function together.
TM Forum: A nonprofit industry association for service pro-

viders and their suppliers in the telecommunications and
entertainment industries.
VIM: See Virtual Infrastructure Manager (VIM).
virtual network function (VNF): A software implementation of

a network function that can be deployed on NFVI.
Virtual Infrastructure Manager (VIM): Software that ensures

physical and virtual resources work together.
virtual machine monitor (VMM): See hypervisor.
VMM: See virtual machine monitor (VMM).
VNF: See virtual network function (VNF).
VNF Manager (VNFM): One of the functional blocks in NFV

MANO, VNFM provides lifecycle management of VNF instances.
VNFM: See VNF Manager (VNFM).
WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

NFV For Dummies PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NFV For Dummies PDF

Uploaded by

Copyright:

Available Formats

These materials are © 2016 John Wiley & Sons, Inc.

Any dissemination, distribution, or unauthorized use is strictly prohibited.

Hewlett Packard Enterprise

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE

ISBN 978‐1‐119‐14992‐7 (pbk); ISBN 978‐1‐119‐14993‐4 (ebk)

Development Editor: Elizabeth Kuball Production Editor: Siddique Shaik

Chapter 1: Telecommunications Industry

Chapter 2: What Is NFV?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 3: NFV Components: Network Functions

Chapter 4: NFV Components: VNF and EMS. . . . . . . . . . 21

Chapter 5: NFV Components: Management

Chapter 6: Complementing NFV with OSS

Chapter 7: NFV Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 8: HPE’s Approach to NFV. . . . . . . . . . . . . . . . . . 43

Chapter 9: Things to Consider When Transforming

This transformation is profound and holds a lot of promise —

To do so, CSPs must embrace “IT‐ification” — the application

Network functions virtualization (NFV) offers a new way for

About This Book

Throughout the book, you’ll find lots of acronyms. In the

I would like to acknowledge the use of ETSI NFV Working

✓✓You work in the telecommunications industry. Perhaps

Icons Used in This Book

Proceed at your own risk . . . well, okay — it’s actually nothing

Beyond the Book

Where to Go from Here

“Would you tell me, please, which way I ought to go from

“I don’t much care where . . . ,” said Alice.

“Then it doesn’t matter which way you go!”

That’s certainly true of Network Functions Virtualization For

However, if you see a particular topic that piques your ­interest,

written to stand on its own, so you can start reading anywhere

I n this chapter, you explore several telecommunications

✓✓Exploding demand: Analysis Mason forecasts that global

growth is set to continue through 2020, when mobile data

Traditionally, CSPs have not been able to optimize their

Network functions virtualization (NFV) applies virtualization

NFV is transforming the way that CSPs architect and design

NFV enables significant benefits through deployment of

✓✓Creating new revenue opportunities: New applications

The Origins of NFV

emerged as a call to action by a global group of t­ elecom

The NFV industry movement began with the goal of saving

I n this chapter, you learn about network functions virtual-

This type of architecture often leads to silos of operations,

NFV redefines the way typical network functions are delivered

This new architecture provides CSPs with an open platform

ETSI NFV Framework

The ETSI NFV Industry Specification Group (ISG) has defined

Figure 2-1: High‐level NFV architectural framework.

The ETSI NFV framework consists of three major components:

✓✓Network Functions Virtualization Infrastructure (NFVI):

✓✓Management and Orchestration (MANO): A ­subsystem

The NFV framework proposes virtualized, software‐only

NFV Management and Orchestration (MANO) provides

NFV Business Goals

Business goals enabled by NFV

✓✓Greater business agility: The ability to offer new serv­

These benefits will provide CSPs with a unique opportunity to

s­ uccessful transformation. They can be classified into three

Additionally, there is large installed base of legacy telco

NFV, by decoupling functions from the infrastructure, war-

Another important operational challenge is to manage opera-

However, if you see a particular topic that piques your interest,

emerged as a call to action by a global group of t elecom

Figure 2-1: High‐level NFV architectural framework.

✓✓Management and Orchestration (MANO): A subsystem

✓✓Greater business agility: The ability to offer new serv

s uccessful transformation. They can be classified into three

Figure 3-1: Hardware resources in NFVI include compute, storage, and

Figure 3-2: Virtual resources and the virtualization layer in NFVI.

Figure 4-1: VNF in an NFV reference architecture.

Figure 4-2: EMS in an NFV reference architecture.

Figure 5-1: VIM in NFV MANO.

Figure 5-2: VNFM in an NFV architecture.

Figure 5-3: NFVO in NFV MANO.

In order to fulfill its responsibilities, the NFVO consumes serv

Hybrid infrastructure in the context of this book means a com-