NFV4Dummies HP

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

Network Functions Virtualization Hewlett Packard Enterprise Special Edition

by Balamurali Thekkedath


® 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 athttp://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 ISSOLD WITH THE UNDERST ANDING 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 [email protected] , or visit www.wiley.com/ go/custompub . For information about licensing the For Dum mies brand for products or services, contact [email protected] .

Publisher’s Acknowledgments Some of the people who helped bring this book to market include the following: Development Editor: Elizabeth Kuball

Production Editor: Siddique Shaik

Copy Editor: Elizabeth Kuball

Special Help: Elizabeth Palmer, Scott Lindsay, Daniel Montesanto, Melody Howard Yuhn, CEH, CISSP; Andreas Krichel

Acquisitions Editor: Katie Mohr Editorial Manager: Rev Mengle Business Development Representative: Karen Hattan


Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 About This Book ........................................................................ 1 Foolish Assumptions ................................................................. 2 Icons Used in This Book............................................................ 2 Beyond the Book ........................................................................ 3 Where to Go from Here ............................................................. 3

Chapter 1: Telecommunications Industry Challenges and Opportunities . . . . . . . . . . . . . . . . . . . .5 Industry Challenges and Opportunities .................................. 5 The Origins of NFV ..................................................................... 7

Chapter 2: What Is NF V?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Vir tualization I nfrastructure . . . . . . . . . . . . . . . . . . . . .1 7 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) . . . . . . . . . . . . . . . . . . . . . .2 5 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 . . . . . . . . . . . . . . . . . . . . . . . . .3 5 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 NF V. . . . . . . . . . . . . . . . . .4 3

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 Infra structure . . . . . . . . . . . . 55 Financial and Business ............................................................ 55 Technology and Architecture ................................................ 56 Operations and Processes ...................................................... 57 Organization ............................................................................. 57

Glossary .. . .. . . .. . .. . .. . .. . .. . .. . .. . .. . . .. . .. . .. 59


Introduction

C

ommunications service providers (CSPs) are evolving their infrastructures at a rate rarely seen since the industry’s transformation from analog to digital — and much faster than the shift from time‐division multiplexing (TDM) to Internet Protocol (IP). This transformation is profound and holds a lot of promise — it’s impossible to ignore the implications. CSPs have an 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 towww.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 w ho 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 r evenues: 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 telecom 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

In This Chapter

What Is NFV?

▶ Understanding NFV ▶ Building a framework for NFV ▶ Recognizing NFV business goals and challenges

n this chapter, you learn about network functions virtualization (NFV) —together, what it is,how howit’s theused, different architectural components work and how organizations can benefit from NFV.

I

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 created 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 services 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 These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.

14


successful 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, srcinating 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

NFFunctions V Compone nts: Network 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 network 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

NFVNF V Compo nents: 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

NF V Componenand ts: Management 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 hypervisor s, 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, perf ormance, 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. These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.

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, theNFV 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 ofNetwork 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 services 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

Comp nting NFV with OSSleme 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 acombination 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, CSPcreation infrastructure that, for the most part, existsmonolithic today. Service 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

support 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/partn er 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

NFV 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 provides with the flexibility and agilitysolutions they require. In an enterprises 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 theiror customers a specialized cloud‐based application, such as ADP 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

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.

H

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 clo ud, holi sti cal ly ali gned and consumed with compute and storage pools. Enables CSPs to achieve consistently efficient networkwide resource utilization, respond dynamically to shifti ng traff ic patte rns 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 carrier‐ 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 made to service offersservice in real‐time. This also need helpsto tobe unify operations across 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 par tners: Select technology companies and vendors, including network equipment providers (NEPs), srcinal equipment manufacturers (OEMs), and CSPs that collaborate on technology innovation, integration and support for the HPE OpenNFV infrastructure stack. ✓ Application partners and network equipment pr oviders (NEPs): These are ISVs that conduct testing, characterization, and validation of their applications and telecom functions on the HPE OpenNFV infrastructure stack. ✓ Service par tners: 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 caninbewhatever implemented, butare are often customer‐specific and built facilities 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 to assure CSPs that solutions being proposed to them fromismultiple 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?

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 com muni cat ions ser vice 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 CSPs need to embrace what we the 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.

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 They need to focus on implementwe doing this? And now in 2016, we ing and cloudifying programmable


53


infrastructure. They need to address the orc hes tra tion pie ce bec ause they need to move from the very manual‐based operation to full automation. Lastly, they have to have a

A. So we saw this a few years ago, and we’ve been pushing that direction. As the only vendo r who is a leader in IT and cloud, and also has a lot of telco history, with our

better way of managing their data. In the bigger picture, it is essential to unde rsta nd the impo rtan ce 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?”

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

For example, what we did with Swisscom was to develop their virtual Custom er Premis e Equipm ent (vCPE) solution. So you figure out a way to do agile services, and go from months to configure a service, to min ut es . Be ca use the in it ia tive 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 driving some of these services? Q. How and where has Hewlett Packard Enterprise played a role in this evolution?

really enables you to manage this new virtual environment by leveraging the capabilities that are importan t in the OSS . We’ ve rec ent ly 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 impor tant here is the focus on the business. The technology is an enabler, but you have to say,

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

“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?”

techno logie s 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.

And finally, a key element that’s really important is culture. We have


Chapter 9

Things to Consider When Transform ing 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, aren’t tooverview go about of the journey to NFV. In this many chapter, yousure get ahow brief 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 See

3rd Generation Partnership Project (3GPP).

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 a highly cohesive business entities that that characterizes are loosely coupled with entitiesset in of 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). See

BRAS: 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 A packet‐oriented mobile data service onservice 2G and(GPRS): 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 srcinal 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). srcinal 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):multimedia A communications protocol for signaling and controlling 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.

NFV4Dummies HP

Recommend Documents