Network Functions Virtualization For Dummies® Hewlett Packard

Transcription

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
Network Functions Virtualization For Dummies®, Hewlett Packard Enterprise Special Edition
Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030‐5774
www.wiley.com
Copyright © 2016 by John Wiley & Sons, Inc., Hoboken, New Jersey
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the
prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com,
Making Everything Easier, and related trade dress are trademarks or registered trademarks of John
Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used
without written permission. All other trademarks are the property of their respective owners. John
Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE
NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR
COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL
WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A
PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR
PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE
SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE
PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL
SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT
PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR
SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION
OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE
OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER
ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR
RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET
WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN
THIS WORK WAS WRITTEN AND WHEN IT IS READ.
ISBN 978‐1‐119‐14992‐7 (pbk); ISBN 978‐1‐119‐14993‐4 (ebk)
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
For general information on our other products and services, or how to create a custom For
Dummies book for your business or organization, please contact our Business Development
Department in the U.S. at 877‐409‐4177, contact info@dummies.biz, or visit www.wiley.com/
go/custompub. For information about licensing the For Dummies brand for products or s ervices,
contact BrandedRights&Licenses@Wiley.com.
Publisher’s Acknowledgments
Some of the people who helped bring this book to market include the following:
Development Editor: Elizabeth Kuball
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,
Scott Lindsay, 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
Chapter 1: Telecommunications Industry
Challenges and Opportunities . . . . . . . . . . . . . . . . . . . . 5
Industry Challenges and Opportunities................................... 5
The Origins of NFV...................................................................... 7
Chapter 2: What Is NFV?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
NFV Defined................................................................................. 9
ETSI NFV Framework................................................................ 10
NFV Business Goals and Challenges....................................... 12
Business goals enabled by NFV.................................... 12
NFV challenges................................................................ 13
Chapter 3: NFV Components: Network Functions
Virtualization Infrastructure. . . . . . . . . . . . . . . . . . . . . 17
Hardware Resources................................................................ 17
Virtual Resources and the Virtualization Layer.................... 18
Chapter 4: NFV Components: VNF and EMS. . . . . . . . . . 21
Virtual Network Functions....................................................... 21
Element Management System................................................. 23
Chapter 5: NFV Components: Management
and Orchestration (MANO). . . . . . . . . . . . . . . . . . . . . . 25
The Virtualized Infrastructure Manager................................ 25
VNF Manager............................................................................. 27
NFV Orchestration.................................................................... 28
iv
Network Functions Virtualization For Dummies
Chapter 6: Complementing NFV with OSS
Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Driving OSS Transformation.................................................... 32
Getting Started with OSS Transformation............................. 33
Chapter 7: NFV Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 35
Virtualization of Mobile Core Network and
IP Multimedia Subsystem..................................................... 35
NFVIaaS...................................................................................... 36
VNFaaS....................................................................................... 37
VNPaaS....................................................................................... 37
VNF Forwarding Graphs........................................................... 38
Virtualization of Mobile Base Station..................................... 38
Virtualization of the Home Environment............................... 39
Virtualization of Content Delivery Networks........................ 39
Fixed‐Access NFV...................................................................... 40
NFV and Software‐Defined Networking.................................. 41
Chapter 8: HPE’s Approach to NFV. . . . . . . . . . . . . . . . . . 43
HPE OpenNFV Reference Architecture.................................. 45
A New Vision for OSS................................................................ 47
The HPE OpenNFV Partner Program...................................... 49
HPE OpenNFV Labs................................................................... 50
NFV Proof‐of‐Concept Projects............................................... 50
Transformation Services.......................................................... 51
Chapter 9: Things to Consider When Transforming
to an NFV‐Enabled CSP Infrastructure . . . . . . . . . . . . 55
Financial and Business............................................................. 55
Technology and Architecture................................................. 56
Operations and Processes....................................................... 57
Organization.............................................................................. 57
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Introduction
C
ommunications service providers (CSPs) are e
volving
their infrastructures at a rate rarely seen since the
industry’s transformation from analog to digital — and much
faster than the shift from time‐division multiplexing (TDM) to
Internet Protocol (IP).
This transformation is profound and holds a lot of promise —
it’s impossible to ignore the implications. CSPs have an opportunity to move from disrupted to disruptor — and return to
the epicenter of the telecommunications ecosystem.
To do so, CSPs must embrace “IT‐ification” — the application
of mainstream IT technologies and techniques that have been
developed and adopted by enterprise segments to increase
their efficiency, customer responsiveness, and agility. While
managing this transformation, they must bridge their current
view of the network to the new network — there is no such
thing as “greenfield” here. And, because no single vendor can do
it all — CSPs must leverage an open, multivendor ecosystem.
Network functions virtualization (NFV) offers a new way for
CSPs to design, deploy, and manage networking services. By
decoupling the network functions from proprietary hardware
appliances and embracing virtualization and cloud technologies and techniques, CSPs can accelerate the introduction of
new, compelling services quickly and cost‐effectively. NFV
enables CSPs to reset the cost base of their network operations and create the flexible service delivery environments
they need to innovate more quickly and drive revenue.
About This Book
This book provides an in‐depth examination of NFV, including
the individual components of the NFV Reference Architecture
and Hewlett Packard Enterprise’s vision for the future of NFV.
2
Throughout the book, you’ll find lots of acronyms. In the
interest of readability, I don’t spell out every acronym. These
terms are defined in the Glossary at the end of the book. So, if
you come across an acronym you’re unfamiliar with, just turn
to the Glossary to find out what it means.
I would like to acknowledge the use of ETSI NFV Working
Group documents as a reference for many sections of this
book.
Foolish Assumptions
It has been said that most assumptions have outlived their
uselessness, but I assume a few things nonetheless:
✓✓You work in the telecommunications industry. Perhaps
you work for a CSP, a network equipment provider
(NEP), an independent software vendor (ISV), or a
service integrator (SI). As such, you’re broadly familiar
with telecommunications and networking concepts,
fundamentals, and terminology.
✓✓You’re somewhat familiar with virtualization technology. You don’t experience anxiety attacks and hyperventilate when someone starts talking about hypervisors.
✓✓You’re a business or technical decision maker in your
organization and you’re interested in learning about
NFV. If that’s the case, then this is the book for you!
Icons Used in This Book
Throughout this book, I use special icons to call attention to
important information. Here’s what you can expect:
This icon points out information that may well be worth committing to your nonvolatile memory, your gray matter, or your
noggin — along with anniversaries and birthdays!
You won’t find a map of the human genome in this book, but
if you seek to attain the seventh level of NERD‐vana, perk up!
This icon explains the jargon beneath the jargon!
Introduction
3
Thank you for reading. Hope you enjoy the book. Please take
care of your writers! Seriously, this icon points out helpful
suggestions and useful nuggets of information.
Proceed at your own risk . . . well, okay — it’s actually nothing
that hazardous. These useful alerts offer practical advice to
help you avoid making potentially costly mistakes.
Beyond the Book
Although this book is chock‐full of information, there’s only
so much I can cover in this book! So, if you find yourself at the
end of this book, thinking, “Gosh, this was an amazing book!
Where can I learn more?,” just go to www.hpe.com/csp/nfv.
There, you can learn more about NFV.
Where to Go from Here
With my apologies to Lewis Carroll, Alice, and the Cheshire Cat:
“Would you tell me, please, which way I ought to go from
here?”
“That depends a good deal on where you want to get to,” said
the Cat — err, the Dummies Man.
“I don’t much care where . . . ,” said Alice.
“Then it doesn’t matter which way you go!”
That’s certainly true of Network Functions Virtualization For
Dummies, which, like Alice in Wonderland, is also destined to
become a timeless classic!
If you don’t know where you’re going, any chapter will get you
there — but Chapter 1 might be a good place to start!
However, if you see a particular topic that piques your interest,
feel free to jump ahead to that chapter. Each chapter is individually wrapped (but not packaged for individual sale) and
4
written to stand on its own, so you can start reading anywhere
and skip around to your heart’s content! Read this book in any
order that suits you (though I don’t recommend upside down
or backward).
I promise you won’t get lost falling down the rabbit hole!
Chapter 1
Telecommunications
Industry Challenges
and Opportunities
In This Chapter
▶▶Recognizing current challenges and opportunities
▶▶Looking back at NFV’s beginnings
I
n this chapter, you explore several telecommunications
industry trends that are driving NFV and how it evolved.
Industry Challenges
and Opportunities
We are living in an increasingly hyperconnected world —
and it’s not just humans that are connected anymore —
the Internet of Things (IoT) is creating new connectivity
requirements and scenarios for our world! The CSPs who
are responsible for providing this connectivity are facing
an exponential rise in traffic and the number of subscribers
on their networks. Today, CSPs are facing challenges on 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
6
growth is set to continue through 2020, when mobile data
levels are estimated to reach 228,491 PB.
✓✓Shifting landscape: Increasing relevance of applications
over pure connectivity and a new breed of competitors
with new business models — for example, from over‐
the‐top (OTT) players, such as Hulu and Netflix, who are
agile, flexible, and able to roll out revenue‐generating
services much faster. Changing and ever‐increasing 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 value‐added applications or service functions that
CSPs use in their network infrastructure, enabling them to
reduce cost and improve time‐to‐market.
NFV is transforming the way that CSPs architect and design
parts of their networks. Using standard IT virtualization technologies, NFV allows a CSP to consolidate the plethora of
applications and specialized network equipment they use in
their network onto industry‐standard high‐volume servers,
Chapter 1: Industry Challenges and Opportunities
7
switches, and storage. NFV ensures that CSPs will 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 time‐to‐market.
✓✓Simplifying the planning and scaling of the network:
New hardware can be quickly added, allowing CSPs to
add or delete application or service capacity on demand
to meet the elastic needs of the traffic, without long 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
software‐defined networking (SDN) movement, and the move
to virtualization and the cloud in data centers, the NFV concept
8
emerged as a call to action by a global group of t elecom
industry operators in 2012. The Industry Specification Group
on NFV (NFV ISG) forum was formed under the European
Telecommunications Standards Institute (ETSI) to address this
issue. The group published the first formal definition of NFV —
the “NFV Architectural Framework” — in 2013.
The NFV industry movement began with the goal of saving
capital equipment costs by transferring network functions
from expensive proprietary platforms to commodity servers.
Over time, network operators have become more interested
in other benefits, starting with improved operations efficiency
and moving to building new service revenues through agile
service creation.
Chapter 2
What Is NFV?
In This Chapter
▶▶Understanding NFV
▶▶Building a framework for NFV
▶▶Recognizing NFV business goals and challenges
I
n this chapter, you learn about network functions virtualization (NFV) — what it is, how the different architectural
components work together, how it’s used, and how organizations can benefit from NFV.
NFV Defined
Today’s telecom networks are primarily built using specialized,
often proprietary, equipment. (In the telecom industry,
proprietary often means a technology or solution that is owned
by a single company.) Some examples of typical telecom
equipment are routers, switches, base stations, firewalls,
voice gateways, and IMS and Mobile Packet Core. These types
of equipment are typically monolithic in design; that is, they
consist of hardware, software, and associated management
systems.
This type of architecture often leads to silos of operations,
vendor lock-in, and the inability to respond to changing
demands in an agile way.
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
the network functions and applications are implemented
as software-only entities and are designed to be independent
of the hardware. These software entities use standard
off-the-shelf compute and storage elements as the hardware
platform.
This new architecture provides CSPs with an open platform
on which innovative software functions and applications
from a diverse vendor ecosystem can be implemented. NFV
provides a way for CSPs to increase their service and 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 high‐level functional architectural framework for NFV
(see Figure 2‐1). Note: The figure includes references for
interfaces between the different architectural components.
Explanation of these interfaces is beyond the scope of this
book.
Chapter 2: What Is NFV?
11
Figure 2-1: High‐level NFV architectural framework.
The ETSI NFV framework consists of three major components:
✓✓Network Functions Virtualization Infrastructure (NFVI):
A subsystem that consists of all the hardware (servers,
storage, and networking) and software components on
which Virtual Network Functions (VNFs) are deployed.
This includes the compute, storage, and networking
resources, and the associated virtualization layer
(hypervisor).
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, software‐only
entities referred to as VNFs running on virtual assets c
reated
by a virtualization layer from a pooled set of physical
hardware resources that comprise the NFVI.
NFV Management and Orchestration (MANO) provides
orchestration and lifecycle management of the virtualized
software resources of the NFVI and the VNFs, as well as
any virtualization‐specific management tasks in the NFV
framework.
NFV Business Goals
and Challenges
NFV is a radical shift in the design and use of telecom 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 time‐to‐market: Rapidly introduce new services
by reducing the time it takes to deploy and validate new
software applications (from months to minutes).
✓✓Improved business processes: Virtualization enables
applications to be decoupled from their underlying infrastructure. This creates opportunities for automation and
business process management (BPM) re‐engineering
initiatives.
✓✓Optimized OPEX: Dedicated telco hardware requires
specialized skills to support and maintain. Virtualization
on industry‐standard platforms that are more readily
supported by IT personnel helps to reduce operating
expenses. The higher level of automation enabled by NFV
also reduces the amount of manual effort required in 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 on‐demand scalability, which helps to eliminate
or delay further investments in expensive, specialized
infrastructure.
These benefits will provide CSPs with a unique opportunity to
be more efficient by leveraging virtualization to improve their
operational capabilities from end‐to‐end.
NFV challenges
Although NFV offers many benefits for service providers, it
will impact future organizations and create challenges for
operations and operations support systems (OSS). Unless
addressed appropriately, these challenges can impact a
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
telco‐grade availability and high performance, and meet the
stringent SLAs that are typical in the CSP world.
Additionally, there is large installed base of legacy telco
equipment. Although much of this current infrastructure will
eventually be replaced by virtualized entities, either through
an NFV transformation initiative or normal lifecycle management, a hybrid environment will always exist. Virtualization
of certain telco equipment won’t necessarily be feasible or
desirable in every deployment situation.
Operations challenges
A significant operational challenge of the NFV transformation
is how to maintain the customer and services views that are
tied to the underlying infrastructure. This requires integration
within existing OSS/business support systems (BSS) environments and end‐to‐end 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 real‐time and
highly automated. In order to take full advantage of the
investments in the infrastructure, CSPs will have to revamp
the way they offer services to their customers. The existing
models of a fixed number of service offerings that are ordered
from a catalog and need time to be deployed will have to
be transformed into a model that allows customers to have
self‐care portals from which they will be able to personalize
their service offers. This transformation to a personalized,
on‐demand service delivery will require changes in the way
services are created and billed. The “catalog” of services that
can be offered to a customer will need to be dynamic and
policy based. The challenges in the service domain will mainly
be in the area of managing a dynamic service offering and
its integration to the underlying infrastructure and real‐time
analytics.
16
Chapter 3
NFV Components: Network
Functions Virtualization
Infrastructure
In This Chapter
▶▶Recognizing the physical components of NFVI
▶▶Building a virtual infrastructure
I
n this chapter, you learn the basics of the NFVI. The NFVI
is the infrastructure on which the VNFs are hosted and
executed. This infrastructure consists of hardware (compute,
storage, and networking) and software resources (like the
virtualization layer or the hypervisor that creates virtual
compute, storage, and networking resources).
Hardware Resources
Hardware that comprise the NFVI include compute, storage,
and network resources (see Figure 3‐1). These are the shared
resources that a VNF uses (through a virtualization layer) for its
processing, storage, and connectivity needs. Commercially available servers form most of the computing hardware. Storage can
either be direct‐attached storage in the servers or shared network‐
attached storage (NAS) and storage area networks (SANs).
Network resources include switching functions, such as routers
and wired (or wireless) links. Together, they can form an
NFVI point-of‐presence (NFVI PoP). An NFVI PoP is defined as
a location where a VNF can be deployed. An NFVI PoP n
etwork
interconnects the compute and storage resources within a
NFVI PoP.
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 Figure 3‐2).
These virtual resources are presented as an independent
entity for each VNF.
Chapter 3: NFV Components: NFVI
19
Figure 3-2: Virtual resources and the virtualization layer in NFVI.
The virtualization layer (commonly referred to as a 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.
Chapter 4
NFV Components:
VNF and EMS
In This Chapter
▶▶Virtualizing physical network devices and functions
▶▶Managing network elements
I
n this chapter, you learn the basics of the Virtual Network
Function (VNF) and the associated Element Management
System (EMS).
Virtual Network Functions
In traditional networks, network functions are typically implemented as purpose‐built 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 a router or firewall. This concept is radically different from
the traditional implementation in many ways. Decoupling
of the software from the hardware allows the lifecycle and
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)
doesn’t usually change the essential functional behavior and
the external operational interfaces of a traditional Physical
Network Function (PNF), like a traditional router or a switch.
The VNF (see Figure 4‐1) can be implemented as a VM, multiple VMs, or a function implemented within a shared VM.
Figure 4-1: VNF in an NFV reference architecture.
Chapter 4: NFV Components: VNF and EMS
23
Running a VNF across multiple VMs may be desirable for fault
tolerance, load balancing, and scalability.
Here are a few factors to keep in mind while developing a VNF
implementation of a traditional network function:
✓✓Design for interoperability with different hypervisors.
(Hypervisors provide VNFs access to shared storage,
compute, and networking resources.)
✓✓Ensure that the process of virtualization does not create
new security threat vectors.
✓✓Ensure that the performance of the VNF is not negatively
impacted by virtualization.
Element Management System
An EMS is the management entity for network elements. It
helps to configure the network element; collects, analyzes,
and takes action on fault and performance information; and
manages security and accounting aspects of the network element. These functions are commonly referred to as fault, configuration, accounting, performance, and security (FCAPS). An
EMS performs management functions for one (one‐to‐one) or
more (one‐to‐many) VNFs (see Figure 4‐2). An EMS may itself
be a VNF in the NFV architecture.
The EMS has integration points with the following:
✓✓The VNF Manager (VNFM; see Chapter 5), to support
the VNF lifecycle management (for example, to trigger
scale‐out/‐in).
✓✓The Operations Support System (OSS, discussed in
Chapter 6), to support application configuration and
management and activation of customer services served
by that VNF.
The OSS may also be used to configure the VNF without
an EMS.
24
Figure 4-2: EMS in an NFV reference architecture.
Chapter 5
NFV Components:
Management and
Orchestration (MANO)
In This Chapter
▶▶Managing resources and data with the Virtualized Infrastructure
Manager
▶▶Performing lifecycle management
▶▶Managing end‐to‐end network services with the NFV Orchestrator
I
n this chapter, I discuss the various components that form
the MANO subsystem.
This new mode of operation with virtualization introduces
the need for a multi-tiered and distributed management layer.
The MANO subsystem within the NFV framework is designed
to address this mode of operation.
The Virtualized Infrastructure
Manager
The VIM is the management system used to control and
manage the compute, storage, and network resources of the
26
NFVI (see Figure 5‐1). Multiple VIMs may be deployed in an
NFVI. Here are the key functions of the VIM:
✓✓Resource management
•• Software inventory, including hypervisors, virtual
compute, storage, and network resources
•• Resource allocation
•• Infrastructure management, including dynamic
resource assignment, power management, and
resource reclamation
✓✓Operations management
•• Visibility and management of the NFVI
•• Root cause analysis of NFVI performance issues
•• Data collection for fault, performance, capacity, and
optimization
Figure 5-1: VIM in NFV MANO.
Chapter 5: NFV Components: Management and Orchestration
27
Resource management and allocation in a virtualized 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 real‐time.
VNF Manager
The Virtual Network Function Manager (VNFM) is the
entity that manages the virtualized network functions (see
Figure 5‐2). Traditionally, the management component
of a network function focuses on Fault Management,
Configuration Management, Accounting Management,
Performance Management, and Security Management (FCAPS).
With the introduction of virtualization, additional aspects
of managing the lifecycle of the VNF become a key function
of the management component. The VNFM and the Element
Management System (EMS) are closely aligned in providing
overall management support for the VNF.
Figure 5-2: VNFM in an NFV architecture.
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 VNF‐associated NFVI
resources and returning them to the NFVI resource pool)
NFV Orchestration
While the VNF Manager is responsible for the management
and operation of individual VNFs, the NFV Orchestrator is
responsible for managing network services that span multiple
VNFs (see Figure 5‐3). The NFVO is responsible for creating
end‐to‐end services across multiple VNFs. The NFVO is also
responsible for managing the lifecycle of Network Services (NS).
The key activities in VNF lifecycle management include the
following:
✓✓Onboarding an NS — for example, registering an NS in
the service catalog (the inventory of services that can be
used to create a product offering to the customers), and
ensuring that all the required parameters and associated
rules are registered as well.
✓✓Instantiating an NS — for example, creating an NS using
the predetermined parameters or templates.
✓✓Scaling up or scaling down an NS — for example, growing
or reducing the capacity of the NS.
✓✓Updating an NS by supporting configuration changes,
such as changing inter‐VNF connectivity or the VNF
instances that are part of the service.
Chapter 5: NFV Components: Management and Orchestration
29
Figure 5-3: NFVO in NFV MANO.
✓✓Creating, deleting, querying, and updating the forwarding
rules and sequence (VNF Forwarding Graph) of an NS.
✓✓Terminating an NS — for example, terminating all the VNF
instances and requesting the release of NFVI resources
associated to the NS and returning them to the NFVI
resource pool.
In order to fulfill its responsibilities, the NFVO consumes serv
ices exposed by other functions (such as VIM functions for
orchestrating interconnection between VNFs). Similarly, the
services provided by NFVO can be consumed by other functions that are authenticated and properly authorized (such
as Operations Support System (OSS) and Business Support
System (BSS).
30
Chapter 6
Complementing NFV with
OSS Transformation
In This Chapter
▶▶Increasing business agility with automation
▶▶Choosing an OSS transformation strategy
D
espite the expanding interest in deploying NFV
and software‐defined networking (SDN) solutions,
communication service provider (CSP) networks will likely
have to contend with their existing infrastructure for a long
time. The introduction of NFV will also require the creation
of a unified management, orchestration, and operations layer
that can support the vision of service and business agility that
NFV promises — over a hybrid infrastructure. CSPs will not be
able to fully realize the agility and efficiency benefits of NFV if
they do not transform their OSS and operational processes.
Hybrid infrastructure in the context of this book means a 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
Today’s OSS often consists of siloed structures with a strong
technology orientation that are rigid in their capability to
incorporate new services or bundle them together — much
like the proprietary, monolithic CSP infrastructure that, for
the most part, exists today. Service creation and delivery
within a CSP is handled by the following major components
of an OSS:
✓✓Service Fulfillment Functions that handle the service
design (idea to implement), service activation (order to
activate), and resource provisioning (plan to provision)
processes
✓✓Service Assurance Functions that cover the assurance
processes (trouble to resolve)
Today, CSPs’ operations typically view fulfillment and 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 today’s OSSs are also not
designed for the type of rapid instantiations and provisioning
processes that technologies like NFV and SDN bring to the
infrastructure.
The NFV management and orchestration (MANO) layer
(described in Chapter 5) takes into account management
of the NFV Infrastructure (NFVI), the Virtualized Network
Functions (VNFs), and the creation of Network Services (NSs).
However, NFV MANO does not extend the scope to creating
services across both physical (legacy telecom) and virtual
(NFV‐based) infrastructure — which will be the near‐term
reality for most CSPs.
The NFV MANO layer does, however, provide a framework for
agile service creation, which can be leveraged and adapted
as part of the transformation of the existing OSS layer to
Chapter 6: Complementing NFV with OSS Transformation
33
s upport both physical (traditional) and virtual (NFV enabled)
infrastructure — with the agility characteristic of virtual and
cloud‐based deployment models.
The NFV Framework not only provides a new set of management components, but also supports new business models.
Both of these use cases are described in Chapter 7. Thus, the
OSS layer must evolve to support these new business models
and enable greater supplier/partner integration.
For OSS to fully leverage the agility and flexibility of NFV,
it needs to be
✓✓Automated: Manual processes should be automated
wherever possible to make operations more agile
✓✓Catalog driven: Modular and intuitive with self‐care
capabilities that empower consumers and enterprises
✓✓Intent based: Abstracting workflows to expose only the
final result
✓✓Data focused: Harnessing analytics to provide 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,
intent‐based configuration, use of SDN controllers to be a
single point of configuration and management for certain
domains, among others. Cloud‐based approaches can tie
the relevant systems together and provide capabilities
such as zero‐touch commissioning, flow‐through provisioning, and network optimization for a more efficient
development environment.
✓✓Close relationship between assurance and fulfillment
processes: NFV architecture allows for real‐time insight
into the state of the network components and inventory.
This information is invaluable to fulfillment processes as
they create new service instances.
Many current OSS infrastructures cannot support these two
key aspects of NFV MANO because the relationship between
the fulfillment and assurance domains is relatively static, with
significant latency in synchronizing inventory information
between the two domains.
Without OSS transformation, the full benefits of NFV cannot
be realized.
Chapter 7
NF V Use Cases
In This Chapter
▶▶Looking at use cases proposed for NFV
▶▶Understanding the relationship between NFV and SDN
N
FV fundamentally changes the way that networks are
built, using standard IT virtualization technologies
to consolidate various types of network equipment onto
industry‐standard servers, switches, and storage. Some
possible use cases proposed for NFV by the ETSI NFV ISG
are described in this chapter.
Virtualization of Mobile Core
Network and IP Multimedia
Subsystem
Mobile networks today use many proprietary hardware
appliances and specialized equipment.
The Evolved Packet Core (EPC), which is comprised of several
specialized components, is the latest core network 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 IP‐based 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 lower‐cost, highly
customizable, and rapidly deployable systems that can scale
dynamically. These features are ideal for the rapidly emerging
and competitive IoT marketplace.
NFVIaaS
Many CSPs today offer both cloud computing and network
services to their customers. The NFVI‐as‐a‐Service (NFVIaaS)
use case is a scenario in which a service provider can offer
its NFVI resources (such as physical compute, net‐work, and
storage) as a service on which other CSPs can run their VNFs.
In an NFVIaaS model, the tenant CSP is responsible for installing, configuring and maintaining its VNFs running on the service provider’s virtualized infrastructure.
Running VNF instances inside an NFVI operated by another
service provider is one way that service providers can meet
the service‐level agreements (SLAs) and regulatory requirements of their global enterprise customers, without actually
maintaining a physical presence around the globe.
Chapter 7: NF V Use Cases
37
VNFaaS
VNF‐as‐a‐Service (VNFaaS) is a model in which CSPs can
provide network functions as a service to their enterprise
without having to ship them a physical appliance.
The two most common examples of VNFaaS are Enterprise
virtualized Customer Premises Equipment (vCPE) and 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 bring‐your‐own‐device (BYOD) policies. Standalone purpose‐built appliances installed at branch
offices are cost prohibitive, slow to deploy, and difficult to
maintain. At the opposite end of the spectrum, all‐in‐one
devices provide severely limited functionality. Neither of
these solutions provides enterprises with the flexibility and
agility they require. In an enterprise vCPE model, the CSP can
offer the enterprise a basic connectivity device on premises
and offer all the value‐added network functions (like firewalls
and load balancers) as a service, hosted on the CSP cloud.
vPE is an example where routing functions in a PE can
be implemented as virtual functions and offered to other
applications (like virtual private network [VPN] services) in
an “as‐a‐Service” model.
In a SaaS model, the customer typically has little to no control
of the underlying infrastructure, operating system, databases,
or middleware. SaaS providers typically offer their customers a
specialized cloud‐based application, such as ADP or Salesforce.
VNFaaS extends the SaaS model to virtualized network 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 (VNF‐FG) provide logical connectivity
between virtual appliances. VNF forwarding graphs provide
greater agility in deployment and upgrades compared to
physical forwarding configurations. In addition, VNF 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
operator’s 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, software‐based 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 customer‐premise 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 Voiceover‐IP
(VoIP) services, and a set‐top box (STB) and/or digital video
recorder (DVR) for media services. Although these devices
are relatively inexpensive compared to enterprise CPE, the
volume of residential customers requires a significant CAPEX
and OPEX investment by service providers.
Virtualization of the home environment provides for lower
capital expenditures (CAPEX) by replacing dedicated CPEs
at residential premises with low‐functionality access devices.
These devices can have longer lifecycles, so they require less
maintenance and fewer upgrades. All the value‐added 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 ever‐increasing demand for rich multimedia content,
such as on‐demand video, streaming (high‐definition) audio
and video, and Internet Protocol television (IPTV), creates
major bandwidth and storage challenges for communications service providers. Integrating content delivery network
40
(CDN) nodes into operator networks can be an effective and
cost‐efficient solution to these challenges. Delivering content
from compute and storage nodes that are closer to the end
customer reduces network backhaul and enables higher‐
bandwidth, better‐quality content streams.
Currently, many CDN cache nodes are built on dedicated,
purpose‐built physical appliances and software. Virtualization
of CDN nodes offers service providers the flexibility to adapt
to new market conditions and opportunities. The field of
content delivery is characterized by rapid innovation in formats, protocols, and compression techniques. Implementing
software‐based functions allows easy migration and upgrades
of functionality. Additionally, it’s much simpler to maintain by
virtue of the use of industry‐standard hardware. Virtualization
also enables dynamic resource allocation and the ability to
avoid over‐engineering.
Fixed‐Access NFV
Broadband digital subscriber line (DSL) access is widely
deployed today for residential and small‐to‐medium business
(SMB) Internet service. However, hybrid fiber‐DSL and very‐
high‐bit‐rate DSL 2 (VDSL2) access technologies are quickly
replacing these deployments. Fixed access NFV addresses the
high costs and bottlenecks often associated with broadband
network access.
Newer access technologies require equipment to be placed in
remote street cabinets or in multi‐occupancy buildings. These
systems need to be highly energy efficient and need to be as
simple as possible to have a long service life. Virtualization
addresses these issues by moving complex processing to
the head end instead of the remote nodes. Current access
network equipment is usually owned and operated by a
single entity. Virtualization allows multi‐tenant operation
of this infrastructure and enables new business models.
Virtualization of fixed access network elements also enables
synergies from co‐location of wireless access assets on a
common NFVI point‐of‐presence (PoP) or platform.
41
NFV and Software‐Defined
Networking
Software‐defined networking (SDN) and NFV are highly
complementary technologies and mutually benefit each other.
While I won’t go into details of SDN in this book, the following
section highlights the close relationship between these 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 (SDN‐enabled hardware, SDN
controllers, and SDN applications) fit into the European
Telecommunications Standards Institute (ETSI) architecture.
Many ETSI proofs‐of‐concept (PoCs) have used SDN resources.
In a CSP network, SDN is key to operationalizing NFV deployments. Here are a few examples of the complementary role of
SDN and NFV:
✓✓In order to ensure that VNF capacity is optimized, it’s
essential that only the right traffic flows are directed
to the appropriate VNFs. SDN techniques like Service
Function Chaining (the ability to define an ordered list
of network services for a set of packets) are essential
for dynamically steering traffic flows to the right VNFs.
SDN‐enabled VNF Graphs are perhaps one of the most
common use cases that combine SDN and NFV.
✓✓One of the key benefits of NFV is the ability to VNFs
instantiate in datacenters closest to where they would be
consumed. SDN is essential to ensure that when VNFs are
migrated across datacenters, the network connectivity
parameters and service‐level agreements (SLAs) are
enforced and secured.
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.
Chapter 8
HPE’s Approach to NFV
In This Chapter
▶▶Exploring the HPE OpenNFV reference architecture
▶▶Looking at HPE’s new vision for OSS
▶▶Working with HPE OpenNFV partners
▶▶Testing solutions in the HPE OpenNFV labs
H
ewlett Packard Enterprise believes that CSPs that are on
the quest for higher agility, innovation, and efficiency
should embrace the notion of the Telco Cloud. Telco Cloud is
the idea of transforming infrastructure to be programmable
and operations to be automated so that CSPs can deliver 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, hardware‐centric architectures to
open and agile architectures based on cloud technologies.
At HPE, the strategy is to provide a reference architecture,
the NFVI and MANO platforms, a rich partner ecosystem, test
facilities to validate solutions, and world-class transformation
support services to enable CSPs to make the transition to NFV.
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.
Chapter 8: HPE’s Approach to NFV
45
HPE’s initiative to create an open platform and open ecosystem
around NFV is called OpenNFV. The OpenNFV program 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 pre‐test and integrate multi‐vendor solutions.
The primary goal of the OpenNFV program is to accelerate the
design, proof‐of‐concept, trial, and deployment of new cloud‐
enabled network services and innovations built on carrier‐
grade systems, while lowering capital expenditures, operating
expenditures, and risk.
In this chapter, you learn about the four essential elements of
HP’s OpenNFV Program: an open standards‐based Reference
Architecture, the HPE OpenNFV Partner Program, HPE
OpenNFV Labs, and Proof‐of‐Concept (POC) Projects. HPE
also provides a comprehensive transformation service 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, time‐to‐market, and
cost — and they can innovate and scale each component
independently with separate development timelines for each
piece. However, the reality is that once the system is disaggregated into separate pieces, the multitudes of interdependencies make changes and reconfiguration challenging — both
time‐consuming and expensive.
The only way to make such a system work is with an open,
standards‐based architecture. Components must have open
interfaces with a well‐understood architecture and clear
boundaries. Everyone across the ecosystem has to agree
on how the components will talk to each other and work
together.
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 de‐facto
standard emerges. With open‐source development around the
defined interfaces, there’s an agreed‐upon implementation
standard. OpenStack and other such open‐source technologies have evolved in the data center, and a large portion of the
cloud deployments today are based on open‐source projects.
The same approach is under way for CSPs in NFV.
HPE is actively involved and has leadership roles in many
standards organizations, making significant contributions to
European Telecommunications Standards Institute (ETSI),
Open Networking Foundation (ONF), Open Network Function
Virtualization (OPNFV), TM Forum, and open‐source initiatives like OpenStack and OpenDaylight.
The HPE OpenNFV reference architecture (see Figure 8‐1)
is a blueprint for how NFV components can be combined to
create robust NFV solution suites. Using the ETSI Reference
Architecture (see Chapter 2) as a starting point, it includes
processors, cache, operating systems, storage, networking,
switching, hypervisors, middleware, management systems,
orchestration, applications, and other components optimized
for NFV processing.
Figure 8-1: The HPE OpenNFV reference architecture.
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
HPE‐provided components or the ones that are preselected
by the CSP. HPE’s MANO framework, which includes the NFV
Director and E2E Service management capability provided by
the HPE Service Director, is designed to integrate operations
of NFV‐enabled and legacy telecom infrastructure, and can
integrate “old” with “new”, and HPE subsystems and components with others. This gives CSPs the freedom to build an
NFV solution to meet their needs — without vendor lock‐in.
HPE provides CSPs the industry’s most reliable, fully integrated and tested carrier‐grade NFV solution. These c
arrier‐
grade capabilities are packaged as HPE Helion OpenStack
Carrier Grade releases.
A New Vision for OSS
Hewlett Packard Enterprise (HPE) offers a new approach
to architecting the OSS layer to take advantage of the principles that NFV MANO solutions bring to the table. HPE’s
vision for the new OSS centers around an end‐to‐end Service
Management layer that can create services across the NFV‐
enabled infrastructure, as well as traditional telecommunications infrastructure (see Figure 8‐2).
Figure 8-2: HPE’s 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 workflow‐based approach
to orchestration, in which a lot of the behavior and steps
are hard coded. In this new approach, the OSS can use these
dynamic declarations of state to create a run‐time list of
actions as opposed to sequential workflows. The service
descriptors are able to describe how the service should
behave in an exceptional scenario, such as the failure of a
component. This opens the door to self‐healing — the OSS
listens to the network health and reconfigures it to circumvent the problem.
The key capabilities that HPE provides in this end‐to‐end
Service Management layer are
✓✓Agile service building: A model‐based design approach
that can create dynamic service models and update
relationships in real‐time. This provides the ability to
implement an industrialized system for creating dynamic
services across Physical Network Functions (PNFs) and
Virtual Network Functions (VNFs).
✓✓End‐to‐end service analytics: Provides real‐time and
long‐term analytics to be used for determining changes
that need to be made to service offers in real‐time. This
also helps to unify operations across service assurance
and service fulfillment.
✓✓Automated self‐healing: Uses analytics to provide real‐
time detection and correction for errors during operations across hybrid infrastructure.
✓✓Flexible integration: Real‐time application programming
interfaces (APIs) provide integration with the broader
OSS ecosystem.
49
With the new OSS architecture, CSPs have a single‐pane‐of‐
glass view of operations across their entire infrastructure —
traditional or NFV‐enabled. The resulting visibility will enable
Operations teams to proactively detect customer‐affecting
problems and speed up the investigation and resolution
of complex issues. HPE’s approach to OSS tranformation
enables CSPs to embark on this transformation at a pace of
their choosing. The HPE Service Director, with its capability to bridge current and new operations, enables a smooth
transition.
The HPE OpenNFV Partner
Program
The OpenNFV Partner program is a very important part of
the move to create a rich, vibrant, and open ecosystem of
partners. The goal for HPE’s OpenNFV program is to create
a platform on which CSPs have the freedom to choose
applications from their vendor of choice.
To support this degree of flexibility and openness, the HPE
OpenNFV Partner Program includes younger, more agile,
smaller ISVs along with the leading NEPs, technology vendors,
and service providers.
The HPE OpenNFV Partner Program consists of three partner
categories:
✓✓Technology partners: Select technology companies and
vendors, including network equipment providers (NEPs),
original equipment manufacturers (OEMs), and CSPs that
collaborate on technology innovation, integration and
support for the HPE OpenNFV infrastructure stack.
✓✓Application partners and network equipment providers
(NEPs): These are ISVs that conduct testing, 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 open‐source development,
it’s critical to test and share information about different
vendor implementations. Proof‐of‐concept (PoC) projects can
demonstrate key capabilities that can be implemented, but
are often customer‐specific and built in whatever facilities are
available for testing.
To truly enable a robust NFV ecosystem, dedicated labs
are needed, where multiple vendors can come together to
test end‐to‐end solutions. These labs are meant to provide
an accurate representation of a slice of the network, which
allows carriers to try things out before implementing them in
production. The labs are also a service development 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 HPE’s reference
architecture.
NFV Proof‐of‐Concept Projects
HPE has been involved in developing a number of active NFV
use cases together with partners and international standards
organizations in Europe, the Americas, and Asia. These PoC
projects include the following use cases:
✓✓Voice/video
✓✓Mobile private networks
✓✓IP routing and transport
51
✓✓Telco cloud
✓✓NFV orchestration
✓✓Virtual evolved packet core (vEPC)
✓✓Multi‐service proxy (MSP)
✓✓Virtualized customer premise equipment (vCPE)
✓✓Virtualized IP Multimedia Subsystem (IMS)
Transformation Services
NFV deployments are a step in the CSP journey to a cloud‐
based infrastructure (Telco Cloud). As with any 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 organization’s goals.
3. Evaluate all aspects (if possible).
These include
•• Technology
•• Application
•• Organization and processes
4.Adapt, execute, and govern.
HPE offers a comprehensive transformation offering that
covers evaluation of strategic choices and planning, executing,
and lifecycle management of the entire process.
52
The HPE perspective:
NFV and the Telco Cloud
It’s 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 it’s impossible to
ignore the ramifications.
“NFV is the biggest change for communications service providers since
IP showed up,” says Saar Gillai,
HPE’s senior vice president and
general manager of Communications
Solutions Business, and the person responsible for the company’s
overall telecommunications strategy. “Remember when we moved
from dedicated lines and circuit
switching to IP? That’s the level of
change we’re 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 software‐ization 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
there’s 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 HPE’s 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 that’s 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
manual‐based 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 that’s 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, that’s 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 we’ve 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, we’re 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. We’ve 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. We’ve 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,
it’s not going to help you.
And we’re obviously driving this
big OpenNFV ecosystem, which we
believe is really the way forward.
It’s not going to be a one‐vendor silo
environment, it’s going to be an ecosystem play. Also, in order to move
this forward, it’s a lot about doing
PoCs (proofs of concepts), getting
the CSPs comfortable that this really
is something that’s important.
We’re also working very heavily
on driving the business aspects of
(continued)
54
(continued)
this evolution. One of the key things
that’s 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 that’s
really important is culture. We have
to move. It’s 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 that’s
not easy because the CSPs have
spent the past 20 years being very
successful in very organized, structured environments, and they’re good
for what they were doing, but they’re
not good for speed. And today the
winning plan for everything is speed.
Chapter 9
Things to Consider
When Transforming to
an NFV‐Enabled CSP
Infrastructure
In This Chapter
▶▶Looking at financial and business considerations
▶▶Identifying technology and architecture considerations
▶▶Considering operations and processes
▶▶Weighing organizational considerations
M
ost CSPs are aware of the benefits of moving to a new
type of infrastructure where they can run applications
in a virtualized environment and create services in an agile
manner. However, many aren’t sure how to go about the 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 they’re evaluated and implemented together.
An HPE NFV Transformation Workshop is a simple way to
start your NFV journey!
Technology and Architecture
Having an architecture blueprint of what the network would
look like after the transformation is critical to the NFV 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. It’s also important to nail down the scale‐out and
performance requirements for different applications. This will
help in planning and sizing the NFVI design.
Other aspects of architecture include transforming the OSS to
support the new breed of infrastructure while continuing to
operate traditional infrastructure. To fully realize the benefits
of NFV, a common orchestrator that understands resource
needs for services across a hybrid infrastructure and can trigger changes based on predefined policies is required. With
the right orchestration engine, zero‐touch or near‐zero‐touch
activation can be supported. These features ensure that the
agility, OPEX, and even CAPEX benefits of NFV can be realized.
The choice of integrating best‐in‐breed applications on an
open platform will also bring forth decisions to be made on
system integration and validation.
Chapter 9: Things to Consider When Transforming to an NFV
57
Operations and Processes
The decision to deploy NFV and embark on a transformation
will have major impact on the current operational processes
that are in place and perfected at most CSPs. Some examples
of this are the process of procurement, validation, system
acceptance, and troubleshooting.
Procurement organizations have historically relied on a single
vendor to provide the hardware, software, and management
functionality associated with a particular product or solution.
In the new world of NFV, these components are decoupled
from each other and may have different vendors providing
different parts. In such a scenario, the procurement process,
the process of validating, and the process of acceptance
testing for a product/solution also need to be revisited.
Troubleshooting and responsibility of service assurance
within the CSP will also need to be revamped to meet the reality of the way the new infrastructure operates.
Organization
Last but not the least is the organizational consideration
when moving to an NFV‐based architecture. NFV drives the
CSP infrastructure to be more open, more virtualized, and
more IT‐centric. This has profound impact on the competence
required for the personnel who operate and manage this
infrastructure.
The expertise for managing the different parts of the network
in this new architecture may reside in different organizations.
For example, the NFVI layer in the new network architecture
will be highly influenced by the CSP’s cloud and datacenter
strategies and the organizations within the CSPs that manage
it, while the competence and expertise for most of the VNF
layers may reside in the network operations team.
One of the key considerations in NFV deployment is to rethink
the best way to design organizations so that the processes
associated with running the new infrastructure are optimized.
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 carrier’s GPRS, 3G, or 4G mobile network and another network, such as the Internet.
Aggregate Business Entity (ABE): A well‐defined 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 provider’s network.
bring your own device (BYOD): A policy in which employees
are permitted to use their personal mobile devices, such as
smartphones and tablets, in the workplace for both work‐
related and personal business.
BSS: See business support system (BSS).
60
business support system (BSS): A computer system used by a
telco to run its customer‐facing business operations.
BYOD: See bring your own device (BYOD).
CDN: See content delivery network (CDN).
CFS: See customer‐facing service (CFS).
cloud service provider: A company that provides cloud services,
such as IaaS, PaaS, or SaaS to subscribers.
CloudEthernet Forum: An industry organization of market‐
leading cloud service providers, network service providers,
equipment manufacturers, system integrators, and 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).
customer‐facing service (CFS): An abstraction that defines the
characteristics and behavior of a particular service, as seen
by the customer.
customer premises equipment (CPE): Telecommunications
equipment — such as telephones, routers, switches, and
gateways — that is physically located at a customer site and
connected to a carrier’s telecommunications equipment at the
demarcation point.
DHCP: See Dynamic Host Configuration Protocol (DHCP).
digital video recorder (DVR): Hardware or software that
records video in a digital format to a storage device. Also
known as a personal video recorder (PVR).
Glossary
61
DNS: See Domain Name System (DNS).
Domain Name System (DNS): A hierarchical naming system
for computers, services, or any resource connected to
the Internet or a private network that provides a mapping
between IP addresses and domain names.
DVR: See digital video recorder (DVR).
Dynamic Host Configuration Protocol (DHCP): A network
protocol that dynamically assigns IP addresses and other
network parameters to devices connected to a network.
eNodeB: See Evolved Node B (eNodeB).
EPC: See Evolved Packet Core (EPC).
ETSI: See European Telecommunciations Standards
Institute (ETSI).
European Telecommunications Standards Institute (ETSI):
An independent, European organization for standardization in
the telecommunications industry.
Evolved Node B (eNodeB): Hardware that is connected to
the mobile phone network that communicates directly with
mobile handsets, such as a base transceiver station (BTS) in
GSM networks.
Evolved Packet Core (EPC): The latest core network architecture for a cellular system.
general packet radio service (GPRS): A packet‐oriented
mobile data service on 2G and 3G cellular communication
systems.
GPRS: See general packet radio service (GPRS).
home subscriber server (HSS): Functions as a location server
and authentication, authorization, and accounting (AAA)
server in the IMS, and serves as a single provisioning point for
IMS subscribers and their services.
HSS: See home subscriber server (HSS).
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 IP‐based networks.
ISV: See independent software vendor (ISV).
Long‐Term Evolution (LTE): A standard for high‐speed wireless communication for mobile phones and data terminals.
LTE: See Long‐Term Evolution (LTE).
Management and Orchestration (MANO): A framework
for automating the management and provisioning of NFV
resources. MANO functional blocks in NFV include the NFVO,
VNFM, and VIM.
MANO: See Management and Orchestration (MANO).
MME: See Mobility Management Entity (MME).
Mobility Management Entity (MME): The key control node for
the LTE access network.
MSP: See multiservice proxy (MSP).
multiservice proxy (MSP): A multipurpose, multi‐technology
network node that enables differentiation, control, and 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 real‐time services.
ONF: See Open Networking Foundation (ONF).
online charging system (OCS): A system allowing a communications service provider to charge its customers in real‐time,
based on service usage.
Open Networking Foundation (ONF): A nonprofit organization
focused on improving networking through SDN and standardizing the OpenFlow protocol and related technologies.
Open Platform for Network Functions Virtualization
(OPNFV): An open‐source project focused on accelerating
NFV’s evolution through an integrated, open platform.
OpenDaylight: A collaborative open‐source project hosted by
The Linux Foundation, with the goal of accelerating the adoption of SDN and creating a solid foundation for NFV.
OpenStack: A free, open‐source cloud computing software
platform.
operations support system (OSS): A computer system used by
a telco to manage its networks.
OPNFV: See Open Platform for Network Functions
Virtualization (OPNFV).
original equipment manufacturer (OEM): A company that
makes a part or subsystem that is used in another company’s
end product.
OSS: See operations support system (OSS).
OTT: See over the top (OTT).
over the top (OTT): A third‐party service provider that delivers audio, video, and other media content over the Internet to
an end‐user device using the Internet service provider (ISP)
network for transport.
PaaS: See Platform as a Service (PaaS).
Glossary
65
Packet Data Network Gateway (PGW): The gateway that
terminates the SGi interface (the reference point between the
PGW and the packet data network) toward the packet data
network.
PCRF: See Policy and Charging Rules Function (PCRF).
P‐CSCF: See Proxy‐Call Session Control Function (P‐CSCF).
personal video recorder (PVR): See digital video recorder
(DVR).
PGW: See Packet Data Network Gateway (PGW).
physical network function (PNF): A physical network device,
such as a router or a switch.
Platform as a Service (PaaS): A cloud computing model in
which the service provider hosts and manages infrastructure
and software components for its subscribers, in order for its
subscribers to develop and deploy custom applications on a
standard computing platform.
PNF: See physical network function (PNF).
Policy and Charging Rules Function (PCRF): Responsible for
policy control in the IMS core network.
Proxy‐Call Session Control Function (P‐CSCF): An SIP proxy
that functions as an SBC and is the first point of contact for
the IMS terminal.
PVR: See personal video recorder (PVR).
QoE: See quality of experience (QoE).
quality of experience (QoE): A measure of a customer’s 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
resource‐facing service (RFS): An abstraction that defines the
characteristics and behavior of a service that supports a CFS
but is not seen or purchased directly by the customer.
RFS: See resource‐facing service (RFS).
SaaS: See Software as a Service (SaaS).
SBC: See session border controller (SBC).
S‐CSCF: See Serving‐Call Session Control Function (S‐CSCF).
SDN: See software‐defined networking (SDN).
service‐level agreement (SLA): Formal minimum performance
standards for systems, applications, networks, or services
established between a service provider and customer.
Serving‐Call Session Control Function (S‐CSCF): The registrar
server in an IMS core network.
Serving Gateway (SGW): The gateway that terminates the
interface toward evolved UMTS Terrestrial Radio Access
(E‐UTRA), the air interface of 3GPP’s LTE upgrade path for
mobile networks.
session border controller (SBC): A Voice over Internet
Protocol (VoIP) network device that controls signaling and
the media streams involved in setting up, conducting, and
tearing down telephone calls or other interactive media
communications.
Session Initiation Protocol (SIP): A communications protocol for signaling and controlling multimedia communication
sessions.
set‐top box (STB): A hardware device that contains a TV tuner
and connects to a TV and external signal source. Also known
as a set‐top unit (STU).
set‐top unit (STU): See set‐top box.
SGW: See Serving Gateway (SGW).
Glossary
67
Shared Information/Data (SID) Model: A unified reference
data model providing a single set of terms for business
objects in telecommunications.
SI: See systems integrator (SI).
SID Model: See Shared Information/Data (SID) Model.
SIP: See Session Initiation Protocol (SIP).
SLA: See service‐level agreement (SLA).
Software as a Service (SaaS): A cloud computing model in
which the service provider hosts and manages software for its
subscribers.
software‐defined networking (SDN): An approach to computer networking that allows network administrators to
manage network services through abstraction of lower‐level
functionality.
STB: See set‐top box (STB).
STU: See set‐top unit (STU).
systems integrator (SI): A company that specializes in 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 Wiley’s ebook EULA.

Network Functions Virtualization For Dummies® Hewlett Packard

Transcription

Similar documents

iPPlus Sales Sheet - IP Plus Consulting, Inc.

modernizing the OSS approach for Virtual Infrastructure

Areva Serf 5 Profile Sheet - Jamerson

Wireshark vs. „The Cloud“

slides - Khosla Ventures

Tools of the Trade: Punching, Crunching, and

Virtualized Micro Data Center

Bluman, "Elementary Statistics a Step by Step Approach", 6th Edition

the full InnovAction magazine