dialogic cloud-ready solutions: a smart approach to … · dialogic cloud-ready solutions: a smart...

White Paper

Dialogic Cloud-Ready Solutions: A Smart Approach to NFV


2

White Paper

Executive SummaryService Providers are embracing a new deployment methodology for telecommunications network infrastructure that moves

functionality from proprietary hardware to virtualized, software-based applications deployed on commercial off-the-shelf (COTS)

servers leveraging the latest in virtualization technology. This is known as network functions virtualization (NFV). Why this disruptive

change, and why is this approach technically possible now? This white paper will discuss:

• How NFV makes sense as a way to eventually supplant current proprietary hardware-based deployment approaches

• The benefits Service Providers can hope to attain from NFV

• How Service Providers should phase their Virtualized Network Function (VNF) implementation strategy to take advantage of

cloud-centric benefits

• How Dialogic has been developing solutions that align with service provider initiatives in this space


3

White Paper

Table of ContentsNFV Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

NFV Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

CAPEX Savings Plus the Ability To Move Expenditures To OPEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

OPEX Savings from NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

The Ultimate Payoff - Accelerating Service Velocity and Increasing Flexibility Through NFV . . . . . . . . . . . . . . . . .6

NFV Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Dialogic Helps Service Providers Virtualize Their Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Dialogic NFV Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Focus on the VNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Phased Implementation to NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Phase I: move network functions to COTS hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Phase II: port network functionality to virtualized environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Phase III: NFV orchestration and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Phase IV: decomposition of VNF functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

NFV and SDN Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Dialogic Service Provider Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13


4

White Paper

NFV Overview

Service Providers are embracing a new deployment methodology known as NFV for telecommunications network infrastructure that eschews

discreet proprietary hardware-based infrastructure . The future of infrastructure deployment lies in software-based functionality deployed on

commercial off-the-shelf (COTS) servers leveraging the latest in virtualization . Major carriers like AT&T and Telefonica have made public their

intent to move to virtualized network functions, and some analysts estimate that virtualized network functions will be broadly deployed by 2017 .

Figure 1 – The virtualization of network applications

Why this drastic change? And why is running communications network infrastructure on software across a distributed collection of data centers

technically possible now? There are four major reasons why NFV is becoming reality:

• Advances in computing power: The computing power of today’s COTS hardware continues to advance in lockstep with Moore’s law; and

nowadays, the need to use purpose-built discrete hardware is considerably lower .

• Advances in virtualization technology: The virtualization technology that ushered in the cloud era was geared more toward transactional

computing . Additional challenges arise when processing data plane and control plane packets for real-time multimedia telecommunications .

These kinds of applications are CPU-intensive and sensitive to latency and dropped packets . Earlier versions of hypervisors geared more

toward transactional applications were not optimized to support the stringent scheduling requirements needed to minimize delay . Advances

in hypervisor technology, the introduction of containers, and media plane processing acceleration reduce the impact of virtualization

overhead and enable fast processing of not only the control plane but also the data plane traffic .

• Support for high availability and disaster recover with virtualization failover techniques: A major reason for purpose-built hardware is

the need for quick failover for an application to a standby dedicated platform . With virtualization of infrastructure and network functionality,

a failure with server, storage or network resources can be transparent to the VNFs . Recovery from such an incident can effectively happen

within the underlying Network Functions Virtualization Infrastructure (NFVI) layer and be corrected by the autonomous activity of a virtualized

infrastructure management function that implements the scaling out of instances in the event of a server, storage, or network problem . This is

a very different way of doing things compared to traditional telco-centric approaches, but one that can ultimately provide greater scalability

and reliability .

• Migration to all IP: As the networks themselves transition to IP, the need for physical connectors to TDM networks dissipates . As such,

network functions can be run in virtualized environments taking advantage of virtualized network interfaces . Also, these IP-based networks are

faster in unprecedented ways . 100Gbpbs speeds on the Internet backbone are here, as are Gigabit per second speeds to the home, thereby

better enabling a cloud-based NFV model .

Classical Hardware Appliance Approach• Fragmented non-commodity hardware• Physical install for each appliance• Hardware development = barrier to entry to new vendors

– Constrains innovation– Restricts competition

Network Functions Virtualization Approach• Diverse ecosystem of ISV application providers• Orchestrated, automatic and remote install• COTS servers, storage and networking• Cloud-based bene ts of agility and elasticity

SBC MRF/MRB SGW DPI Service Orchestrator

PGW/GGSN RANCDN

Source: ETSI NFV speci�cation group

CSCF

Firewall

Router NATWAN Acceleration MME/SGSN

BRAS MGCF Switch

Service

Cloud Orchestrator

Virtualized Applications

Virtualized Infrastructure

Application Orchestrator

dns

Virtual Appliance

duree

Virtual Appliance

Virtual Appliance

Cloud Orchestrator

Data Center

Virtual Switching

Virtual Computer

Virtual Storage

Service Chain


5

White Paper

Service Providers want to take advantage of CAPEX and OPEX savings opportunities associated with virtualization . It leverages their ever-

growing investment in data center compute, storage, and network infrastructure . With the technological advances cited previously, moving to

an NFV architectural model is within reach . However, service providers see a bigger impact from NFV1 on business and operational agility, time-

to-market for new services, operational efficiency, and investment risk — all of which are ways NFV can allow them to fundamentally alter their

business model for the better .

Figure 2 – Survey: What are the factors driving NFV Source: TM Forum, 2015

NFV Benefits

Service providers are keenly aware of the flexibility and agility virtualization gives them in establishing

a framework on which to automate the deployment of network functionality, speed-up the delivery of

new IP-based services, and accrue both CAPEX and OPEX savings .

CAPEX Savings Plus the Ability To Move Expenditures To OPEX

From a CAPEX perspective, a Service Providers can build out a data center using less expensive COTS hardware and virtualization technology

and use these to host the software-based network infrastructure components referred to as Virtualized Network Functions (VNFs) . A Service

Provider’s purchasing power allows them to tip the scale in their favor and deploy COTS hardware for implementing VNFs in their data centers

and central offices as opposed to deploying purpose-built hardware that performs the same tasks . When it comes to deploying applications

on bare metal COTS, Service Providers have a cost advantage over network infrastructure vendors in sourcing the underlying COTS hardware .

This advantage should encourage network infrastructure vendors to invest in development to port their network applications to software . This

development is not trivial, and those that have not been doing so may be at a disadvantage in the marketplace .

This concept of using a “hardware pool” to run the VNFs enables easier scalability and improves the business case for customers who want to

accelerate their NFV initiatives . Scalability is paramount and allows the carrier to reduce the number of servers to buy . Subsequently, the ability

to elastically scale reduces the need to have additional hardware capacity for the “worst” case usage scenarios since in virtualized computing

environments, a Service Provider can reassign hardware during a spike in demand . Additional cost to deploy functionality would only be required

for the VNF software in this model . Hardware could also be assigned to VNFs by capacity usage models by time of day, testing of new services,

etc . If the total workload of the COTS hardware is optimized in this way, then there would be fewer servers required, and in turn, this can help

reduce the power usage, and cooling and space requirements .

Additionally, running a service based on cloud principles moves a portion of the CAPEX expense to OPEX . Traditional fixed upfront hardware

costs associated with implementing and rolling out a new service can now be deferred in a virtualized deployment model, allowing the cost of

delivering a service to be better aligned with customer demand and uptake, as well as lowering the risk involved .

CAPEXReduction

OPEXReduction

New and Rapid Service Delivery

NFV Bene�ts

1 A 2015 TM Forum survey of service providers showed that reducing the time from concept to deployed new services and the ability to adapt to new business or market conditions were top of mind when it came to interest in NFV.

It’s about agilityand

velocityWhat’s Driving Interest in NFV:

52%business agility

42% servicevelocity

CAPEX and OPEX Reduction only 35% and 39% respectively!


6

White Paper

OPEX Savings from NFV

From an OPEX perspective, Service Providers can take advantage of the reduced operational costs to install and maintain a COTS infrastructure .

Training costs are reduced because there is less diversity from a network hardware perspective for the operations and engineering staff to

understand and manage . Another benefit of COTS deployment is lower costs and complexity of acquiring, storing, and managing spares .

Additionally, with the elastic nature of NFV, multiple applications can use the capacity of the underlying resources instead of a one-to-one

allocation like in the case of proprietary hardware and bare metal COTS . This opens up the possibility for smart reuse and pooling of the carrier

data center’s COTS hardware, as VNF needs increase or decrease .

Another OPEX benefit is that the Service Provider can determine where in the cloud to locate the VNF . For example, a Service Provider could

move the network function to a data center that is not necessarily physically located near the subscriber to better utilize pools of available

resources, which would make sense if the function is not time sensitive . On the other hand, it may make more sense to locate some functions, such

as those involving latency-sensitive media plane processing, in distributed data centers physically near the source of the traffic, and scale up more

resources closer to the subscriber, as the demand on the network requires . In this model, the Service Provider can place the network function at

more locations at the edge of the network or even on the customer premise if the service is for an enterprise .

The Ultimate Payoff - Accelerating Service Velocity and Increasing Flexibility Through NFV

Ultimately, software-based VNFs will enable deployment of new, innovative, revenue-generating services faster . Adding and testing a new

software-based service could shave months off the time required to roll it out, and significantly reduce upfront costs compared to traditional

methods that involve deploying network functions on purpose-built hardware . Developers can experiment with, and develop new network-based

applications because functionality can be provisioned and put on- and off-line on demand, rather than racking and stacking new hardware for this

purpose . Moving network functionality to software enables Service Providers to increase the rate and number of targeted services they can roll

out and reduce the cost of “getting it wrong .” In the past, if the business plan didn’t anticipate an uptake on a service, it resulted in a considerable

waste of upfront CAPEX and operational resources . With NFV, initial development for new applications and development enhancements to make

existing applications more appealing to customers can occur with less investment and fewer resources and result in a faster time-to-market .

In the traditional model where equipment vendors supply functionality through hardware-based platforms, upgrades to features and new

functionality in many cases are tied to an underlying hardware upgrade . In virtualized environments, the application is decoupled from the

underlying hardware . In an NFV scenario, features and functionality are added via software upgrades to the VNF . This allows Service Providers to

load, test, and use new features for commercial deployment on a virtual test platform eliminating the need to install a separate, stand-alone test

bed, and enabling a faster time to deployment .

NFV Architecture

Within an NFV service topology, in addition to the VNFs, the NFV also employs an underlying NFVI layer consisting of the virtual and physical

compute, storage, and network resources . There is a complementary management and orchestration layer (MANO) that is responsible for

• Chaining together VNFs and Physical Network Functions (PNFs) into a service;

• Coordinating the application of virtual and physical computing, storage, and networking resources to the applications;

• Managing the performance and capacity of VNFs and VNFCs; and

• Interworking with the Orchestration and Virtualized Infrastructure Manager (VIM) .

Management applications in the MANO layer are responsible for making sure VNFs come online, expand, or terminate, as the service requires .

The MANO layer also:

• Reserves and allocates hardware from the “hardware pool” on which the VNFs run;

• Enables multiple VNFs of the same function to run at the same time, and thus scale to demand;

• Performs policy decisions for use of the service


7

White Paper

Orchestration in the MANO layer helps automate service delivery with high reliability and scalability by:

• Automating configuration and provisioning of VNFs and/or service functions that may span one or more VNFs (e .g ., service chaining);

• Auto-scaling (scale-in/scale-out) the VNF resources;

• Resource reservation where needed per the service level agreements (SLAs) for a given service;

• Turn up/down of service functions or VNF instances (life-cycle management) as per the service SLAs; and

• Live migration of VNFs during maintenance (e .g ., data center server maintenance), etc .

The ETSI NFV Industry Specifications Group (ISG) has worked at defining the functional blocks of NFV and the interfaces between them, including

the VNFs, the OSS/BSS applications, VNF managers, the VIM, the NFVI, and NFV orchestration applications . In the group specifications ETSI is

developing, the VNFs and their associated element managers (EMs) will interface with the following:

• Corresponding VNF management applications

• Existing OSS/BSS platforms

• Underlying NFV Hardware Infrastructure (NFVI)

Figure 3 – ETSI NFV ISG architectural model

Dialogic Helps Service Providers Virtualize Their Applications

Dialogic has a rich history of software innovation and is reimagining how core network capabilities are deployed both in Service Provider networks

and in the solutions of application developers . Since the early 2000s, Dialogic has been actively moving digital signal processing (DSP)-based

solutions to software-based . Dialogic supported this movement even at the time when running thousands of channels of media processing

on a COTS platform was not even possible . Service Providers expect media applications that move from DSP-based platforms to software-

based platforms will perform at the same level . However, improving the performance of media functionality in virtualized environments to meet

operator expectations is not a trivial task . Dialogic saw the possibilities the future held, and embraced this move to software early on .

In the context of the NFV architecture, Dialogic’s solutions are primarily VNFs operating over a service provider’s NFVI . Dialogic’s virtualized

offerings include the following:

• Dialogic® PowerMedia™ XMS - media server, IMS Media Resource Function (MRF), and transcoding,

• Dialogic® PowerMedia™ Media Resource Broker (MRB),

• Dialogic® PowerVille™ Load Balancer (LB),

• Dialogic® BorderNet™ Virtualized SBC

We’re applying the same transformational approach to select Dialogic signaling solutions, and our roadmap includes plans to enable other

COTS-based solutions, such as our ControlSwitch™ System softswitch, to operate as a VNF . As a proof point, as of 2015, Dialogic has deployed

more than 3 million production ports globally of real-time, rich media processing via the PowerMedia™ XMS media server— all software-based

and running on COTS servers .

Virtual Network Functions (VNFs) NFV Management and Orchestration

NFV Infrastructure (NFVI)

Virtual Computing Virtual Storage Virtual Network

VNF VNF VNF VNF VNF

Virtualization Layer

Hardware resources

Computing

H d

Storage Network

VNF Manager

NFV Orchestration

Virtualized Infrastructure Manager


8

White Paper

Dialogic voice, video, host-based protocol stack binaries, and fax product lines support virtualization, and other Dialogic product lines are

also primarily software applications running on COTS-based hardware . This puts Dialogic customers in an advantageous position since the

applications are not extensively tethered to proprietary hardware platforms like some other vendors’ products .

Dialogic NFV Vision

Dialogic fully embraces the movement to NFV and sees specific guiding principles when it comes to NFV . In addition to being a participant on

the ETSI NFV ISG, Dialogic is also a member of the Open Platform for NFV (OPNFV) Project . We have started to build on the lessons learned from

public cloud implementations and integrate those concepts into our development of next generation products that will make them inherently

more cloud-based services . These principles include the following:

• NFV and SDN are inextricably linked and that the full set of NFV benefits comes from integrating functionality in the application layer that can

impact what is occurring in the packet forwarding plane

• VNF automation, scalability, and programmability are not “nice to have” concepts when moving to NFV, but should be “must have” goals

• Modularity of software is critical to optimize VNF application performance and scalability, and realize the full potential of a virtualized environment

• VNFs should be architected for flexibility to allow operators to accommodate technology advancements at the NFVI layer such as moving from

virtual machines to container technology

Dialogic also sees the importance of integrating open source APIs into its applications to leverage the body of work being done by organizations

like OPNFV that will help make implementing NFV easier, and VNFs more portable and readily deployed . Our aim is to help service providers

make NFV profitable for them by accelerating service velocity and innovation, and reducing the risk and cost of rolling out services .

Looking at current technology, the cost-to-performance comparison does not reflect the continuing advances in computing and server

virtualization technology . Computer performance is growing, and the impact of hypervisor overhead on application processing is lessening,

which makes running real-time multimedia applications in a virtual environment more attractive . In addition, most of the discussion of VNFs to

date has them running in virtual machines (VMs) . However, other approaches such as containers or unikernels will help expand options for Service

Providers, and can help improve scaling performance and NFVI utilization . The bottom line is that a technical challenge of today is not necessarily

considered a challenge for tomorrow . At Dialogic, we see the advantage that media plane processing and security acceleration technologies

from the COTS servers provide . However, we do not rely on hardware acceleration technology, such as DSP assist, as a requirement with our VNFs .

We held that belief 10 years ago and we are still resolute in our development to foster it today .

This movement of software-based network processing — what is now encompassed in NFV — has been an intrinsic part of Dialogic’s DNA and

is exemplified by the visionary developments in our applications and participation in public cloud POCs and industry organizations . Unlike other

vendors reliant on proprietary hardware-based solutions, Dialogic does not have to change overnight to support a software-based product

model . We already understand how to create and build cloud-based solutions, how to measure performance, how to scale solutions, and how to

provide the necessary services and support that go along with virtualized environments .

Focus on the VNFDialogic is primarily focused on developing solutions at the VNF layer . Our developmental roadmap includes VNF Manager Functionality and the adoption of open APIs to orchestrate the Dialogic VNF components as well as communicate to the service orchestration, the NFVI, and cloud orchestration components of the NFV .

Interoperability within the NFV ecosystem will be important, and Dialogic also plans to leverage third-party software wherever possible when deploying our VNFs . This is especially important with the MANO layer where open APIs will be used to access both third party VNF Managers, VIMs as well as orchestration functions .

Dialogic also believes that optimizing VNFs through NFV APIs and interfaces to take advantage of the underlying server capabilities such as Single Root I/O Virtualization (SR-IOV) will be critical, especially for media processing solutions . Accordingly, Dialogic plans to embrace these capabilities in our solutions .


9

White Paper

Phased Implementation to NFV

Service Providers are using a phased approach as a trajectory for smart NFV deployment in their operating environments and being selective on what they move to virtualized environments . The approach Dialogic has taken in rolling out NFV functionality is aligned with Service Provider NFV initiatives to help position them to reduce costs and better scale to support the delivery of targeted and individualized services to customers at a faster rate .

Phase I: move network functions to COTS hardwarePhase I is an important step that enables Service Providers to start migrating away from proprietary purpose-built platforms . Using proprietary hardware solutions results in having to expend engineering cycles to design and deploy their infrastructure and operational cycles to maintain and support those platforms — an overhead they don’t see as adding value to improving the customer experience . With increases in hardware performance, COTS servers are becoming well suited to support real-time, multimedia applications . Dialogic solutions are deployed on COTS hardware to help Service Providers cost-effectively deploy and scale solutions in their networks .

Phase II: port network functionality to virtualized environmentsEnabling network functionality to run efficiently in virtualized environments is critical . This allows network functions to take advantage of on-demand computing and the elasticity that virtualization brings to the table . While virtualization introduces additional overhead that impacts the overall performance of an application, the advances in hypervisor technology, application containers and techniques to accelerate media plane processing mean that NFV environments are becoming well-suited to support not only control plane intensive functions, but also data plane applications . Real-time, multimedia and collaborative services are delay-sensitive and put a heavy load on I/O and CPU resources . Packet scheduling performance improvements in the area of virtualization makes the cloud better suited to supporting these kinds of applications and gives service providers more confidence to migrate real-time multimedia services to a cloud infrastructure .

Extracting performance from software applications, especially ones that support real-time, always-on services, is an important requirement for next-generation VNFs . Dialogic excels at doing this in a way that rivals hardware-centric approaches used by other vendors . With our virtualized offerings, Dialogic is helping customers take advantage of the flexibility and elasticity virtualized computing environments have to offer .

Dialogic supports multiple hypervisors for its virtualized products, including VMware and KVM, and has implemented flexible software architecture to support other hypervisor technologies as required . In addition to porting applications to virtualized environments, Dialogic also provides virtualized instances of its EMS that are integrated within the VNF or run separately as another application in either the same or different virtual machine . Dialogic plans to optimize its VNFs through NFV APIs and interfaces to take advantage of underlying server capabilities such as SR-IOV, and also overcome hypervisor overhead issues . Dialogic also plans to test our VNFs with OpenStack and public cloud-based infrastructure environments such as Amazon .

Dialogic VNF EMS applications provide full fault, configuration, accounting, performance and security (FCAPS) management functionality for any given VNF . Part of Dialogic’s planned implementation of NFV functionality will be to enable the specific EM application to work either with the Dialogic VNF Manager or another supported third party VNF Manager when it requires information on NFVI resources .

Phase III: NFV orchestration and managementNFV is more than just porting monolithic applications to run in virtualized environments . Service Providers are taking lessons from the cloud for direction on tools and approaches for application automation and service chaining, and applying those techniques to virtualized infrastructure services . NFV orchestration and management is getting a lot of attention due to the important role both play in helping Service Providers realize many of the benefits of NFV . Among the benefits are the ability to

• Automatically spin up and spin down capacity and instances of virtualized applications;

• Allocate VNFs in virtual machines or containers on specific virtual and physical compute, storage, and network resources in various data centers as demand dictates; and

• Chain functionality together to make an end-to-end network service .

The ETSI NFV ISG MANO document specifies a framework of the various components of the orchestration and management layer, and describes the interfaces and associated operations within the MANO components as well as with the VNFs, and the NFVI . Along with the ability to port infrastructure applications with scalable performance to virtualized environments, there is work going on in parallel to identify a robust set of orchestration and management tools . With capabilities from the MANO layer, Service Providers can expand their integration of VNFs from


10

White Paper

outside of their current stable of network equipment manufacturers to include more nimble virtualized network infrastructure vendors to help them take advantage of benefits from deploying NFV .

MANO Components

There are multiple layers of VNF orchestration and management:

• NFV infrastructure management is provided by whatever infrastructure as a service (IaaS) is utilized by a carrier or enterprise and can leverage APIs provided by applications such as Amazon AWS, OpenStack, or the carrier’s own IaaS environment .

• Service orchestration performs the logical chaining of VNF elements via input from the applicable BSS/OSS platforms and the VNF Manager to provide an end-to-end service . Examples of such applications include Canonical’s JuJu, or IBM’s SmartCloud .

• Application management and interaction with the orchestration modules would be provided by the VNF manager . To manage the NFV applications, part of Dialogic’s approach is to include, along with EMS capabilities, a management application to support Dialogic VNFs . The Dialogic VNF manager would provide functionality for each VNF as applicable:

— Deployment of servers

— Server resource management

— Installation and management of Dialogic VNFs

— Implement and configure HA functionality

— Connections with IaaS/PaaS billing and access so that the applications can properly charge, authenticate, and so forth

Figure 4 – Dialogic’s VNF management architecture detailing applications being developed for NFV

Dialogic supports the notion of open interfaces, especially in the context of the NFV framework . For example, in the way information is exposed

from the Dialogic EM or VNFs to the applicable VNF manager . This information includes things like configuration and provisioning of routing

policies, exporting data records, alarms, and analytics . Some of this information is provided to OSS/BSS applications through the EMS or,

as applicable, to the orchestration layer through the VNF Manager . When it comes to interaction with the OSS/BSS and VNF management

applications, Dialogic VNFs offer several standards-based mechanisms . These include the following:

• Cloud APIs for integration with SDN

• SNMP

• SOAP/XML

• RESTful API

• Web-based bulk interface

• Secure mass data transfer protocols such as SFTP/SSH

• SIP, MSML, VoiceXML, JSR309, Network Announcements, RFC4117

NFV - MANO

NFVI

Virtual NetworkVirtual StorageVirtual Computing

VNF

EM


OSS/BSS

Hardware resources

NetworkComputing Storage

VNF Manager

VNF Catalog

Virtualized Infrastructure Manager

NFV Orchestration

Or-Vnfm

Or-Vi

Nf-Vi

Ve-Vnfm-em

Ve-Vnfm-vnf

Vi-Vnfm

Vn-Nf


11

White Paper

Phase IV: decomposition of VNF functionalityWhen you combine application virtualization with advanced orchestration through common VNF APIs, it is important to architect the software

in a modular fashion . Breaking down VNFs into smaller, more atomic component pieces opens up and exposes more functionality (for instance

to application developers), establishes a framework where operators can foster the creation of a wider range of innovative services, and enables

competition and a “best in breed” approach for the various functions required for an end-to-end service .

Figure 5 – Dialogic’s PowerMedia™ XMS MRF and MRB provides media processing functionality.

Porting a monolithic piece of software from a COTS or purpose-built appliance to a virtualized environment does not necessarily imply the

application has been optimized to take advantage of NFV benefits such as elasticity and deployment flexibility . Inefficiently designed VNFs can

lead to longer times to scale out instances, and responding to changes in capacity demand . For example, software that is not modular in nature

may need to have the entire instance scaled when confronted with bursty demand conditions, while a VNF that utilizes a modular architecture may

only need one VNF component or specific VNF template to scale, which results in faster instantiation . This architecture also lends itself to enabling

the ability to move the necessary functionality closer to the traffic sources and sinks, helping to reduce delay and improve user experience .

Dialogic has already embraced a modular approach to architecting solutions . Dialogic sees the potential for enabling Service Providers to

become even more agile with software-based, scalable, virtualized resource platforms that they and developers alike can use to build innovative

services . When Dialogic VNFs are broken down into smaller modules, these can potentially be used in different ways to create new services . For

example, Dialogic’s MRB and fax engines are instances of decomposition of the MRF VNF . Another example to consider is support for smaller

media transcoding VNFs that are only pertinent to a WebRTC application, or potentially to an audio and/or videoconference VNF .

Dialogic also anticipates other use cases for decomposed VNFs in other areas, including:

• Multiprotocol signaling interworking functions

• Diameter message enhancement with external subscriber, policy, or charging intelligence

• Wi-Fi interworking

• Softswitch routing policies

Dialogic continues to develop NFV functionality for service providers and application developers and is also evaluating models for further

decomposition of these modules . This decomposition is seen as a natural evolution of Dialogic’s VNFs given the current modular and distributed

architecture of Dialogic software .

Industry attention on this will continue as orchestration capabilities at the application level and VNF managers become better adept at managing

component VNFs and chaining them together to create new services or platforms for developers .

Composite Media Processing VNF

NFV Mgmt. & Orchestration (MANO)

Virtual networkVirtual storageVirtual computing


OSS/BSS

NetworkPhysical storagePhysical computing

Orchestration

Virtualized Infrastructure Manager (VIM)

VNF Manager

Media Resource VNFc Media Resource VNFc

MRB VNFcEMS VNF

Nova

Swift

Cinder

Heat

Neutron

Ironic

Keystroke

Glance

Media Resource VNFc

Catalog


12

White Paper

NFV and SDN Relationship

Software-defined networking (SDN) is an approach to network management created to provide greater control, programmability, automation

and optimization of networks, and routing between applications . The SDN objective is to utilize commercially available, high volume servers

and switches to enable dynamic network configuration for changing business needs or faster innovation . In SDN, the control of how packets are

forwarded is separated from the devices that do the actual switching and forwarding . This abstraction of the network control intelligence from

the packet delivery provides enhanced performance, reduced complexity, and improved centralized operational management of data centers .

SDN as defined by the Open Networking Foundation (ONF) relies on a well-defined common information model like that used in OpenFlow for

granular control of network traffic flows . The result is optimized use of commercially available hardware to deliver dynamic network capabilities

without specific management of individual network elements .

NFV and SDN are complementary concepts . An NFV-oriented architecture aligns closely with SDN objectives to utilize IT virtualization and

COTS servers to provide dynamic configuration of network services . Both concepts provide a similar benefit of protecting existing investments

while making the network more configurable and adaptable to future needs . However, service providers do not have to wait for SDN to start

implementing an NFV strategy . NFV helps position service providers to reduce CAPEX, OPEX, and power consumption; meanwhile, SDN

concepts create network abstractions to enable faster innovation in data centers . Similar to SDN principles of data packet routing, NFV can

use service chaining to optimize distribution of network services . This allows service providers to be able to rapidly create services with greater

control in automation and optimization .

As NFV progresses, Dialogic foresees benefits of SDN concepts and leveraging the applicable APIs as service provider networks continue to

evolve . The combination of SDN and NFV would replace expensive dedicated hardware appliances, move control software to a central location,

and align network and appliance evolution without the need for hardware upgrades . The APIs supported within SDN can be used for even greater

control over network routing, security, and bandwidth management for the services provided by the operator . Dialogic plans to continue to

actively explore and apply these techniques to the evolving NFV architecture and associated services .

Dialogic Service Provider Solutions

Dialogic offers an array of cloud-ready and COTs based applications for use by Service Providers and application developers . It includes:

• Media servers; media resource function (MRF)

– PowerMedia XMS is a media resource platform that service providers can use to deliver media rich services in IMS/VoLTE environments . It has

a proven track record of performance with millions of ports deployed globally . Application developers can use PowerMedia XMS to develop

new and innovative value-added services focused on Rich Communication Services (RCS) or over-the-top (OTT) applications, all using the latest

modern APIs .

• Media resource broker (MRB)

– PowerMedia XMS MRB brings cloud-based scale and performance to rich media handling in IMS/VoLTE architectures . Dialogic co-wrote the

IETF MRB specification and implemented capabilities that include media server load balancing, media resource pooling and consolidation

among application servers, and automated resiliency of MRF resources to ensure high availability . PowerMedia XMS MRB can be part of the

MRF or application server, and it can be deployed as a standalone VNF in a VoLTE/IMS architecture .

• Load Balancer (LB)

– The PowerVille Load Balancer is a software-based high-performance, cloud-ready, purpose built and fully optimized network traffic load-

balancer uniquely designed to meet challenges for today’s demanding real-time communication infrastructure in both carrier and enterprise

applications . The software-based PowerVille LB allows application developers, service providers and enterprises to dynamically scale, distribute

and manage traffic associated with a diverse set of real-time and non-real-time applications deployed in today’s networks across disparate

applications and datacenters .

• Media transcoding

– PowerMedia XMS supports the latest audio and video codecs, including Opus, iLBC and HD Voice codecs such as AMR-WB, and video codecs

such as H .264 and VP8 . PowerMedia XMS transcoding resources are software-based and can be invoked via SIP using standard transcoding

control models .


13

White Paper

• Signaling Gateway and Message Router

– The advanced message routing capabilities of the Dialogic Signaling Interface Unit (SIU) provide an expanded set of signaling interworking and

gateway features . The versatile host based protocol stack binaries utilized by the SIU – which are already deployable in virtualized environments

- enable it to be used in dedicated applications such as a Gateway Signal Transfer Point (STP) and SMS/SCCP router, or in conjunction with

application servers to offload the signaling processing heavy lifting to improve performance .

• Session border controller (SBC)

– Dialogic rolled out its BorderNet Virtualized Session Border Controller in July 2013 . The virtualized SBC shares the same code base as its

hardware appliance-based counterpart providing the same flexibility, carrier class-features and ease-of-use for virtualized environments .

• Class 4 Switching/IMS media gateway control function (MGCF) platforms

– Dialogic has been a market leader in softswitch solutions for service providers for years, and continues to support service provider initiatives that

help ease the transition from legacy end-of-life switching platforms to IMS/VoLTE . Dialogic’s ControlSwitch™ System softswitch currently runs

on COTS hardware and plans include making the solution cloud-ready . The ControlSwitch System’s advanced modular software architecture

lends itself well to migration to virtualized environments, and already consists of a decomposed architecture that separates core functionality

into separate modules providing unmatched scalability and reliability, and ready to take advantage of the benefits of virtualized environments .

• Fax Over IP (FoIP)

– Dialogic® Brooktrout® SR140 is the software-based fax engine market share leader instrumental in moving fax from the TDM realm to the IP

realm . It supports the IP-based fax protocols with the fax interoperability of Dialogic’s Brooktrout® hardware-based fax products .

Figure 6 – Dialogic’s infrastructure solutions are architected to work in virtualized environments. This diagram indicates the applications that are currently deployable in virtualized environments, as well as those applications targeted for NFV.

Conclusions

Dialogic fully embraces the benefits of a software-centric approach that is inherent with NFV and SDN . While Dialogic plans to continue to

support and drive our traditional hardware-based deployments for those customers that desire such an approach, we also plan to focus on

building upon the strides in software-centric and virtualized applications that we’ve been making for already more than a decade . The benefits

to CAPEX, OPEX, service deployment, and speed-of-innovation are there for service providers utilizing NFV, including benefits in reduced

equipment diversity, dynamic reuse of the hardware, speed-to-market and targeted service introduction . However, Dialogic also sees benefits

for our developer community in creating new innovative services, including:

• Decreased risk

• The ability to address a larger market

• Decreased cost of deployment

• The ability to start small and scale massively as the demand requires

NFV - MANO

Vn-Nf

Dialogic VNF Dialogic VNFDialogic VNF Dialogic VNF

NFVI Virtual Computing Virtual Storage Virtual Network

SBC

g

MRF

Dialogic VNF

Fax

Dialogic VNF

Media Transcoding

Signaling Server/Gateway

Softswitch / MGCF

Dialogic VNF

LoadBalancer


OSS/BSS

Hardwareresources

Computing Storage Network

VNF Manager

NFV Orchestration

Virtualized Infrastructure

Manager

Ve-Vnfm-em

Ve-Vnfm-vnf

Or-Vnfm

Vi-Vnfm

Or-Vi

SOAP/XMLREST APIs

Current VNF

Vn-Nf Vn-Nf

Roadmap VNF

Vn-Nf Vn-Nf Vn-Nf Vn-Nf

NF-Vi

MRF

MRB


14

White Paper

These benefits should make a compelling recipe for success for developers who want to move to a cloud-based model .

Dialogic believes service providers should be cognizant of demands that media plane and signaling plane processing make on a virtualized

environment; however, that should not deter them from migrating service delivery functionality to the cloud . There may be implementation

changes necessary, such as distributing functionality among multiple data centers closer to the sources and sinks of traffic; but a distributed

approach can lead to a more robust, on-demand architecture as opposed to a centralized service delivery approach .

NFV, and particularly virtualization and orchestration, encourages and enables operators to look outside of their normal circle of legacy hardware-

centric vendors and to start integrating innovation from new cloud or software solution providers . The barriers to entry and the risk involved for

rolling out new services can be markedly reduced with an NFV approach . Dialogic has been innovating with software for a long time . It is in our

DNA, and we can help you move your NFV vision forward .

www.dialogic.com

For a list of Dialogic locations and offices, please visit: https://www .dialogic .com/contact .aspx

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH PRODUCTS OF DIALOGIC CORPORATION AND ITS AFFILIATES OR SUBSIDIARIES (“DIALOGIC”) . NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT . EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY .

Dialogic products are not intended for use in certain safety-affecting situations . Please see http://www .dialogic .com/company/terms-of-use .aspx for more details .

Dialogic may make changes to specifications, product descriptions, and plans at any time, without notice .

Dialogic is a registered trademark of Dialogic Corporation and its affiliates or subsidiaries . Dialogic’s trademarks may be used publicly only with permission from Dialogic . Such permission may only be granted by Dialogic’s legal department at 6700 de la Cote-de-Liesse Road, Suite 100, Borough of Saint-Laurent, Montreal, Quebec, Canada H4T 2B5 . Any authorized use of Dialogic’s trademarks will be subject to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement .

The names of actual companies and products mentioned herein are the trademarks of their respective owners . Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to implement their concepts or applications, which licenses may vary from country to country .

Any use case(s) shown and/or described herein represent one or more examples of the various ways, scenarios or environments in which Dialogic® products can be used . Such use case(s) are non-limiting and do not represent recommendations of Dialogic as to whether or how to use Dialogic products .

Copyright © 2016 Dialogic Corporation . All rights reserved . 02/16 14062-05

dialogic cloud-ready solutions: a smart approach to … · dialogic cloud-ready solutions: a smart...

Documents