NFV4Dummies HP

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 070305774
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) 7486011, fax (201) 7486008, 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 9781119149927 (pbk); ISBN 9781119149934 (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 8774094177, 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.
Publishers Acknowledgments
Some of the people who helped bring this book to market include the following:
Development Editor: Elizabeth Kuball
Copy Editor: Elizabeth Kuball
Acquisitions Editor: Katie Mohr
Editorial Manager: Rev Mengle
Business Development Representative:
Karen Hattan
Production Editor: Siddique Shaik

Special Help: Elizabeth Palmer,
ScottLindsay, Daniel Montesanto,
Melody Howard Yuhn, CEH, CISSP;
Andreas Krichel
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
Chapter1: Telecommunications Industry

Challenges andOpportunities . . . . . . . . . . . . . . . . . . . . 5
Industry Challenges andOpportunities................................... 5
The Origins of NFV...................................................................... 7
Chapter2: 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
Chapter3: NFV Components: Network Functions

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

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

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

Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Driving OSS Transformation.................................................... 32
Getting Started with OSS Transformation............................. 33
Chapter7: 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
FixedAccess NFV...................................................................... 40
NFV and SoftwareDefined Networking.................................. 41
Chapter8: HPEs 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 ProofofConcept Projects............................................... 50
Transformation Services.......................................................... 51
Chapter9: Things to Consider WhenTransforming

to an NFVEnabled CSP Infrastructure . . . . . . . . . . . . 55
Financial and Business............................................................. 55
Technology and Architecture................................................. 56
Operations and Processes....................................................... 57
Organization.............................................................................. 57
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Introduction
ommunications service providers (CSPs) are evolving

their infrastructures at a rate rarely seen since the
industrys transformation from analog to digital and much
faster than the shift from timedivision multiplexing (TDM) to
Internet Protocol (IP).
This transformation is profound and holds a lot of promise
its impossible to ignore the implications. CSPs have an opportunity to move from disrupted to disruptor and return to
the epicenter of the telecommunications ecosystem.
To do so, CSPs must embrace ITification 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 technologies and techniques, CSPs can accelerate the introduction of
new, compelling services quickly and costeffectively. NFV
enables CSPs to reset the cost base of their network operations and create the flexible service delivery environments
they need to innovate more quickly and drive revenue.
About This Book

This book provides an indepth examination of NFV, including
the individual components of the NFV Reference Architecture
and Hewlett Packard Enterprises vision for the future of NFV.

Throughout the book, youll find lots of acronyms. In the
interest of readability, I dont spell out every acronym. These
terms are defined in the Glossary at the end of the book. So, if
you come across an acronym youre 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, youre broadly familiar
with telecommunications and networking concepts,
fundamentals, and terminology.
Youre somewhat familiar with virtualization technology. You dont experience anxiety attacks and hyperventilate when someone starts talking about hypervisors.
Youre a business or technical decision maker in your
organization and youre interested in learning about
NFV. If thats 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. Heres what you can expect:
This icon points out information that may well be worth committing to your nonvolatile memory, your gray matter, or your
noggin along with anniversaries and birthdays!
You wont find a map of the human genome in this book, but
if you seek to attain the seventh level of NERDvana, perk up!
This icon explains the jargon beneath the jargon!
Introduction
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 its 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 chockfull of information, theres 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 dont much care where..., said Alice.
Then it doesnt matter which way you go!
Thats certainly true of Network Functions Virtualization For
Dummies, which, like Alice in Wonderland, is also destined to
become a timeless classic!
If you dont know where youre going, any chapter will get you
there but Chapter1 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 individually 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 hearts content! Read this book in any
order that suits you (though I dont recommend upside down
or backward).
I promise you wont get lost falling down the rabbit hole!
Chapter1
Telecommunications
Industry Challenges
andOpportunities
In This Chapter
Recognizing current challenges and opportunities
Looking back at NFVs beginnings
n this chapter, you explore several telecommunications

industry trends that are driving NFV and how it evolved.
Industry Challenges
andOpportunities
We are living in an increasingly hyperconnected world
and its 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
anexponential rise in traffic and the number of subscribers
on their networks. Today, CSPs are facing challenges on multiple 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
thetop (OTT) players, such as Hulu and Netflix, who are
agile, flexible, and able to roll out revenuegenerating
services much faster. Changing and everincreasing consumer expectations for personalized services and experiences also up the ante for CSPs.
Inability to offer new services to users rapidly and
dynamically: Current CSP networks are built on monolithic, 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 valueadded applications or service functions that
CSPs use in their network infrastructure, enabling them to
reduce cost and improve timetomarket.
NFV is transforming the way that CSPs architect and design
parts of their networks. Using standard IT virtualization technologies, NFV allows a CSP to consolidate the plethora of
applications and specialized network equipment they use in
their network onto industrystandard highvolume servers,
Chapter1: Industry Challenges and Opportunities
switches, and storage. NFV ensures that CSPs will automatically benefit from any major advances and disruptive innovations 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 segments can be quickly tested and deployed at the scale
required. With NFV, the CSP network can become a platform on which an ecosystem of independent software
vendors can quickly bring new applications and innovations to market.
Increasing flexibility and agility with cloud-style fulfillment models: Applications and services can be readily
updated and deployed without unnecessary delays,
speeding timetomarket.
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 network 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 offerings for consumers and businesses.
The Origins of NFV

Capitalizing on the technology advances that emerged from the
softwaredefined 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.
Chapter2
What Is NFV?
In This Chapter
Understanding NFV
Building a framework for NFV
Recognizing NFV business goals and challenges
n this chapter, you learn about network functions virtualization (NFV) what it is, how the different architectural
components work together, how its used, and how organizations can benefit from NFV.
NFV Defined
Todays 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.
10

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
thenetwork 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 business 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 highlevel functional architectural framework for NFV
(seeFigure21). Note: The figure includes references for
interfaces between the different architectural components.
Explanation of these interfaces is beyond the scope of this
book.
Chapter2: What Is NFV?
11
Figure 2-1:Highlevel 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).
12

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, softwareonly
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 virtualizationspecific management tasks in the NFV
framework.
NFV Business Goals

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

NFV transformation promises to bring major business, technology, and operational benefits to increase carriers competitiveness. 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 customer, centralized, or distributed).
13
New opportunities and more innovation: Innovative

new business opportunities are possible with virtualization technologies and a platform that can host applications 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 considered too risky to try out can now be experimented with
in a controlled manner.
Faster timetomarket: 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 infrastructure. This creates opportunities for automation and
business process management (BPM) reengineering
initiatives.
Optimized OPEX: Dedicated telco hardware requires
specialized skills to support and maintain. Virtualization
on industrystandard 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 configuration 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 utilization and ondemand 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 endtoend.
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
14

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
telcograde 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 management, a hybrid environment will always exist. Virtualization
of certain telco equipment wont 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) environments and endtoend automation to enable agility and faster
service velocity.
NFV, by decoupling functions from the infrastructure, warrants new procedures for testing/validation/acceptance and
troubleshooting. Purchasing and planning processes and competencies also need to change to be more oriented to the way
the IT domain works.
Another important operational challenge is to manage operations costs while deploying NFV. Factors contributing to this
challenge include the following:
Complexity associated with managing a hybrid environment of virtualized and legacy equipment
Complexity of managing functions implemented by a
distributed set of software entities
15
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 competencies 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 realtime 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
selfcare portals from which they will be able to personalize
their service offers. This transformation to a personalized,
ondemand 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 realtime
analytics.
16
Chapter3
NFV Components: Network

Functions Virtualization
Infrastructure
In This Chapter
Recognizing the physical components of NFVI
Building a virtual infrastructure
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 Figure31). These are the shared
resources that a VNF uses (through a virtualization layer) for its
processing, storage, and connectivity needs. Commercially available servers form most of the computing hardware. Storage can
either be directattached 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-ofpresence (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.
18
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 Figure32).
These virtual resources are presented as an independent
entity for each VNF.
Chapter3: NFV Components: NFVI
19
Figure 3-2:Virtual resources and the virtualization layer in NFVI.
The virtualization layer (commonly referred to as a hypervisor) 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.
20

The NFV specifications do not specify a particular virtualization 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.
Chapter4
NFV Components:
VNF and EMS
In This Chapter
Virtualizing physical network devices and functions
Managing network elements
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 implemented as purposebuilt hardware appliances running proprietary 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 arouter 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
22

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)
doesnt 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 Figure41) can be implemented as a VM, multiple VMs, or a function implemented within a shared VM.
Figure 4-1:VNF in an NFV reference architecture.
Chapter4: 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 element. These functions are commonly referred to as fault, configuration, accounting, performance, and security (FCAPS). An
EMS performs management functions for one (onetoone) or
more (onetomany) VNFs (see Figure42). An EMS may itself
be a VNF in the NFV architecture.
The EMS has integration points with the following:
The VNF Manager (VNFM; see Chapter5), to support
theVNF lifecycle management (for example, to trigger
scaleout/in).
The Operations Support System (OSS, discussed in
Chapter6), 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
anEMS.
24
Figure 4-2:EMS in an NFV reference architecture.
Chapter5
NFV Components:
Management and
Orchestration (MANO)
In This Chapter
Managing resources and data with the Virtualized Infrastructure
Manager
Performing lifecycle management

Managing endtoend network services with the NFV Orchestrator
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
26

NFVI (see Figure51). 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.
Chapter5: NFV Components: Management and Orchestration
27
Resource management and allocation in a virtualized environment is a complex task. Given the nature of the architecture,
all resources are shared between multiple tenants or applications, and the VIM needs to take care of the competing
requests and constraints in realtime.
VNF Manager
The Virtual Network Function Manager (VNFM) is the
entity that manages the virtualized network functions (see
Figure52). 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.

28

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 VNFassociated 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 Figure53). The NFVO is responsible for creating
endtoend 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 interVNF connectivity or the VNF
instances that are part of the service.
Chapter5: 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 functions that are authenticated and properly authorized (such
as Operations Support System (OSS) and Business Support
System (BSS).
30
Chapter6
Complementing NFV with

OSS Transformation
In This Chapter
Increasing business agility with automation
Choosing an OSS transformation strategy
espite the expanding interest in deploying NFV

and softwaredefined 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 combination of virtual and physical network functions or a combination 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.
32
Driving OSS Transformation

Todays 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
ofan 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 assurance 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 todays 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 Chapter5) 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
(NFVbased) infrastructure which will be the nearterm
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
Chapter6: Complementing NFV with OSS Transformation
33
s upport both physical (traditional) and virtual (NFV enabled)

infrastructure with the agility characteristic of virtual and
cloudbased deployment models.
The NFV Framework not only provides a new set of management components, but also supports new business models.
Both of these use cases are described in Chapter7. 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,
itneeds to be
Automated: Manual processes should be automated
wherever possible to make operations more agile
Catalog driven: Modular and intuitive with selfcare
capabilities that empower consumers and enterprises
Intent based: Abstracting workflows to expose only the
final result
Data focused: Harnessing analytics to provide personalized 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 introduction 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 current OSS into a more efficient system.
34

Two key aspects of NFV MANO that can be leveraged to transform 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,
intentbased configuration, use of SDN controllers to be a
single point of configuration and management for certain
domains, among others. Cloudbased approaches can tie
the relevant systems together and provide capabilities
such as zerotouch commissioning, flowthrough provisioning, and network optimization for a more efficient
development environment.
Close relationship between assurance and fulfillment
processes: NFV architecture allows for realtime 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.
Chapter7
NFV Use Cases

In This Chapter
Looking at use cases proposed for NFV
Understanding the relationship between NFV and SDN
FV fundamentally changes the way that networks are

built, using standard IT virtualization technologies
to consolidate various types of network equipment onto
industrystandard 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 architecture 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 requirements. For example, there may be cases in which data plane
36

resources (data intensive) need to be increased, but not necessarily control plane resources (compute intensive), or vice
versa. There may also be cases where only some EPC functions 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 IPbased networks, both fixed
and mobile, and is also composed of several specialized components. Independent scaling of the various component functions 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 lowercost, 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 NFVIasaService (NFVIaaS)
use case is a scenario in which a service provider can offer
its NFVI resources (such as physical compute, network, and
storage) as a service on which other CSPs can run their VNFs.
In an NFVIaaS model, the tenant CSP is responsible for installing, configuring and maintaining its VNFs running on the service providers virtualized infrastructure.
Running VNF instances inside an NFVI operated by another
service provider is one way that service providers can meet
the servicelevel agreements (SLAs) and regulatory requirements of their global enterprise customers, without actually
maintaining a physical presence around the globe.
Chapter7: NFV Use Cases
37
VNFaaS
VNFasaService (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 virtualized 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 bringyourowndevice (BYOD) policies. Standalone purposebuilt appliances installed at branch
offices are cost prohibitive, slow to deploy, and difficult to
maintain. At the opposite end of the spectrum, allinone
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 valueadded 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 asaService 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 cloudbased application, such as ADP or Salesforce.
VNFaaS extends the SaaS model to virtualized network functions, 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 enterprise customers a suite of infrastructure and applications as
38

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 assignment (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 (VNFFG) provide logical connectivity
between virtual appliances. VNF forwarding graphs provide
greater agility in deployment and upgrades compared to
physical forwarding configurations. In addition, VNF forwarding 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
operators capital and operating expenses. RAN nodes, including 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, softwarebased implementation can
39
enable dynamic resource allocation, better load balancing,

and easier configuration and management. Another advantage 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 customerpremise equipment (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 residential gateway (RGW) or router for Internet and VoiceoverIP
(VoIP) services, and a settop 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 lowfunctionality access devices.
These devices can have longer lifecycles, so they require less
maintenance and fewer upgrades. All the valueadded functionality 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 everincreasing demand for rich multimedia content,
such as ondemand video, streaming (highdefinition) audio
and video, and Internet Protocol television (IPTV), creates
major bandwidth and storage challenges for communications service providers. Integrating content delivery network
40

(CDN) nodes into operator networks can be an effective and
costefficient 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, betterquality content streams.
Currently, many CDN cache nodes are built on dedicated,
purposebuilt 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 formats, protocols, and compression techniques. Implementing
softwarebased functions allows easy migration and upgrades
of functionality. Additionally, its much simpler to maintain by
virtue of the use of industrystandard hardware. Virtualization
also enables dynamic resource allocation and the ability to
avoid overengineering.
FixedAccess NFV
Broadband digital subscriber line (DSL) access is widely
deployed today for residential and smalltomedium business
(SMB) Internet service. However, hybrid fiberDSL and very
highbitrate 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 multioccupancy 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 multitenant operation
of this infrastructure and enables new business models.
Virtualization of fixed access network elements also enables
synergies from colocation of wireless access assets on a
common NFVI pointofpresence (PoP) or platform.
41
NFV and SoftwareDefined

Networking
Softwaredefined networking (SDN) and NFV are highly
complementary technologies and mutually benefit each other.
While I wont go into details of SDN in this book, the following
section highlights the close relationship between these technologies. SDN virtualizes network resources for consumption,
similar to the way storage and compute resources are virtualized 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 infrastructure 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 (SDNenabled hardware, SDN
controllers, and SDN applications) fit into the European
Telecommunications Standards Institute (ETSI) architecture.
Many ETSI proofsofconcept (PoCs) have used SDN resources.
In a CSP network, SDN is key to operationalizing NFV deployments. Here are a few examples of the complementary role of
SDN and NFV:
In order to ensure that VNF capacity is optimized, its
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.
SDNenabled 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 servicelevel agreements (SLAs) are
enforced and secured.
42

SDN controllers also play a major role in service orchestration 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.
Chapter8
HPEs Approach to NFV

In This Chapter
Exploring the HPE OpenNFV reference architecture
Looking at HPEs new vision for OSS
Working with HPE OpenNFV partners
Testing solutions in the HPE OpenNFV labs
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 personalized and on-demand services to their customers.
The adoption of NFV and SDN technologies and related evolution 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 possible for CSPs to move network functions from traditional and
proprietary, monolithic, hardwarecentric 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.
44
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

software is separated from the
underlying hardware. The goal
is to enable virtualized network
functions (VNFs) to run on standardized, open platforms.
Virtualize: In this stage, network
functions are deployed on hypervisordriven, virtualized infrastructure resources. This lets
you achieve higher utilization,
better cost efficiencies, and the
ability to scale up/down rapidly.
Cloudify: In this stage, widearea
network is operated as part of
the cloud, holistically aligned
and consumed with compute
and storage pools. Enables
CSPs to achieve consistently
efficient networkwide resource
utilization, respond dynamically
to shifting traffic patterns and
customer demand, and instantiate services dynamically through
the use of automation.
Decompose: In this final stage,

monolithic network functions
are decomposed into elemental
building blocks. Services are
recomposed as microservices.
Network, compute, and storage
resources are geographically
distributed. CSPs can compose
new and improved services from
the building blocks, through use
of serviceaware interfaces that
provide seamless integration of
network, compute and storage
resources.
Each phase in this evolution delivers
incremental benefits, from reduced
OPEX to facilitating an agile services environment that encourages speedy development of new
and innovative applications and
services.
There may not be a need to complete
each phase of this evolution. Individual
deployments can start/jump ahead
to any phase as appropriate.
Chapter8: HPEs Approach to NFV
45
HPEs initiative to create an open platform and open ecosystem

around NFV is called OpenNFV. The OpenNFV program provides CSPs the foundation to build a programmable infrastructure 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 pretest and integrate multivendor solutions.
The primary goal of the OpenNFV program is to accelerate the
design, proofofconcept, 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
HPs OpenNFV Program: an open standardsbased Reference
Architecture, the HPE OpenNFV Partner Program, HPE
OpenNFV Labs, and ProofofConcept (POC) Projects. HPE
also provides a comprehensive transformation service offering 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, timetomarket, 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 disaggregated into separate pieces, the multitudes of interdependencies make changes and reconfiguration challenging both
timeconsuming and expensive.
The only way to make such a system work is with an open,
standardsbased architecture. Components must have open
interfaces with a wellunderstood architecture and clear
boundaries. Everyone across the ecosystem has to agree
on how the components will talk to each other and work
together.
46

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 defacto
standard emerges. With opensource development around the
defined interfaces, theres an agreedupon implementation
standard. OpenStack and other such opensource technologies have evolved in the data center, and a large portion of the
cloud deployments today are based on opensource 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 opensource initiatives like OpenStack and OpenDaylight.
The HPE OpenNFV reference architecture (see Figure81)
is a blueprint for how NFV components can be combined to
create robust NFV solution suites. Using the ETSI Reference
Architecture (see Chapter2) 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.
47
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
HPEprovided components or the ones that are preselected
by the CSP. HPEs MANO framework, which includes the NFV
Director and E2E Service management capability provided by
the HPE Service Director, is designed to integrate operations
of NFVenabled and legacy telecom infrastructure, and can
integrate old with new, and HPE subsystems and components with others. This gives CSPs the freedom to build an
NFV solution to meet their needs without vendor lockin.
HPE provides CSPs the industrys most reliable, fully integrated and tested carriergrade 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 principles that NFV MANO solutions bring to the table. HPEs
vision for the new OSS centers around an endtoend Service
Management layer that can create services across the NFV
enabled infrastructure, as well as traditional telecommunications infrastructure (seeFigure82).
Figure 8-2:HPEs vision for OSS transformation.
48

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 describing the behavior and requirements of the traditional and
virtualized operations
The concept of dynamically declaring a service, its relationships and behavior (policies)
This approach replaces the current workflowbased 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 runtime 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 selfhealing the OSS
listens to the network health and reconfigures it to circumvent the problem.
The key capabilities that HPE provides in this endtoend
Service Management layer are
Agile service building: A modelbased design approach
that can create dynamic service models and update
relationships in realtime. This provides the ability to
implement an industrialized system for creating dynamic
services across Physical Network Functions (PNFs) and
Virtual Network Functions (VNFs).
Endtoend service analytics: Provides realtime and
longterm analytics to be used for determining changes
that need to be made to service offers in realtime. This
also helps to unify operations across service assurance
and service fulfillment.
Automated selfhealing: Uses analytics to provide real
time detection and correction for errors during operations across hybrid infrastructure.
Flexible integration: Realtime application programming
interfaces (APIs) provide integration with the broader
OSS ecosystem.
49
With the new OSS architecture, CSPs have a singlepaneof

glass view of operations across their entire infrastructure
traditional or NFVenabled. The resulting visibility will enable
Operations teams to proactively detect customeraffecting
problems and speed up the investigation and resolution
of complex issues. HPEs approach to OSS tranformation
enables CSPs to embark on this transformation at a pace of
their choosing. The HPE Service Director, with its capability tobridge 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 HPEs 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, characterization, 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.
50
HPE OpenNFV Labs

With the approach of encouraging opensource development,
its critical to test and share information about different
vendor implementations. Proofofconcept (PoC) projects can
demonstrate key capabilities that can be implemented, but
are often customerspecific 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 endtoend 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 environment where carriers can test the integration between vendors 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 multiple 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 HPEs reference
architecture.
NFV ProofofConcept 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
51
Telco cloud
NFV orchestration
Virtual evolved packet core (vEPC)
Multiservice 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 transformation, 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 organizations 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.
52
The HPE perspective:

NFV and the Telco Cloud
Its rare to identify a sea change
while the sea change is under
way. But with a development like
NFV, the transformation is so
profound and holds so much
promise that its impossible to
ignore the ramifications.
NFV is the biggest change for communications service providers since
IP showed up, says Saar Gillai,
HPEs senior vice president and
general manager of Communications
Solutions Business, and the person responsible for the companys
overall telecommunications strategy. Remember when we moved
from dedicated lines and circuit
switching to IP? Thats the level of
change were seeing here.
Gillai recently talked about how NFV
is moving entire networks from proprietary, dedicated metal boxes to
open, flexible services optimized
for the cloud, and why in the new
telecom paradigm, agility and nimbleness trump the old standards of
stability and capacity.
Q. How has the communications
landscape evolved over the past 12
months?
A. There have been a lot of changes
in terms of softwareization and network virtualization, but to summarize
it, 2014 was about the what. What is
it? 2015 was about the why. Why are
we doing this? And now in 2016, we
are talking about the how. So I think

theres an embrace of this need to
move to the cloudification and software model, and that, over the last
year, has really taken off. People
now are talking about, How do I do
it? and How do I move forward?,
where as last year was more about
the, Why should we do this?
Q. What is HPEs point of view on the
evolution?
A. A few years back, we saw this
coming along, and realized that for
the communications service providers (CSPs) to move from this
connectivity business to become a
digital service provider, they need
to embrace this change. One of the
things that we looked at is that the
world is moving from where everything is based on specs to more ecosystem plays, because thats how
this world works. So we launched
our OpenNFV program to start building out the ecosystem for that.
More generally, our view is that the
CSPs need to embrace what we call
the Telco Cloud, to become full
digital service providers, and we can
help them drive that manner by going
through an organized process of getting there. So we think that they need
to embrace that, and there are many
facets of doing it.
They need to focus on implementing and cloudifying programmable
infrastructure. They need to address

the orchestration piece because
they need to move from the very
manualbased operation to full automation. Lastly, they have to have a
better way of managing their data.
In the bigger picture, it is essential
to understand the importance of
culture, business case, and getting
early successes. If you are going to
do some virtualization or NFV, you
need to figure out What can you
do thats going to give you a quick
return?
For example, what we did with
Swisscom was to develop their virtual Customer Premise Equipment
(vCPE) solution. So you figure out
a way to do agile services, and go
from months to configure a service,
to minutes. Because the initiative was well defined in scope and
limited in complexity, Swisscom
expects to see the immediate return.
And while you see that, also, you
can drive the culture of adopting
some agility, and getting the organization comfortable with this model
before you take on very large things.
So, thats really an important piece
of the how, while always focusing on what the value proposition is
going to be at the top line, not just,
Okay, this is going to save me a lot
of money, but How do I increase
agility by d riving some of these
services?
Q. How and where has Hewlett
Packard Enterprise played a role in
this evolution?
53
A. So we saw this a few years ago,

and weve been pushing that direction. As the only vendor who is a
leader in IT and cloud, and also
has a lot of telco history, with our
CMS portfolio, and our HSS, and
our orchestration, were in a unique
position to help them on this journey,
because you need a combination
of both in this hybrid environment.
HPE has solutions across all the different levels here. Weve launched
solutions, enabled network virtualization based on open source, with
our leadership in OpenStack. NFV
System, as an integrated system,
allows you to deploy NFV quickly.
We launched NFV Director, which
really enables you to manage this
new virtual environment by leveraging the capabilities that are important in the OSS. Weve recently
launched, the Service Director. This
allows you to tie the current system,
all the way from the service, down
to the infrastructure. Because if you
make your infrastructure run really
fast, but the service is still very slow,
its not going to help you.
And were obviously driving this
big OpenNFV ecosystem, which we
believe is really the way forward.
Its not going to be a onevendor silo
environment, its going to be an ecosystem play. Also, in order to move
this forward, its a lot about doing
PoCs (proofs of concepts), getting
the CSPs comfortable that this really
is something thats important.
Were also working very heavily
on driving the business aspects of
(continued)
54

(continued)
this evolution. One of the key things

thats important here is the focus
on the business. The technology
is an enabler, but you have to say,
Okay, what do I need to do? And
now, moving forward, speed is the
most important thing. And to understand, How do I move faster?,
maybe I need to virtualize, maybe
I could do something else. How do
I move faster from service requirement, to service creation, to service
monetization?
And finally, a key element thats
really important is culture. We have
to move. Its interesting to talk about

all these new technologies, but
really, the most important thing is to
understand is that moving to these
technologies means to move to a
different culture, a more devops oriented, horizontal culture, and thats
not easy because the CSPs have
spent the past 20 years being very
successful in very organized, structured environments, and theyre good
for what they were doing, but theyre
not good for speed. And today the
winning plan for everything is speed.
Chapter9
Things to Consider
WhenTransforming to
an NFVEnabled CSP
Infrastructure
In This Chapter
Looking at financial and business considerations
Identifying technology and architecture considerations
Considering operations and processes
Weighing organizational considerations
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 arent sure how to go about the journey 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.
56

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 infrastructure. In many cases, multiple use cases may make sense
when theyre 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 transformation journey. This process of coming to an agreement on
the strategic vision of how the network will look and be operated is key to defining the steps in the journey. Of the many
considerations are the evaluation of the maturity of applications 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 applications into specific locations, but careful consideration
needs to be given to traffic patterns and interaction between
applications. Its also important to nail down the scaleout 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 trigger changes based on predefined policies is required. With
the right orchestration engine, zerotouch or nearzerotouch
activation can be supported. These features ensure that the
agility, OPEX, and even CAPEX benefits of NFV can be realized.
The choice of integrating bestinbreed applications on an
open platform will also bring forth decisions to be made on
system integration and validation.
Chapter9: Things to Consider WhenTransforming 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 reality of the way the new infrastructure operates.
Organization
Last but not the least is the organizational consideration
when moving to an NFVbased architecture. NFV drives the
CSP infrastructure to be more open, more virtualized, and
more ITcentric. 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 CSPs 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.
58
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 carriers GPRS, 3G, or 4G mobile network and another network, such as the Internet.
Aggregate Business Entity (ABE): A welldefined set of information 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 operational standards and solutions for the information and communications 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 providers 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).
60

business support system (BSS): A computer system used by a
telco to run its customerfacing business operations.
BYOD: See bring your own device (BYOD).
CDN: See content delivery network (CDN).
CFS: See customerfacing 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 software 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).
customerfacing 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 carriers 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 architecture for a cellular system.
general packet radio service (GPRS): A packetoriented
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).
62

hypervisor: Software or firmware that runs between the computer operating system and the hardware kernel, and allows
multiple guest operating systems (or virtual machines
[VMs]) to run concurrently on a single physical host computer. 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 specializing in making or selling software.
Infrastructure as a Service (IaaS): A cloud computing model
in which the service provider hosts hardware, software, storage, and other infrastructure components for its subscribers.
IP Multimedia Subsystem (IMS): A session control architecture to support the provisioning of multimedia services over
EPC and other IPbased networks.
ISV: See independent software vendor (ISV).
LongTerm Evolution (LTE): A standard for highspeed wireless communication for mobile phones and data terminals.
LTE: See LongTerm 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, multitechnology
network node that enables differentiation, control, and monetization 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 architecture concept that proposes using IT virtualization technologies 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).
64

offline charging system (OFCS): A system allowing a communications service provider to charge its customers without
affecting realtime services.
ONF: See Open Networking Foundation (ONF).
online charging system (OCS): A system allowing a communications service provider to charge its customers in realtime,
based on service usage.
Open Networking Foundation (ONF): A nonprofit organization
focused on improving networking through SDN and standardizing the OpenFlow protocol and related technologies.
Open Platform for Network Functions Virtualization
(OPNFV): An opensource project focused on accelerating
NFVs evolution through an integrated, open platform.
OpenDaylight: A collaborative opensource project hosted by
The Linux Foundation, with the goal of accelerating the adoption of SDN and creating a solid foundation for NFV.
OpenStack: A free, opensource 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 companys
end product.
OSS: See operations support system (OSS).
OTT: See over the top (OTT).
over the top (OTT): A thirdparty service provider that delivers audio, video, and other media content over the Internet to
an enduser 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).
PCSCF: See ProxyCall Session Control Function (PCSCF).
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.
ProxyCall Session Control Function (PCSCF): 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 customers experiences with a service.
radio access network (RAN): Equipment, such as base stations (Node Bs), which connects mobile devices to the public
telephone network or the Internet.
RAN: See radio access network (RAN).
66

resourcefacing 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 resourcefacing service (RFS).
SaaS: See Software as a Service (SaaS).
SBC: See session border controller (SBC).
SCSCF: See ServingCall Session Control Function (SCSCF).
SDN: See softwaredefined networking (SDN).
servicelevel agreement (SLA): Formal minimum performance
standards for systems, applications, networks, or services
established between a service provider and customer.
ServingCall Session Control Function (SCSCF): The registrar
server in an IMS core network.
Serving Gateway (SGW): The gateway that terminates the
interface toward evolved UMTS Terrestrial Radio Access
(EUTRA), the air interface of 3GPPs 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 protocol for signaling and controlling multimedia communication
sessions.
settop box (STB): A hardware device that contains a TV tuner
and connects to a TV and external signal source. Also known
as a settop unit (STU).
settop unit (STU): See settop 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 servicelevel agreement (SLA).
Software as a Service (SaaS): A cloud computing model in
which the service provider hosts and manages software for its
subscribers.
softwaredefined networking (SDN): An approach to computer networking that allows network administrators to
manage network services through abstraction of lowerlevel
functionality.
STB: See settop box (STB).
STU: See settop unit (STU).
systems integrator (SI): A company that specializes in bringing component subsystems together into a whole and ensuring that those subsystems function together.
TM Forum: A nonprofit industry association for service providers 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).
68

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 Wileys ebook EULA.

NFV4Dummies HP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NFV4Dummies HP

Transféré par

Droits d'auteur :

Formats disponibles

These materials are 2016 John Wiley & Sons, Inc.

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

Production Editor: Siddique Shaik

Chapter1: Telecommunications Industry

Chapter2: What Is NFV?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter3: NFV Components: Network Functions

Chapter4: NFV Components: VNF and EMS. . . . . . . . . . 21

Chapter5: NFV Components: Management

Network Functions Virtualization For Dummies 

Chapter6: Complementing NFV with OSS

Chapter7: NFV Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter8: HPEs Approach to NFV. . . . . . . . . . . . . . . . . . 43

Chapter9: Things to Consider WhenTransforming

ommunications service providers (CSPs) are evolving

About This Book

Network Functions Virtualization For Dummies 

Icons Used in This Book

Beyond the Book

Where to Go from Here

Network Functions Virtualization For Dummies 

n this chapter, you explore several telecommunications

Network Functions Virtualization For Dummies 

Chapter1: Industry Challenges and Opportunities

The Origins of NFV

Network Functions Virtualization For Dummies 

Network Functions Virtualization For Dummies 

ETSI NFV Framework

Chapter2: What Is NFV?

Figure 2-1:Highlevel NFV architectural framework.

The ETSI NFV framework consists of three major components:

Network Functions Virtualization For Dummies 

NFV Business Goals

Business goals enabled by NFV

Chapter2: What Is NFV?

New opportunities and more innovation: Innovative

Network Functions Virtualization For Dummies 

Chapter2: What Is NFV?

NFV creates an elastic relationship between services and

Network Functions Virtualization For Dummies 

NFV Components: Network

Network Functions Virtualization For Dummies 

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

Where a geographically distributed NFVI is required, several

Virtual Resources and the

Chapter3: NFV Components: NFVI

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

Network Functions Virtualization For Dummies 

n this chapter, you learn the basics of the Virtual Network

Virtual Network Functions

Network Functions Virtualization For Dummies 

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

Chapter4: NFV Components: VNF and EMS

Running a VNF across multiple VMs may be desirable for fault

Element Management System

Network Functions Virtualization For Dummies 

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

Performing lifecycle management

n this chapter, I discuss the various components that form

This new mode of operation with virtualization introduces

The Virtualized Infrastructure

Network Functions Virtualization For Dummies 

Figure 5-1:VIM in NFV MANO.

Chapter5: NFV Components: Management and Orchestration

Figure 5-2:VNFM in an NFV architecture.

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Figure 2-1:Highlevel NFV architectural framework.

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

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

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

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

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

Network Functions Virtualization For Dummies

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

Network Functions Virtualization For Dummies

Figure 5-1:VIM in NFV MANO.

Figure 5-2:VNFM in an NFV architecture.

Network Functions Virtualization For Dummies

Figure 5-3:NFVO in NFV MANO.

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Figure 8-1:The HPE OpenNFV reference architecture.

Figure 8-2:HPEs vision for OSS transformation.

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies

Network Functions Virtualization For Dummies