E-guide

NFV Basics: Implementation, Challenges and Benefits

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

In this e-guide: Network functions virtualization (NFV) allows service providers and operators to abstract network services, such as firewalling and load balancing, into software that runs on basic servers.

For operators and service providers, the holy grail of an NFV implementation is the ability to dynamically provision network components, services and applications in a matter of minutes rather than the weeks or months it takes to do so now.

Mobile operators and service providers are embracing NFV more quickly than anyone had expected, and experts are betting that the new technology will eventually make its way into the enterprise. However, business and technical challenges still loom in NFV.

In this Essential Guide, we explore NFV implementation basics and the potential benefits. We also break down current issues with NFV, as well as vendor approaches to the new technology.

Page 1 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Section 1: The ins and outs of NFV NFV: How does it work?

NFV virtualizes network services and applications that once ran on hardware appliances. In fact, network functions virtualization could replace many network devices with more flexible software running on bare metal servers, enabling a new kind of service chaining. Learn the basics of how NFV works, and how it could make its way into the enterprise.

Page 2 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

What do we need from NFV orchestration?

Tom Nolle, President

Orchestration in network functions virtualization (NFV) is so critical that ETSI's NFV specification group has coined the term "MANO" for management and orchestration, and now the phrase has entered the networking lexicon.

Yet for all the work to develop "MANO," there's a surprising lack of consistency in how "orchestration" is defined by vendors. What's more, there's a major disconnect between the formal notion of orchestration for NFV and what operators actually need to meet their virtualization goals. That disconnect must be addressed or it will threaten NFV deployment.

What network operators need from NFV orchestration The term orchestration in IT networking describes the process of automating the deployment and connection of multiple IT/network elements or software components. In that context, orchestration creates a kind of recipe for a service or application that, when followed, creates and sustains the expected experience for users.

Page 3 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

That can quicken the pace of deployment and reduce operating costs, both of which increase return on infrastructure and profits.

Now orchestration must match the same goals for NFV in operator networks. While capital expense management was initially the driving force behind NFV, operators have now evolved to focusing on improvements in service agility and velocity, as well as control of opex.

The problem this poses for NFV is that the ETSI Industry Specification Groups (ISG) work is focused on the hosting of virtual functions, which in most cases makes up only a small part of service insertion. A business VPN with a thousand sites might consume a few instances of a virtual firewall, for example, but will have much larger needs when it comes to enabling automated service insertion.

It is this shift in goals that has created a disconnect between what standards groups say about NFV orchestration and what operators need. Resolving this can come only from somehow taking orchestration and management to a higher level.

Are NFV managers the answer? NFV includes the concept of "infrastructure" or "virtual function" managers who link the orchestration and management functions to hardware of many types. These managers or handlers may also be responsible for orchestrating a combination of NFV and non-NFV service elements.

Page 4 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

All that's needed is a manager that takes into consideration every infrastructure element that must be controlled, and a model that represents the role of each of these elements in a service. In this situation, the NFV orchestration must either be able to control every element in the network, or it must be capable of subordinating to a higher-level orchestration strategy for end-to-end service control.

Why we need open-standards NFV orchestration If not properly directed, this kind of orchestration expansion could generate multiple and incompatible proprietary solutions as vendors struggle to protect sales and differentiate their own approaches.

The risk of "walled-garden NFV" and orchestration has led many operators to seek open standards and even open-source software. As all of this takes shape, a more standardized approach to expanding NFV orchestration is needed. That appears to require two things --an open approach to service modeling and an open mechanism for managing services built from legacy or NFV-supported features.

Taken alone, NFV orchestration could be handled using something like the OpenStack Nova/Neutron APIs. The challenge is in modeling complex services that aren't fully based on cloud-hosted components, and for that there are no specific standards evolving. The most promising approach is the Topology and Orchestration Specification for Cloud Services (TOSCA), which is under development in the open standards development organization OASIS.

Page 5 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

As the name suggests, this is also intended as a cloud specification, but TOSCA models appear to be flexible enough to describe the kind of complex services that would contain NFV elements.

NFV orchestration must be paired with service management To make the most of automated orchestration, this should be linked with service and element management in some way. Complex services, particularly those like NFV that host elements on virtual resources, require the virtual device the user sees be a construct of orchestration. Those virtual devices must be represented by a parallel construct of a management view. A virtual branch access device might be a firewall, NAT, DNS and DHCP component, each hosted on a virtual machine and connected via SDN. While the user shouldn't be able to distinguish between the elements, the network operations center has to be able to decompose the virtual device into its real components to solve problems.

One logical way to do this is to apply some of the principles of the IETF's Infrastructure to Application Exposure (i2aex) specification, which collects and centralizes all "real" management data into a repository and delivers derived management views.

Applications can then either directly query the repository (using SQL, for example) or use an SNMP or management "proxy" that will expose repository variables through an appropriate management interface standard.

Page 6 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

This approach also limits the risk of many virtual functions overwhelming shared devices with management requests, or having those functions make changes to shared resources that would impact other users. NFV orchestration must include secure multi-tenant management.

Ultimately, management and orchestration of NFV must be more than managing and arranging the new hosted-function model that NFV has created. The model has to be able to handle the entire service, end to end, or provider goals for improving service velocity/agility and operational efficiency cannot be met.

Do NFV orchestration tools exist? To date, operators say that only a small number of vendors have even indicated such an approach is on their roadmap. Alcatel-Lucent, Cisco and HP claim they have a full solution, but none are yet offered in full form, according to research surveys that I've conducted.

Without a management/orchestration model that meets their goals, NFV buyers may realize that NFV deployments are likely to under-realize their full potential. This may leave operators scrambling to address their service agility and operations issues in some other way.

Next article

Page 7 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Network functions virtualization primer: Software devices take over

David Jacobs

Network functions virtualization (NFV) allows engineers to replace traditional network devices with software that lives on commodity servers. This software performs the network functions previously provided by dedicated hardware.

This combination of server and software can replace a wide range of network devices, from switches and routers to firewalls and VPN gateways. These new software devices may run on physical servers, virtual machines controlled by hypervisors or a combination of the two.

NFV was initiated by a group of network service providers, including ATT, BT, Deutsche Telecom and Verizon, and was first presented at the SDN and OpenFlow World Congress in October 2012. The technology takes advantage of developments in virtualization technology and hardware optimizations built into the latest generation of processor chips and network interfaces to reduce or eliminate the need for traditional, dedicated network devices.

Page 8 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

While software-based routers and switches have been available for many years, moving network functions to servers in high throughput networks was not possible with previous generations of processors and network interfaces. For example, a PC loaded with router software was limited by the fact that all packet processing was performed in the machine's CPU, with no hardware assist built into the interface card or onto the PC motherboard.

Now, processors and network adapters provide greatly increased throughput and processing capability because they've been optimized to support virtualization. Newer processors contain multiple cores to spread the load across multiple virtual machines (VMs) and applications. Additionally, adapters include hardware features that support multiple 10 GbE interfaces, while offloading tasks previously done on the processor. Per core packet queues and adapters in virtual networks support offload functions from the virtual switch. Meanwhile, network controller chips include support for features, including link-level encryption, IPsec, TCP packet partitioning and checksum calculation.

NFV reduces costs and improves resource usage Carriers and service providers began working on NFV to better use resources in complicated networks in order to reduce cost and complexity. Though carriers and service providers have led NFV efforts, the technology helps any enterprise with a vast network and a wide diversity of functions.

Page 9 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Very large networks have massive inventory of different device types, including PE or CE routers, firewalls, session border controllers, VPN gateways and a variety of other device types. These devices are constantly being developed and acquired, so equipment rapidly becomes obsolete and must be replaced. What's more, lots of this equipment spends plenty of time unused. For example, if a small network change requires fewer firewalls but more VPN gateways, these already purchased firewalls would lay idle. With network functions virtualization, a server that is a firewall today can be a VPN gateway tomorrow with just a shift in software.

Network functions virtualization for flexibility in hardware … and ideas NFV's ability to spin up an additional virtual server or update the software on a physical server reduces the need to move devices from rack to rack, move cables and recompute power and cooling requirements when the network grows or is reconfigured. This decreases the possibility of network downtime that generally exists when changes are made in a traditional network.

Finally, relying on software for network functions opens the door to a new level of input and innovation by software developers or third parties as opposed to depending on innovation from traditional hardware vendors that can be slow moving.

Page 10 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

New concepts in network software can come from the open software community, from academia or from minimally funded startups. Newly developed software can be quickly evaluated since testing does not require waiting for the next network vendor software update.

NFV and SDN: Complementary, but not the same Software defined networking (SDN) is not a requirement for NFV, but the two technologies are complementary.

Engineers can implement NFV, choosing to rely on traditional networking algorithms such as spanning tree or IGRP instead of moving to an SDN architecture.

Yet SDN can improve performance and simplify operations in a network functions virtualization environment.

With SDN engineers decouple the control plane from the physical network, monitoring and directing the entire network from a centralized controller. This controller functions on a server and generates directives to each data plane device. While SDN was originally conceived to control the operation of network hardware devices, it can just as easily integrate into an NFV environment, communicating with software-based components on commodity servers. What's more, these servers and software can be designed to be OpenFlow-friendly, unlike many existing hardware switches.

Page 11 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Challenges in network functions virtualization are plentiful Multiple challenges must be resolved for the NFV concept to be widely adopted:

1. A standardized interface must be developed between virtual appliances and the underlying hardware and hypervisor to make appliances portable across different operators' or enterprise networks.

2. Testing is still required to determine the performance penalty that occurs due to replacing specialized devices with commodity servers. (The penalty can be minimized by choosing appropriate software, according to the proposal's authors.)

3. A migration path must be developed to enable NFV implementations to coexist with existing management infrastructure and with legacy network equipment.

4. A standard set of management interfaces must be developed to provide a consistent view across NFV components and remaining hardware-based network components.

5. Automation services must be developed for NFV implementations to scale.

6. Security, network resiliency and stability cannot be compromised by the transition to NFV. New security strategies may need to be developed to work in an NFV environment.

Page 12 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

7. Network operations must be simplified. Today's network complexity is because of multiple devices and management methods developed over past generations. NFV must provide simpler, more uniform management.

8. Network operators must be able to integrate any vendor's server hardware, hypervisor, and any appliance.

As for the future of NFV, several industry initiatives are underway. An Industry Specification Group (ISG) has been formed within the auspices of the European Telecommunications Standards Institute (ETSI) to address existing challenges. Several computer and network equipment vendors have joined with the service providers to advance this initiative. Plans also call for working closely with the Open Networking Foundation as it continues to accelerate the adoption of SDN technologies and standards.

Next article

Page 13 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Will network functions virtualization be used in the enterprise?

Jason Edelman, Principal Solutions Architect

Jason Edelman explains whether or not network functions virtualization will ever transition into the enterprise, or if it is a service/provider play.

Will network functions virtualization be used in enterprises, or is it just an operator/service provider play?

Network functions virtualization (NFV) will no doubt be used in the enterprise, although it’s gaining traction in the service provider space. NFV offers a wide range of benefits, even for the enterprises that include reduced CapEx, linear scale/pricing, smaller fault domains. In addition, it makes applications -- along with their associated policies -- more portable.

A side effect of all of this is an inherently better business continuity plan. However, NFV for the enterprise will take time. This will require IT teams to become more comfortable embracing software-centric L4-7 services, as well as changes in operational models. An understanding of how to optimize performance with DPDKs, and potentially even looking at programmable hardware, will be needed as well.

Another challenge is the time and process it takes to re-architect monolithic services appliances that were predominantly deployed for north-south

Page 14 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

traffic. This could be done in a way where there may be many more appliances, but each supporting smaller workloads and be optimized for east/west traffic.

Next article

Page 15 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Section 2: NFV roadblocks Challenges and issues with NFV

It's clear what NFV can offer in terms of benefits, but challenges also exist. Some network experts argue a new network management model is needed for NFV and its implied orchestration. Operators will also face issues with NFV implementation, as well as with finding funding for the new technology.

Page 16 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Network Functions Virtualization demands new network management models

Tom Nolle, President

When a cadre of giant global network operators started the initiative known as Network Functions Virtualization (NFV) in late 2012, their stated goal was to leverage virtualization technology to consolidate network equipment types onto industry-standard servers, switches and storage.

Clearly this was aimed at reducing the capital cost of purpose-built network equipment. But only a year later, the focus widened. These same operators believed the benefit of NFV would lie in improving the efficiency of operations, even enabling service agility.

That was a profound shift that meant NFV's success would depend on its operational effectiveness and this would require a shift in network management model away from one that is device-driven and toward one that would take into account orchestration across both legacy network components and virtual resources.

Page 17 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Why virtual network functions can't be managed as traditional network devices The challenge for NFV is that a new operations model must provide efficiency across an entire service. This means management models must reach beyond hosting virtual functions on servers as specific devices.

What the ETSI NFV Industry Specification Group (ISG) process appears to aim for is the creation of a network management model for NFV that "plugs into" current network management system and OSS/BSS systems by offering element management interfaces to NFV processes and elements.

In effect, this means that a virtual network function, or a complex of such functions that emulates the behavior of a physical appliance (like a firewall), would be a virtual form of that physical device and be managed in the same way.

While this approach would address the stated goal of exploiting virtualization, it also suggests that overall service deployment and management practices would change little as NFV is deployed. That makes it difficult to secure major changes in operating efficiency or service agility.

Page 18 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

How to change the network management model for NFV There are two ways this could change -- one by creating a smarter higher layer above NFV, and the other by making an NFV virtual device into something very different from the real device on which it was based.

The connections between virtual network functions inside an NFV virtual device could already involve legacy network components and certainly would involve multiple virtual function components, virtual machines or containers for hosting, etc. That means that every NFV virtual device is really a system of cooperating elements whose collective functionality has to be reflected through the management information base that represents the virtual device to any management system or OSS/BSS element.

If the scope of a virtual device is very small -- limited to emulating a single real appliance -- then current systems and practices would change little when NFV is deployed. If, however, the virtual device was expanded to include more legacy network components, it's possible to visualize an NFV "device" that represents a complete end-to-end service, including both virtual and legacy elements. In that case, how NFV services were deployed and managed inside the virtual device boundary would determine how agile and operationally efficient the service was.

Page 19 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

The problem with this approach is that we already have NMS, OSS, and BSS systems for legacy networks and for the legacy components of future networks. If NFV defines an umbrella operations model, how does that model embrace service components that have no NFV components?

A network management model for integrated NFV An alternate approach preserves these past practices by creating a new operations model that sits above the ETSI NFV processes. This model would define services as a collection of virtual elements some of which might be implemented through NFV processes and some through normal legacy-network provisioning and management. Efficiencies in service agility and operations efficiency would be created by this new operations model and could be applied even to services with no NFV components at all.

It should be clear that what's being considered here is less what needs to be done operationally than where the new operations model would reside. What's being described in either the "inside" or "on-top-of-NFV" situations is a two-level process of orchestration and management that contrasts with the single-level practices that dominate today. The NFV operations model consists of a functional layer where logical components of services are assembled into retail offerings regardless of how they are implemented, and a second structural layer where the logical components are actually deployed by committing network, software and server resources.

Page 20 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

This model fits both the evolving NFV specifications and cloud computing's own notion of "DevOps" provisioning quite well, since both could fit in the structural layer. However, there are no functional-layer models currently accepted, and many would argue that none are under consideration. Two issues deter such a model: jurisdiction and management.

Who is responsible for building a management model beyond OSS/BSS? Something that lies between OSS/BSS systems and networks could logically be called either an extension to OSS/BSS or an extension to the network.

The TM Forum (TMF) is the accepted OSS/BSS standards group and so would be a logical candidate to pursue functional management models. The problem is that functional operations models look a lot like building service logic and the TMF is a management body.

On the network side, there's no shortage of possible sources for a model, ranging from the NFV ISG and cloud groups like OpenStack, to the IETF, the International Telecommunications Union, 3GPP and even the Open Networking Foundation. A network-side operations model might end up being five such models, which would then demand a higher-level model to accommodate them all.

Page 21 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

The most likely paths to a resolution of NFV's operations challenges are the TMF at the OSS/BSS level or a union of the NFV ISG and the ONF on the network side. Those two bodies have already agreed on cooperating, but the focus of their cooperation is well below the functional level and it leaves management out of the picture completely.

Next article

Page 22 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Overcoming network functions virtualization implementation challenges

Tom Nolle, CIMI Corporation

Network functions virtualization (NFV) technology aims to host network functions on standardized servers rather than custom devices. While vendors and carrier network operators are eager to launch trials, the European Telecommunications Standards Institute (ETSI) specification process is scheduled to run until January 2015, so early NFV implementation will have to be based on broader principles that will have to be adopted as more details emerge.

To achieve NFV implementation in the shorter term, vendors will have to make four key decisions: on implementing a cloud-hosted model, choosing network-optimized platforms, structuring services and resources based on TM Forum principles to facilitate operations integration, and adopting an agile and loosely coupled data/process architecture.

Finding common management framework for NFV: Go OpenStack? In theory, NFV could be hosted on anything from dedicated physical servers to virtual servers in the cloud.

Page 23 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

But in practice, accommodating that wide a range of implementation choices is difficult without a consistent management framework that covers all the options.

The answer to that problem may be in placing virtual functions in the cloud and using OpenStack as the cloud software platform. OpenStack has wide industry support, and it has a network-as-a-service framework. Neutron (formerly called Quantum) has plug-ins that support most of the popular SDN technologies and even some proprietary network management systems (NMSs). However, Neutron is evolving to meet cloud computing needs rather than the broader needs of network operators, and it's likely that early implementations of NFV will have to extend Neutron for carrier networks to cover things like traditional point-to-point connections that don't exist in the cloud. In this case, Neutron would have to be augmented by developers -- or bypassed for the models it doesn't support.

Optimizing commercial servers for NFV implementation The success of NFV and hosting virtual functions will hinge on whether these functions can be made available and perform as needed.

The expressed goal of the ETSI NFV Industry Specification Group (ISG) is to do this on commercial servers, but these will have to be network-optimized through both hardware and software. This optimization is particularly necessary in the case of the data-path connection from network interfaces

Page 24 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

to virtual machines. After all, network devices vary depending on the traffic they're expected to handle and the reliability they're expected to deliver. The same scenario holds true for NFV hosts -- so the same optimization will be necessary.

Finding an NFV management model: Look to the TM Forum The third issue in implementing NFV is the management process. This has to be based on a data model to describe services and resources. Even before NFV came along, the TM Forum (TMF) provided a suitable, perhaps even ideal, data model, (SID) GB922. While it's likely this model will have to be extended to support virtual functions and cloud resources, the extensions are minimal, and GB922 offers a rich model for describing both services that include virtual functions and the resources on which those functions are hosted.

The TMF model greatly facilitates the structuring and management of both resources and services, and NFV's own virtual-function management conception will likely be fit into the larger TMF model in any case.

In addition, the TMF model can be easily adapted to represent not only services newly composed from virtual functions, but also services provisioned traditionally, and even those a partner supplies.

Page 25 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

By having a common architecture to represent all kinds of services, the model allows operators to manage the transition to NFV when many traditional network devices will remain in use.

NFV implementation demands untraditional data models Management integration and service modeling are only examples of the largest and final NFV implementation decision, the data model. NFV touches the existing network OSS/BSS, as well as NMSs, the cloud management systems and the management of virtual functions themselves. It will have to accommodate all of the devices used to host NFV and all the surrounding network equipment.

Virtualization, machine images of virtual functions, virtual-network SDN connectivity and traffic patterns will all have to be considered in identifying the best places to host functions and the best ways of connecting them. The optimization task is significant, but the real challenge is simply expressing the policies to guide deployment and accumulating the management data needed. For that, NFV implementation demands thinking outside the box of traditional data models.

Modern data-driven process models separate data storage from data/information models, and they use a semantic layer to describe interpretation and relationships.

Page 26 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

These can easily accommodate collector interfaces to gather telemetry from devices and functions, as well as distribution interfaces to visualize the data in the form a management system needs. The IETF has already proposed using a data repository to accumulate resource information for distribution to virtual functions or management processes in its Infrastructure to Application Exposure (i2aex) architecture. This semantic modeling approach also makes it easy to adapt a prestandard implementation to interfaces yet to be specified by the NFV ISG.

In NFV implementation, do we need off-the-shelf cloud apps? Beyond these basic implementation points, there's also the basic question of where virtual functions actually come from.

If virtual functions have to be custom-developed to run in an NFV implementation, there could be a potential delay in function availability. After all, developers have to commit to the new environment, which could result in multiple platforms with different requirement sets. The ability to host any cloud-ready application or network component in NFV would solve the function availability problem, but off-the-shelf cloud application or network feature components couldn't take advantage of any special management, availability or performance tools that might be built into the NFV specification. The right answer is likely to support both off-the-shelf apps and customized apps with NFV-optimized behavior. The market can then choose what's most important.

Page 27 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

There will almost certainly be many NFV implementations before specifications emerge. In fact, the ISG's work isn't intended to describe or limit the implementation process and vendors, and NFV users will place different values on different features and capabilities. As the implementations roll out, we'll get our first concrete look at what NFV can do, and from that we'll be able to tell just how much of a revolution it will be.

Next article

Page 28 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

NFV applications emerge from ISVs, but challenges loom

Lee Doyle, Principal Analyst

The ISV community has the potential to drive network functions virtualization (NFV) adoption, bringing IT's dynamic innovation to the staid telecom environment. But with limited resources, it'll be a challenge to build sales channels and create market awareness for NFV applications.

Who are the NFV ISVs? The NFV ISV community comprises a group of approximately 50 companies ranging from startups to established software suppliers. The category excludes leading network equipment suppliers (e.g., Cisco, Ericsson and Huawei, which derive the vast majority of their product revenue from equipment), as well as leading IT suppliers, such as HP, IBM, Dell and Oracle.

Wide breadth of NFV applications The NFV ISV community provides applications that span a wide range of the providers in the telecom infrastructure landscape, including:

Page 29 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

• Routing and broadband remote access server, or BRAS -- e.g., Brocade and Adara

• Virtual CPE (home and business) -- e.g., Active Broadband and Netsocket

• Orchestration, management and monitoring -- e.g., Overture and Nakina

• Evolved packet core (mobile core) -- e.g., Affirmed and Connectem • Deep packet inspection, or DPI -- e.g., Saisei and Procera • IMS or VoIP -- e.g., Mavenir and Metaswitch • Session Border Control, or SBC -- e.g., Edgewater • SDN -- e.g., Pica8, Big Switch, Cumulus • Security -- e.g., Catbird and vAmour • WAN optimization -- e.g., Vello Cloud, SilverPeak, Viptela and Pertino • Application Delivery Control (ADC) -- e.g., Embrane

These applications are delivered as Virtual Network Functions, or VNFs -- often as part of a broader NFV solution.

Challenges for NFV ISVs NFV ISVs face a number of vexing challenges as they bring their products to market. The first challenge, of course, is to develop an innovative, virtualized product that meets the reliability and scalability requirements of the telecom industry. In addition to the technical challenges, ISVs also must develop a succinct value proposition (elevator pitch) directed at large telcos, explaining why they should introduce a new, unproven product into their highly complex network operations.

Page 30 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

In a recent survey of 40 NFV ISVs, Doyle Research found their top challenges include:

• Creating market awareness • Building effective sales channels • Ability to scale with qualified people • Finding the financial resources to invest in long-term growth

A marketing message that can be heard in a sea of hype The surge in interest in NFV by the tier one telecom service providers has led to a rapid increase in the number and volume of marketing messages around NFV products and solutions. The challenge for NFV ISVs is to break out of the market noise and make potential customers aware of their unique solutions. These efforts are often hampered by limited marketing resources and people as the ISVs focus their resources on technical efforts.

NFV channels tackle lengthy sales cycles NFV is a complex and highly technical sale to network operators. The sales cycle can be one or two years long, especially if it involves starting in the labs, moving to proofs of concept and then to limited deployments. NFV ISVs generally hire a few direct sales folks to develop "lighthouse" accounts, but must rely on partners and the channel to sell to a broader audience.

Page 31 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

A number of large IT and network suppliers, including Intel, Alcatel-Lucent and HP, have created their own ISV ecosystems designed to help smaller ISVs get their products to market.

How to handle the challenge of a small staff Most NFV ISVs have limited technical and support resources, sometimes with only a few dozen people on staff. For those lucky enough to land a tier one customer (or two), those resources can easily be consumed during a six-month trial or proof-of-concept engagement. NFV ISVs need partners to help them scale their technical integration and global support resources.

Finding the financial resources to push through trial periods The investment community remains strongly supportive of NFV and SDN startups. The challenge for NFV ISVs is to maintain the required financial resources for long enough to sustain them through a period of limited revenue as customers trial their products (generally for free). The NFV market is quite small now but is expected to grow strongly during 2015 and 2016 as customers move to limited, then broader production deployment.

Page 32 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Conclusions ISVs are critical in delivering NFV technology to the traditionally slow-moving telecom industry. A large number of network software suppliers are delivering initial NFV applications across a wide variety of use cases. In addition to developing technically excellent products, these ISVs will need to clearly articulate the use case and benefits of their products, attract the right sales partners, and work to scale their technical resources as they gain new customers. The development of the NFV market will be relatively slow in the near term, and investors and IT partners will need to take a long-term view to nurture the tremendous value of this community.

Next article

Page 33 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

SDN and NFV will come to life in the operator network, eventually

Rivka Little, NICE Actimize

SANTA CLARA, Calif. -- The Open Networking Summit 2014 this week could have been called "The NFV Show."

Telecom operators took the stage, one after the other, detailing plans to migrate away from "brittle" or inflexible legacy networks by implementing a combination of network functions virtualization (NFV) and SDN. Yet, details on the software or hardware tools needed to make this transition are still in short supply.

AT&T, NTT, Telefonica and Telecom Italia were among the operators that spoke at the Open Networking Summit. Each will use varying strategies to virtualize key network functions, placing them on commodity servers and then connecting them through a flexible SDN infrastructure that is all managed through a unified orchestration system.

The goal is to provision virtual services and applications in minutes instead of the months it takes on legacy networks. This will make it more cost-efficient to run and scale networks, since operators will be able to provision and de-provision bandwidth on demand based on actual user need. Also, this kind of granular network function control will eventually let operators offer optimized, customized content on demand.

Page 34 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

If customers can pay more, they can get better service. That means NFV and SDN could be linked to revenue generation in addition to network efficiency.

But that kind of total network transformation is a long way off.

"This is five to eight years out," said Forrester Research principal analyst Andre Kindness. Operators will face challenges in finding tools that let them equally manage virtual and physical resources through a common interface, he said.

Telecom operators have extremely complex Operation Support Systems and Business Support Systems (OSS/BSS) that manage every function, from business issues like billing, to performance elements, such as quality of service, and performance of logical and physical resources. As networks have become more complex and multi-layered, OSS/BSS has become complicated and even behemoth.

"OSS/BSS is their biggest challenge. These systems will have to tie into this [new] orchestration infrastructure," said IDC research manager Nav Chander. "They will [eventually have to] get rid of legacy OSS and consolidate networks" to make them programmable enough to make dynamic changes.

Operators can and will move incrementally to NFV, starting with specific groups of network features and functions. Mobile operators are already virtualizing their Evolved Packet Core (EPC), the technology that handles subscriber management and authorization.

Page 35 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Cisco Chief CTO and Chief Architect David Ward explained that EPC functions are a relatively clean and straightforward lift from the physical appliance into a virtual instance. Cisco now offers virtualized EPC technology.

Other operators are already beginning to dynamically provision virtual firewalls, load balancing and WAN optimization. "The real opportunity is customer-facing services. We can each have our own virtual service wherever we go," Chander said.

But to go deep enough to provision bandwidth on demand, with self-service network features and optimized content, operators are seeking new ideas and tools to scale SDN (or some other form of programmability) across the WAN. They're looking for ideas on how to extend orchestration to each layer of their network and controllers with programmability that can reach down into the optical transport layer. The challenges are many.

AT&T will take on radical shift AT&T Senior Executive Vice President of Networks John Donovan delivered a concise keynote message: AT&T is embarking on radical change in the form of SDN and NFV.

The first step will be to dump purpose-built equipment designed for specific sets of features. Instead, AT&T will virtualize network functions that can be "instantiated and updated from anywhere and more quickly than they are today," Donovan said.

Page 36 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Then, AT&T will build programmable networks that "dynamically reroute traffic, add capacity, and introduce new features through programmable, policy-based controllers." Along the way, AT&T will provide open application programming interfaces, so customers and partners can build their own apps into the network.

But Donovan was the first to admit the technology is not in place for this transformation, so AT&T will look beyond only incumbent vendors, like Cisco and Juniper, in the search for innovative tools. The company has met with more than 100 vendors -- both startup and incumbent -- as well as researchers in its quest.

"This allows for non-traditional network players, smaller entrepreneurial players, universities and others to participate in our new ecosystem in addition to the existing players," he said.

AT&T is already focusing on virtualizing its EPC and IP multimedia subsystem. Donovan identified hardware vendors Ericsson and Metaswitch as two established suppliers that are on board with AT&T's plans. He also identified two smaller vendors, Tail-f Systems and Affirmed Networks. Tail-f provides network control software that can manage network gear from multiple vendors by interfacing with their existing control planes. Affirmed Networks develops technology that virtualizes EPC.

Page 37 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

NTT's toe is in the NFV and SDN pool, but the operator is ready to dive in NTT first took on network virtualization and SDN in 2012 with its Enterprise Cloud service. The operator implemented OpenFlow SDN both inside the cloud data center and in the intra-data center network, bypassing manual configuration of routers and switches, and enabling automated provisioning of cloud resources.

Now, the company is ready to take SDN and NFV further, and will start by working toward self-service, automated VPN provisioning.

"We automated configurations of provisioning within the data center, but existing VPN service is still done by manual operations. What we will focus on next is the interconnection portion between the data center and the VPN network," said Yukio Ito, NTT senior vice president. "Both networks have edge devices, and we need a system to configure both devices simultaneously."

NTT is working with technology that will let users configure their network by entering the information into a portal, which then speaks to a controller that turns on the VPN. That information is also advertised to an edge router for distribution in the VPN network, Ito explained.

Page 38 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Next up, NTT will turn its vision to virtualizing network functions, such as WAN accelerators and firewalls, so customers no longer have to build them on-premises, Ito said. These services will be connected through an "SDN common framework" and controlled through an orchestrator.

Finally, NTT will go deeper with SDN and NFV beyond Layer 2/3 and into the optical and transport network, Ito said. But he also made clear that this is a deeper challenge.

"To apply SDN to the whole network, we need to think about how we apply SDN to wide area network," Ito said. This will require multilayer optimization and multi-grade redundancy, as well as a migration of all management techniques.

NTT has started by building overlay networks and will move slowly to full SDN. In the meantime, NTT can simplify the network by using virtual "network slices" to connect NFVs.

Ciena demands operators step up to NFV and SDN, but it doesn't offer total solution Francois Locoh-Donou, senior vice president of Ciena Corp.'s global products group, scolded operators for not moving quickly enough into programmability. Then he outlined Ciena's NFV and SDN strategy -- which is also largely still in development.

Page 39 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"At Mobile World Congress, there were 70,000 of us that descended on that city. Prices at hotels went through the roof, prices of car rentals were three times higher, flights were more expensive … but what about the price of network service? No change," Locoh-Donou said. "Why is it that when there is a golden opportunity for network operators to optimize their infrastructure, they're not able to do so?"

Ciena is offering a combination of technology that lets operators gain a global view of the network with the ability to collect network usage data in real time. Then, operators can use this information for flexible provisioning and resource management. "If we can define network behaviors, we gain a lot of flexibility; we can evolve services faster," he said.

Ciena will use OpenDaylight (ODL) controllers that direct flows among "contention-less optical switches that allow wavelengths to move around the network." The use of ODL controllers will also mean operators can build their own applications as needed.

Next article

Page 40 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Section 3: NFV upsides The benefits of NFV

Cost efficiency is a main driver of NFV. Learn how increased service agility and other benefits could result from an NFV implementation.

Page 41 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Is service agility the payoff in network functions virtualization?

Tom Nolle, CIMI Corporation

Network Functions Virtualization (NFV) “the technology that allows operators to virtualize network functions and run them on less-expensive off-the-shelf servers” has generated quite the buzz with the promise of cost savings.

Yet despite initial dreams of tossing out expensive proprietary routers for commodity servers, NFV's path to network spending reduction is fuzzy. It remains unclear whether the technology will ever offer the performance necessary to replace proprietary routing and other core network functions in large-scale networks.

However, NFV will enable the virtualization of plenty of other network features, and will lead to a new level of service agility. With that, the technology promises an even more enticing promise than operational cost savings: It could mean new service revenue.

The idea is that NFV will let operators virtualize network appliances and services, which can then be dynamically provisioned and integrated into a larger orchestration context.

Essentially, network services such as firewalling and load balancing will be provisioned as flexibly as the applications they support.

Page 42 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Until now, operators have been able to automate applications that live on virtual servers, but then they would have to manually provision the supporting network services, sometimes even on a hop-by-hop basis. This manual process has been counterproductive to automated, orchestrated application provisioning.

NFV is still in its early stages, but if the technology eventually enables dynamic provisioning of network services, it could become the dominant network technology shift of the decade.

Service agility, the holy grail of NFV When it comes to NFV, operators love to toss about the term service agility. That's because currently it can take between two weeks and two months for operators to provision business services. Worse, if these services require new supporting infrastructure, it can take more than six months of lab work and then additional time to build the new devices. With NFV, operators hope to avoid this lengthy deployment because services are created through software integration and can be validated and deployed faster.

While NFV could clearly substitute for appliances like firewalls and load-balancers, or even for internal components of IP Multimedia Subsystem (IMS), the catch will be in how much of a provisioned service is actually software-based.

The more legacy equipment involved in provisioning a new service, the less impact NFV can have on service agility.

Page 43 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

And that will be a common dilemma, since operators won't likely replace access equipment. They won't, for example, replace carrier Ethernet with hosted Ethernet switching. Even where an operator uses virtual switching, optical transport and other deeper OSI functions won't be converted into virtual functions. So in order to maximize NFV benefits, operators must extend NFV orchestration outside the boundaries of network functions to underlying legacy network. Vendors and operators are still working on strategies to extend NFV orchestration in this way.

New network features for potential revenue While there are still challenges in using NFV to impact service velocity in a significant way, the technology can already enable a new range of service features that will be used to produce revenue. NFV will allow operators to offer context-aware network services, or the ability to ensure varying levels of service and performance according to application, user or location. Ultimately, providers will be able to charge accordingly for these granular services and performance assurances.

The ETSI specifications for NFV make it clear that NFV and cloud computing, or hosted applications, are very closely related. A network function could eventually be composed and provisioned in exactly the same way as a SaaS application. This could create a totally new model of services, blending network features with cloud computing or blending cloud-hosted application components with network services.

Page 44 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

An example of this would be distributed load-balancing for cloudbursting. In a model in which copies of an application are hosted in the cloud, but are dispersed and shared among users, NFV and its dynamic provisioning can be used to load balance effectively across sites and users.

This kind of granularity in management lets operators define QoS/QoE goals for a cloud application according to users' specific needs and meet those goals at the network level. Additionally, they can integrate managed security and availability features into applications dynamically. Network operators will use this capability to differentiate their own higher-level services by tying them directly to network behavior.

NFV services must offer this kind of integration of applications and network behavior in order to be differentiated from other cloud services. But there are also other important features beyond transport/connection QoS.

Network access security, as well as network resiliency and manageability, are all features that can be linked to the network and offered more easily and granularly with NFV.

NFV's dynamic distributed load-balancing and management across data centers or clouds will allow operators to secure sites from DDoS attacks, as well as to manage an array of remote devices, and even to use IT tools for facilities management, to make power usage decisions for example.

NFV could also be extended to non-connectivity features of the network. Probably the most relevant of these use cases is context-aware networking or the ability to make performance and provisioning decisions based on location, user activity and even social context.

Page 45 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

If users are busy, they don't have to receive application access. Or they can receive varying levels of access depending on the type of application they need.

Ultimately, it's not likely that NFV will introduce new services that couldn't otherwise be provided. NFV is about function hosting, and there are many ways to host functions-- from appliances to dedicated servers, through virtualization and via the cloud. But NFV will create a framework for deploying complex applications and operating them with high reliability and low operational expenditure costs. This will allow operators to price even complex contextual applications at levels that are consistent with broad adoption and still make a satisfactory profit from their investment. It will also allow operators to bring new services to market faster, accelerating revenue realization and encouraging investment.

The future of carrier networking depends on a combination of utility for buyers and profit for the operators. NFV doesn't change the game, but it optimizes how it's played, and that's just as important in today's world.

Next article

Page 46 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

How network functions virtualization will revolutionize architecture

Tom Nolle, CIMI Corporation

For decades, networks and network services have been built by linking purpose-built hardware through communications trunks, then inducing cooperative behavior among these elements using management systems. The process worked well for traditional services, but it is breaking down in the Internet age as operators look to reduce the cost of their infrastructure to accommodate lower revenue per bit. Now, those operators want their own flexible platforms for building new revenue-generating services because they are competing with handset and over-the-top players. Network functions virtualization (NFV) is the initiative that embodies both these goals.

Currently being considered by an Industry Specification Group within the European Telecommunications Standards Institute (ETSI), as well as other industry groups including the Open Networking Foundation, NFV aims to move network functions out of network equipment and onto virtual hosting. These functions range from simple firewalls, network address translation and load balancing to more complex processes, such as IP Multimedia Subsystem and the Evolved Packet Core framework.

If it's successfully developed and implemented, NFV will completely revolutionize how networks are built, managed and used to create services.

Page 47 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

It's unlikely that virtual hosts will totally displace network equipment (data-plane tasks like large-scale packet forwarding will likely require specialized devices, though they could be simpler and cheaper), but the high-value portion of network services could be made into a series of interoperating, cloud-hosted components. In this context, virtual devices could be used to accomplish special missions, and they could be as easy to build as a componentized application.

Network functions virtualization depends on the proper execution of four steps:

1. Existing network functions have to be componentized and broken into virtual functions with standard interfaces. It's likely that the points of virtual function componentization will at first align with existing device boundaries and with standard component descriptions generated by such standards groups as the 3rd Generation Partnership Project or the Internet Engineering Task Force.

2. These new virtual functions will have to be structured to be run as applications in the cloud, with virtual network interfaces instead of the physical connectors that serve device networks.

3. A deployment process, something resembling DevOps, will be needed to instantiate virtual functions and connect them into cooperating systems as we used to do with devices.

4. We'll need a new vision of management to handle a world where major pieces of the network are virtual software elements sharing servers, not real devices with real management interfaces to control their behavior.

Page 48 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Moving from hardware-based functions to virtual ones Some network functions already are available in the form of open source or proprietary software, but much is embedded in hardware. To be turned into virtual components, hardware functions have to be separated from the specific hardware on which they run, which might leave some elemental device with basic features behind -- similar to what could happen with software-defined networking, or SDN.

For NFV to work, it will have to work with standardized components that obey defined and interoperable interfaces. It also will have to work with proprietary components created by vendors to support cloud capabilities. For example, engineers will have to be able to create multiple instances of a function for improved reliability or performance. Open source packages or software-based implementations of vendor-specific routers, switches, firewalls and other elements could be suitable components in their current forms.

To make a component into a virtual function, you'll have to convert it into a standard form suitable for deployment on a virtual resource pool, such as the cloud. Obviously there are no physical plugs and sockets on a virtual function, so every real interface will have to be replaced with a virtual one, such as an Open vSwitch or other similar product. This would then manage the connections and data flows among the virtual functions when they deploy.

Page 49 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

At this point, some standardization of the server requirements will likely be needed to ensure that every virtual function doesn't need its own specialized hosting platform features.

These newly componentized and standardized virtual functions then will have to be deployed to create services, much as service-oriented architecture components are deployed and integrated to build applications. In the cloud, this could be a function of cloud-management application programming interfaces like Nova and Quantum in OpenStack, or deployment could be managed through a DevOps process, using something like Chef or Puppet. For NFV to provide reasonable operating costs and agile deployment, some automated mechanism is indicated, and the NFV activity could elect to identify something specific or only to provide the means of integrating a variety of open source or commercial tools to do the job.

NFV management challenges Management is the most challenging aspect of NFV. It's true that NFV must somehow support the current network management, network operations and the OSS/BSS processesOoSperations and business support systems S/BSS processes of operators, but it's also true that doing this probably is not as simple as providing a virtual management interface for each virtual function. The actual resources that host and connect virtual functions are outside the functions, so it isn't likely they'll be fully visible to current management apps.

Page 50 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Furthermore, they are shared resources, so no management interface can be allowed to do something to a virtual function that would have a negative impact on other functions that might share some of the resources. Management changes must also preserve network stability and security. For all these reasons, it could be that the management of virtual functions will itself be virtual, provided by some external process that relates virtual functions and their resources to a series of management interfaces that can support both current and future management activities.

What will it take to create NFV standards? To address all these steps with new standards would be a task so complex it's doubtful it could be completed in a decade. It's therefore likely that ETSI and associated organizations will develop NFV using current standards from other bodies rather than creating new ones.

Where no standard is suitable, they'd recommend changes to the most relevant standard available, working through the standards body that "owned" that particular standard. Any standard that currently defines the internetworking of real devices could be used to define virtual functions. For example, virtualization and cloud management standards could describe how virtual functions are actually hosted.

Network functions virtualization is an incredibly ambitious effort, but it's driven by a growing number of vendors and operators who want to create a profitable, stable and agile network framework for future services.

Page 51 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

It's already influencing network design for operators and product planning for vendors. As it matures, its effects will surely be felt even in enterprise networking. The union of the network and IT that the cloud represents could be built on the architecture that NFV defines in the near future. If so, it will shape every enterprise and consumer service delivered through the network.

Next article

Page 52 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Section 4: How SDN and NFV work together

What is the relationship between SDN and NFV

SDN and NFV aren't one in the same. In this section, experts explain the differences between SDN and NFV, while also taking a look at how each complements the other. Together, SDN and NFV provide powerful benefits to those in the mobile space as well as within service chain provisioning.

Page 53 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

What is the difference between SDN and NFV?

Glen Kemp, Professional services consultant

What is the difference between SDN and NFV?

Network function virtualization (NFV) and software-defined networks (SDN) are two closely related technologies that often exist together, but not always. An SDN can be considered a series of network objects (such as switches, routers, firewalls) that deploy in a highly automated manner. The automation may be achieved by using commercial or open source tools customized according to the administrator's requirements. A full SDN may only cover relatively straightforward networking requirements, such as VLAN and interface provisioning.

In many cases, SDN will also be linked to server virtualization, providing the glue that sticks virtual networks together. This may involve NFV, but not necessarily. NFV is the process of moving services, such as load balancing, firewalls and IPS, away from dedicated hardware into a virtualized environment. This is, of course, part of a wider movement toward the virtualization of applications and services.

Functions such as caching and content control can easily be migrated to a virtualized environment but won't necessarily provide any significant reduction in operating costs until some intelligence is introduced.

Page 54 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

This is because a straight physical to virtual, from an operational perspective, achieves little beyond the initial reduction in power and rack-space consumption. Until some dynamic intelligence is introduced with an SDN technology, NFV inherits many of the same constraints as traditional hardware appliance deployments, such as static, administrator-defined and managed policies.

A good example is virtualized application delivery controllers (ADCs). With careful configuration, it is possible to react to the network state and spin up or down application servers as demands rise and fall. However, traditional hardware deployments have been able to do this for a while, and the configuration is very static; it doesn't cater to the scenario where the ADC itself becomes overloaded or an additional application needs to be brought into production quickly. With SDN features driving NFV, several useful things start to happen. The network can react when things need to change at the micro and macro level. An additional instance can be provisioned in a cluster of virtualized ADCs as the load increases, and production applications can easily be cloned and re-deployed in a development environment. The potential is endless.

So it's perfectly possible to have NFV without the inclusion of a full-blown SDN. The two are often deployed together, and an SDN that drives NFV is a very powerful combination.

Neither NFV nor SDN are turnkey solutions in early 2014 -- a great deal of integration and policy design still need to happen. This can become a reality for many enterprises, but the harness is not entirely in place.

Page 55 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

That said, the tools are rapidly evolving, and many vendors are bringing technologies to market that support SDN or NFV deployments. Ultimately, the implementation of either or both technologies will be driven by the business needs.

Next article

Page 56 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Understanding the relationship between SDN and NFV

Tom Nolle, CIMI Corporation

It's difficult to get an industry with a long depreciation cycle for capital equipment to support any sort of revolution, but networking is facing two at once. Both software-defined networking (SDN) and network functions virtualization (NFV) propose revolutionary developments, and the success of either in changing the network may depend on the technologies being somewhat harmonious, if not actually supportive of each other. Just where the points of harmony lie may explain our roadmap to the network of the future.

SDN and NFV are not part and parcel SDN evolved out of two fairly different industry problems. First, building and managing large IP/Ethernet networks was becoming increasingly complex given the adaptive nature of packet forwarding for both protocols. Traffic management and operations efficiencies could be improved, many said, by exercising central control over forwarding. Early examples of SDN by players like Google seem to bear this out.

Page 57 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Second, the promise of cloud computing creates a new model for application deployment where tenants must share public cloud data centers in a non-interfering way, and multi-component applications must be deployed on flexible resource pools without losing control over performance and security. Given two different missions, it's not surprising that there are at least three models of SDN being promoted. One model is based on centralized control using OpenFlow controllers, another depends on using SDN to provision and manage network virtualization using network overlays, and the third is a distributed model in which a higher layer of software communicates with the network and its existing protocols.

Network functions virtualization is a carrier-driven initiative to virtualize network functions and migrate them from purpose-built devices to generic servers. The express goals of NFV are to reduce deployment costs for services by reducing the reliance on proprietary devices and to improve service flexibility by using a more agile software-based framework for building service features. From the first white paper proposing NFV, innovators visualized a pool of virtual functions, a pool of resources, and a composition/orchestration process that links the former to the latter. That paper suggests that NFV and SDN have some overlap, but SDN is not a subset of NFV, or the other way around. So where do SDN and NFV intersect? And how will the interaction between SDN and NFV impact the evolution of both ideas?

Page 58 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

SDN and NFV will meet to advance centralized control … down the road It seems clear that NFV could define the central control functions of SDN as virtual functions, so, for example, OpenFlow switches could be directed by NFV software. In theory, the SDN controller could be implemented as a virtual function, which would make it conform to both SDN and NFV.

Firewall and load-balancing applications are also targets of NFV since they have an SDN-like segregation of forwarding and control behaviors. Indeed, if NFV addresses the general case of policy-managed forwarding, it could define a superset of SDN.

NFV could also define central control and administration of networks that operate through other protocols, such as BGP and MPLS, and even define configuration and management of optical-layer transport. However, none of these appear to be near-term priorities for the body, and so this direct overlap of SDN and NFV doesn't seem likely in the next few years.

NFV demands virtual network overlays … and thus SDN While it may take some time before we see NFV play a key role in SDN architecture and vice versa, the use of network overlays in NFV will drive an intersection of the technologies in the shorter term.

Page 59 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

NFV is likely to at least accept, if not mandate, a model of cloud-hosted virtual functions. Each collection of virtual functions that make up a user service could be viewed as a tenant on NFV infrastructure, which would mean that the cloud issues of multi-tenancy would likely influence NFV to adopt a software-overlay network model. This is where SDN comes into play.

This model, made up of tunnels and vSwitches, would segregate virtual functions to prevent accidental or malicious interaction, and it would link easily to current cloud computing virtual network interfaces like OpenStack's Quantum. The virtual networks would be provisioned and managed using SDN.

Adoption of network overlays for virtual function segregation could make NFV the largest consumer of cloud networking and SDN services. This would mean that NFV could shape product features and accelerate product deployment in the SDN space.

That alone could have an impact on every cloud computing data center and application, including private and hybrid clouds.

How NFV will push SDN beyond the data center NFV's use of virtual network overlays could also drive an expansion of this SDN model beyond the data center where it's focused most often today.

Page 60 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

If NFV allows services to be composed of virtual functions hosted in different data centers, that would require virtual networks to stretch across data centers and become end-to-end. An end-to-end virtual network would be far more interesting to enterprises than one limited to the data center. Building application-specific networks that extend to the branch locations might usher in a new model for application access control, application performance management and even application security.

Will NFV unify differing SDN models? With the use of network overlays, NFV could also unify the two models of SDN infrastructure -- centralized and distributed. If connectivity control and application component or user isolation are managed by the network overlay, then the physical-network mission of SDN can be more constrained to traffic management. If SDN manages aggregated routes more than individual application flows, it could be more scalable.

Remember that the most commonly referenced SDN applications today -- data center LANs and Google's SDN IP core network -- are more route-driven than flow-driven. Unification of the SDN model might also make it easier to sort out SDN implementations. The lower physical network SDN in this two-layer model might easily be created using revisions to existing protocols, which has already been proposed. While it doesn't offer the kind of application connectivity control some would like, that requirement would be met by the higher software virtual network layer or overlay.

Page 61 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Despite all the conversations, SDN and NFV are still works in progress, and both could miss their targets. But if NFV succeeds in reaching its goals, it will solidify and propel SDN forward as well and create a common network revolution at last.

Next article

Page 62 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

In mobile networks, SDN and NFV mean service orchestration

Indranil Chatterjee, Community Member

Software-defined networking (SDN) and Network functions virtualization (NFV) took center stage at Mobile World Congress this year as it became clear that the technology has the potential to revolutionize mobile operator networks. SDN and NFV can enable resource and service orchestration with dynamic provisioning that can take minutes instead of months.

In mobile networks, the need for dynamic provisioning and orchestration The foundation of Ethernet and IP protocol networks is elegant and simple, but things have become ever more complicated over the years with the introduction of features, such as access control lists (ACLs) and VLANs. This issue has become even more pronounced in mobile core data centers where operators must support control plane functions, such as policy and charging rules function (PCRF), User Data Repository (UDR) for subscriber data management and user plane applications involving complex Layer 7+ processing for rapidly growing video traffic.

Page 63 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Let's take the example of a control plane function, UDR, to illustrate current mobile network operator challenges. Openwave Mobility has deployed a UDR with a customer that has over 100 million subscribers. The UDR is accessed by dozens of applications including the short message service center (SMSC) and the multimedia messaging service (MMSC) in real time for reading and writing subscriber attribute data. It is arguably one of the most critical control plane elements in the customer's network. While the application has been solid over the last 10 years, there are two areas where this application can benefit from the introduction of SDN and NFV.

The first area is related to provisioning lead times. Today the UDR dimensioning and provisioning based on peak traffic forecasts has to be done almost a year in advance to account for setting up hardware, VLANs, load balancing, as well as software installations, configuration, data synchronization, and so on. That's a complex and time-consuming process to say the least. Imagine the multiplicative effect of this challenge for network and IT personnel when you take into account that each application in the network that has its own solution for load balancing, high availability (HA), configuration, monitoring, reporting, and the like.

This has resulted in CFOs sweating with the working capital ramifications of these long lead times. This problem is exacerbated by the fact that, given the long lead times, operators usually end up overprovisioning by 60-100% to ensure that there are no outages on days like Dec 25th, which would be a PR nightmare and immediate trigger for churn of subscribers.

Page 64 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

The second challenge that could be addressed by SDN and NFV is a concept that is interestingly not talked about as much in the context of SDN -- separation of application logic and enforcement from corresponding subscriber data. In many applications today, such as the policy and charging rules function (PCRF) and home subscriber service (HSS), the subscriber data and application logic/enforcement are banded together, usually in a proprietary interface, resulting in subscriber data that resides in multiple silos leading to data duplication, storage inefficiencies, data errors, complexity in the application related to HA and ultimately increasing the complexity and time to market for new applications.

How SDN and NFV address mobile network challenges We know already that SDN and NFV can address these challenges in two ways: dynamic resource orchestration and intelligent service orchestration. Dynamic resource orchestration, involving the principles of NFV, requires a uniform virtualization stack across applications often in the context of a private cloud for operators.

This means that individual applications such as the UDR not only have the capability to run on virtual machines but also have the capability of being auto-elastic during peak load times, with self-configured new instances coming up while maintaining state and critical capabilities such as HA and failover.

Page 65 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

This ultimately means that operators can reduce lead times for dimensioning and provisioning of resources for an application down to minutes from months. Meanwhile intelligent service orchestration primarily involves the principles of SDN whereby switches, routers and applications at Layer 7 can be programmed from a centralized component called the controller with intelligent decisions regarding individual flow routing in real time. It is important to note that intelligent service orchestration means subscriber policy and profile-aware service chaining at the flow level. In other words to realize this vision of differentiated service offerings by mobile operators will require a centralized data component such as a UDR. The SDN controller will interface with a UDR to truly enable dynamic and subscriber aware service chaining for each flow.

In summary, dynamic resource orchestration in tandem with intelligent service orchestration dramatically cuts down the long lead times associated with dimensioning and provisioning additional resources for an existing application, while also reducing the cost and time to market for new applications. It also goes a step further by providing the capability to deploy subscriber-aware services.

Given that this is a paradigm shift when it comes to how OpenWave's customers deploy and go to market with new services, the reality is that all this will be done very much in a phased approach over the next few years. In terms of functional areas, operators are focusing on OSS/BSS and the services data center as testing grounds for SDN and NFV, where proof of concepts have involved basic resource orchestration capabilities such as deploying applications on virtual machines.

Page 66 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

In 2013 we will see thought leadership and proof-of-concepts given our interactions and active engagements with mobile operators with regards to SDN and NFV.

Next article

Page 67 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

How SDN and NFV simplify network service chain provisioning

David Jacobs

Service chaining is not a new concept, but the trend has taken on a new importance with the rise of SDN and Network Functions Virtualization (NFV).

A service chain simply consists of a set of network services, such as firewalls or application delivery controllers (ADCs) that are interconnected through the network to support an application. But SDN and NFV can make the service chain and application provisioning process a whole lot shorter and simpler.

In the past, building a service chain to support a new application took a great deal of time and effort. It meant acquiring network devices and cabling them together in the required sequence. Each service required a specialized hardware device, and each device had to be individually configured with its own command syntax. The chance for error was high, and a problem in one component could disrupt the entire network.

Moving network functions into software means that building a service chain no longer requires acquiring hardware.

Adding to the difficulty, application loads often increase over time, so building a chain that would not have to be immediately reconfigured meant estimating future demand and over-provisioning to support growth.

Page 68 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Devices needed to be sized to support the maximum level of demand -- something which might only occur at particular times of the year. Yet extra capacity has meant extra capital investment.

The effort required to construct a chain also meant that chains were often built to support multiple applications. As a result, data sometimes passed through unnecessary network devices or servers and consumed extra bandwidth and CPU cycles.

SDN and NFV simplify service chains Two recent developments -- SDN and NFV -- now enable network managers to quickly and inexpensively create, modify and remove service chains.

SDN moves management functions out of the hardware and places it in controller software that executes in a server. A standardized configuration protocol between the controller and network devices replaces proprietary device configuration languages. As a result, entire service chains can be provisioned and constantly reconfigured from the controller. In that scenario, the chance for error is much smaller since the controller software has an overall view of the network, reducing the chance for inconsistent device configurations.

NFV moves network functions out of dedicated hardware devices and into software. Functions that in the past required specialized hardware devices can now be performed on standard x86 servers.

Page 69 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Specialized packet handling hardware has been added to standard servers to make this possible.

Moving network functions into software means that building a service chain no longer requires acquiring hardware. Network functions typically execute as virtual machines under control of a hypervisor. When more bandwidth is required, an additional virtual machine can be provisioned to take part of the load, or the initial VM can be moved to a higher capacity server or to one that is less heavily loaded by other applications. There's no need to overprovision since additional server-based capacity can be added when needed.

Connections between service chain components may be contained within a single virtualized server or may cross network links between servers. Traffic may be contained within a VLAN or by one of the technologies being developed by vendors to address VLAN limitations, such as VXLAN tunneling.

SDN and NFV service chains change the service provider model Because communications service providers and public cloud providers carry such a wide variety of data types and applications, SDN and NFV-driven service chaining can improve their business models just by simplifying the service chain provisioning process.

Page 70 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Cloud providers must host enterprise applications that access databases and make bulk data transfers to and from customers' private networks constantly; meanwhile, communications service providers carry email, voice, video, Web traffic and downloads. Each data type benefits from specific types of related services. With SDN and NFV, providers can create service chains tuned to each data type and ensure the level of service each customer purchases as a result. What's more, they can do this provisioning more quickly and for less money.

For service providers, a service chain may consist of an edge router at the customer premises, followed by deep packet inspection (DPI). The DPI service determines the type of traffic and signals the controller software to create a service chain for that packet stream and that customer.

An email service chain, for example, would include virus, spam and phishing detection and could be routed through connections offering no delay and with jitter guarantees. Web traffic would be routed through a chain that includes virus scanning and an ADC. The chain created for video and voice traffic would include traffic shaping, so that traffic would be routed over links with the level of delay and jitter guarantees purchased by each customer. Each type of stream would receive only the services needed, skipping the unnecessary ones.

SDN or NFV service chaining also makes the process of network upgrade simpler. Communications service providers, for example, have networks that are geographically distributed, so upgrading equipment requires travel. In addition, a single error can bring down the entire network and cause outages on interconnecting providers' networks. But with SDN and NFV,

Page 71 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

providers can create new chains that increase the efficiency and the capacity of their networks without radically changing hardware.

Finally, service providers can use new service chaining techniques to generate revenue from applications. Until now third parties have delivered services such as video on demand over service provider networks, while service providers themselves have been unable to enter these markets because of the complications involved in provisioning. But service chaining enables them to more efficiently embed applications and related services in the network itself, placing them at an advantage over the third party provider.

SDN and NFV and their use in building service chains are very recent developments. Vendors have begun exploring the technology and developing management tools that will simplify their use. As experience with the techniques accumulates and network managers see their benefits, service chains based on SDN and NFV will become a standard component of clouds and service provider networks.

Next article

Page 72 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Section 5: Tangible NFV Real world uses of NFV

NFV is getting closer to actual uptake. In this section, read about various vendors and their NFV strategies for mobile operators and other service providers.

Page 73 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

AT&T Domain 2.0 kicks into high gear as carrier embraces NFV and SDN

Shamus McGillicuddy, Enterprise Management Associates

SANTA CLARA, Calif. -- AT&T will start deploying SDN and network functions virtualization technologies this year as part of its Domain 2.0 vision for a next-generation network -- and it's willing to shake up vendor relationships to get there.

Last year, the carrier announced AT&T Domain 2.0, a plan to transform its network using SDN and network functions virtualization (NFV). During a keynote address at the Open Networking Summit this week, John Donovan, AT&T's senior executive vice president for technology and network operations, said 2014 is the year of "beachhead projects" that will move his company toward Domain 2.0. AT&T will use SDN and NFV to create a "user-defined network cloud." This will be a multi-service, multi-tenant platform that "taps into NFV and SDN to perform a broad variety of network functions and services," he said.

"NFV moves network functions from ASIC-based hardware to software running on general purpose computing. Those virtual network functions can be instantiated anywhere and more quickly than they are today," Donovan said.

Page 74 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

AT&T will follow four principles as it builds out this user-defined network cloud, he said. The infrastructure must be open, simple, scalable and secure. The openness means AT&T is ready to do business with new vendors, even companies that are not traditional telco vendors, he said.

"We're leaving the [procurement] process open," he said. "We appreciate the benefits of collaboration, and we're going to make sure we stay open to new ideas and maintain a competitive process. So if a company comes along with an innovation, they'll have a chance to pursue it with us."

"Our strategy is more than just a network design change," Donovan added. "It's a change in how we do business with suppliers [and] with how we manage platforms, systems and software. It changes our people. We have to take advantage of cultural change at our company."

Donovan called on the networking industry to work with AT&T to build SDN and NFV products that enable this user-defined network. "We've reached out to 100 different vendors to drive a whole new ecosystem of network equipment," he said. "Some won't share the same interest we have in moving to a new future, but some have."

Donovan identified hardware vendors Ericsson and Metaswitch as two established suppliers that are on board with AT&T's plans. He also identified two smaller vendors, Tail-f Systems and Affirmed Networks, which are working closely with AT&T.

He lauded Tail-f for its network control software, which can manage network gear from multiple vendors by interfacing with their existing control planes.

Page 75 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

He also praised Affirmed Networks for the technology it's developing that virtualizes the Evolved Packet Core (EPC).

AT&T's SDN plans: The bigger picture There are key areas that AT&T will not touch as part of its SDN initiative, at least for now, Donovan said. Those areas include the routing core, the optical transport network and radio access networks.

The carrier's decision to focus on the EPC, also known as the mobile core, as well as IP Multimedia Subsystem technology, opens up several possibilities for innovation, according to Lee Doyle, chief analyst for Wellesley, Mass.-based Doyle Research. He also noted Donovan's mention of turning AT&T's 4,600 central offices into environments that support a networking cloud -- a move that Doyle speculated would take advantage of existing infrastructure at those locations, including fiber, DSL, content delivery networks and potentially edge routers.

Overall, AT&T's SDN and NFV plans could affect between 40% and 50% of its annual infrastructure budget, Doyle said. The initiative will involve billions of dollars of spending. If anything is going to spur laggard vendors to comprehensively embrace SDN and NFV, that's the kind of money that will get it done. However, AT&T also hopes the move toward SDN and NFV will reduce its capital budget.

Page 76 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

As part of its year of "beachhead projects," Donovan said AT&T will try putting controllers on existing platforms and building a set of capabilities it can test. In 2015, the carrier will start building out new platforms, part of the AT&T Domain 2.0 initiative. The legacy infrastructure that comprises Domain 1.0 will have to go. "We won't do overlay networks," he said. "We will tag things as Domain 1.0, toe-tag it and move to 2.0."

AT&T confident it can secure, manage new network Donovan faced pointed questions from the audience following his presentation. When asked whether AT&T's operational support system (OSS) could handle this transformation. Donovan said his team has identified 1,000 applications in AT&T's OSS environment that are targeted for retirement.

"We will have new applications and new technology that will allow us to do policy and provisioning as a parallel process, rather than an overarching process that defines and inhibits everything we do," he replied.

One audience member expressed skepticism about AT&T's ability to secure such an infrastructure.

"We have an architectural design for security -- a platform called Astra -- which is abstracted and cloud-based," Donovan responded.

Page 77 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"We're in the process of moving from a firewalled enterprise into highly distributed data piles with rigorous requirements for compliance around that, and [we're working on] an architecture where data is hard to find and difficult to assemble into something meaningful."

When asked to explain why AT&T was doing SDN, Donovan replied, "There is no army that can hold back an economic principle whose time has come."

Next article

Page 78 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

CloudNFV group will create network functions virtualization prototypes

Shamus McGillicuddy, Senior Analyst

Several vendors have formed the CloudNFV consortium to create prototypes of network functions virtualization while service providers continue to move forward with standardization.

Last year nearly a dozen top network service providers banded together to define the concept of network functions virtualization (NFV). NFV posits that service providers can redeploy many of the network functions that live in large and expensive carrier-grade network appliances as virtual machines on industry standard hardware. NFV promises to reduce both the cost and complexity of service provider networks.

Service providers want their vendors to adopt this approach. To spur action, the Industry Specification Group (ISG) of the European Telecommunications Standards Institute (ETSI) has started standardizing NFV.

Meanwhile, CloudNFV has emerged on the vendor side to prototype technologies based on these emerging standards, said Tom Nolle, president of CIMI Corp., the network technology consulting firm that is leading the CloudNFV effort.

Page 79 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"Standardization is essential for creating interoperable frameworks for something like this, but standardization doesn't provide an implementation model," Nolle said. "You can't write software from a standard. You've got to have a software implementation architecture. While standards and implementation architecture are obviously related to one another, there are a lot of decisions in implementing something that can also affect interoperability in ways that the people who write standards might not visualize."

Nolle emphasized that CloudNFV isn't competing with the ETSI ISG's work, but rather is trying to support and inform the standardization effort by demonstrating the interplay between the standards and commercial implementation of them.

Five vendors went public with their participation in CloudNFV last week, and each plays a role creating an integrated, multi-vendor prototype for NFV. Dell offers data center infrastructure where the virtual network functions reside. 6WIND accelerates the performance of those functions in a cloud environment. EnterpriseWeb provides software for a data model that describes, orchestrates and optimizes the resources that compose a virtual network function. Overture Networks is providing orchestration software, an SDN controller and metro edge switches to link the WAN with the virtual network functions deployed in a cloud. Qosmos offers network monitoring software that provides network operations insight into how NFV is performing on the network. The IP voice infrastructure vendor MetaSwitch has also reportedly joined the group.

Page 80 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"All these [components] were important from the start because it was our intention with CloudNFV to build a framework that could be deployed globally," Nolle said. "Every operator could stick this in a lab and build a global federation of NFV implementations that could then be used to test and validate different approaches and concepts."

CloudNFV is not an open source project like OpenDaylight. The participants are not creating an open source platform that anyone can build products upon. The vendors are retaining their intellectual property, but they are creating open interfaces between the different components of NFV so all vendors can build to that specification and service providers can deploy multi-vendor NFV with minimal heartbreak.

"We published our integration guidelines on our website and integration is the thing we're principally looking at here," Nolle said. "We're trying to build an expandable framework. We are going to serve as both a model for NFV implementation and also as a source of components of NFV implementation because our architecture breaks up into pieces."

This is important because service providers "aren't keen on a big monolithic [NFV] solution from a single tier-one vendor," said Mark Durrett, director of marketing for Morrisville, N.C.-based Overture. "They would rather see something that is open and has field-replaceable components. If they become dissatisfied with one vendor's solution, they can move on to another one and keep the rest of the infrastructure in place."

CloudNFV is ready to start demonstrating its first NFV prototype, an IP Multimedia Subsystem service.

Page 81 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

For a group that formed just six months ago, CloudNFV's ability to have an initial prototype so quickly speaks to the power of multi-vendor approaches to NFV, Durrett said.

"We've gone from zero to proof-of-concept demo in six months," he said. "If you look at recent announcements from tier-one vendors of cloud-based NFV platforms, they've spent upwards of $60 million in three years to get this far."

Next article

Page 82 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Cisco NCS enables programmable network functions virtualization

Shamus McGillicuddy, Senior Analyst

With its Network Convergence System, Cisco Systems Inc. has introduced a family of highly programmable routers that deliver some of the flexibility and programmability service providers are looking for in SDN and network functions virtualization.

"The infrastructure being programmable accelerates or amplifies the actual usefulness of NFV [network functions virtualization]," said Stephen Liu, director of service provider marketing at San Jose, Calif.-based Cisco. "If you take NFV in its pure concept, it's about moving off of dedicated hardware onto general-purpose compute [in data centers] to do functions in the network like security or certain policy actions. Along with being able to support those types of topologies, the programmable interface [of NCS] allows us to distribute those service stations and actually make those services portable, inline in the infrastructure to be brought online, on demand."

The Cisco Network Convergence System (NCS) platform comprises three new series of routers:

Page 83 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

• Cisco NCS 6000: A 1.2 PBps modular router with 1 Tbps line cards, shipping today, and 5 Tbps per slot capacity for future line cards. The router converges both IP and optical networking.

• Cisco NCS 4000: A modular 6.4 Tbps modular router with 400 Gbps per slot. It supports optical transport, dense wavelength division multiplexing (DWDM), SONET and Ethernet.

• Cisco NCS 2000: A series of routers available in two models (2 and 6 line card capacities) that can connect DWDM transport networks at rates of 100 Gbps and beyond.

The NCS routers are powered by Cisco's new nPower X1 ASIC, which delivers 400 Gbps of capacity on a single chip. Unlike most network silicon, which balances processing and memory on one platform, the nPower X1 is 100% processing capacity, accessing the memory it needs by going off the chip. And combined with the open programmability of the overall system, it allows the NCS routers' network processing power to be repurposed on the fly, according to Len LuPriore, senior manager of strategic marketing for Cisco's service provider group. The NCS routers integrate with Cisco's management and orchestration software, including the company's Prime and Quantum software suites, to create a highly programmable network that can provision new services and applications automatically.

"We're building a layered approach, made up of the engines [routers], coupled with orchestration and management that are working with the applications," LuPriore said.

Page 84 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"In between each layer we have new code and capabilities that allow for cross communications between the applications, orchestration and hardware. The orchestration system is telling the hardware what to do and the hardware is responding back and saying, 'This is what I just did. Are my tolerances right? Do I have the right speed?' The application might say, 'No, I need more power.' This feedback loop occurs with constant monitoring of what's going on."

The degree of programmability supplied in this case is "stunning and opens up execution models for services that haven't really been possible before," said Paul Parker-Johnson, practice lead for cloud computing and virtual infrastructure technologies at Gilbert, Ariz.-based ACG Research. "One can easily envision localized instances of M2M [machine to machine] or so-called Internet of Things application modules deployed as desired in a given service context at any place in the supported network."

At a higher level, service providers will be able to create "policy domains," such as threat protection and authentication, which will allow them to create a programmable framework where services are running partially in the WAN and in cloud data centers, he said.

NCS "combines all of Cisco's next-generation technologies under a common umbrella to address emerging changes in the network and how it is managed to deliver on services as driven by the Internet of Everything [IoE]," said Glen Hunt, principal analyst for transport and routing infrastructure at Washington, D.C.-based Current Analysis Inc.

Page 85 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

NCS "goes beyond a simple platform launch to include a common operating system to span the network, data center and offers cloud support to deliver a more flexible services model."

NCS has the ability to orchestrate the service chains of virtual network functions associated with NFV, Cisco's Liu said. But it can also instantiate those services inline on the routers themselves. Routing traffic to NFV-enabled data centers slows down performance.

"With NFV, [service providers] want to get dedicated functions off hardware and put them on cheap compute," Liu said. "That's all well and good from a CapEx point of view. What is overlooked a little bit is that now you have these service stations existing in data centers. To get to those, you have to trombone a lot of traffic from the users to these service stations, and then back onto the network and onward to their final destination. So there is a lot of inefficiency that might occur. The virtualization and programmability [of NCS] allows us to port those network functions and distribute them into the network elements so we can process them inline."

Cisco is extending the concept of NFV further with the ability to link its own server platform, the Unified Computing System (UCS), directly to the control plane of the NCS routing subsystem.

"Once we extend the virtual capabilities -- where we have virtual IOS-XR running on virtual machines -- we can move the virtual control plane to UCS, which allows us to capitalize on x86 compute, coupled with our customized silicon," Cisco's LuPriore said.

Page 86 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"Then with NFV, we can move functions anywhere in the network by creating this fabric through UCS that allows us to aggregate core, edge, data center and optical components. We can really repurpose those at will across the cloud and leverage resources in an optimal way."

Cisco announced that service providers BSkyB, KDDI and Telstra have already deployed NCS.

Next article

Page 87 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Ixia virtualizes IxLoad appliance for NFV testing

Shamus McGillicuddy, Senior Analyst

Ixia is virtualizing its IxLoad testing appliances to help service providers evaluate network functions virtualization in the mobile core. Mobile operators, in particular, are looking for help with NFV testing.

"We're seeing some pause in spending and rollouts in some operators as they are trying to figure out NFV," said Joe Zeto, senior director of product marketing at Ixia. "They are trying to figure out what to virtualize and what not to virtualize. At the end of the day, they have known performance from their physical appliances and they have to make sure whatever they do when using virtualized software and off-the-shelf equipment [doesn't affect] quality of experience for their end users."

By virtualizing IxLoad, operators and developers can now run instances of the testing technology directly on the hypervisor hosts where the NFV virtual network functions reside, he said.

"This is for performance testing of virtual switches and hypervisors and getting the bottlenecks out of that," Zeto said. "It's also for functional testing [of NFV applications]. You can spin [virtual test ports] up and down pretty rapidly."

Page 88 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

As service providers start NFV testing, many of them are looking to accelerate and scale out their approach to testing individual virtual network functions, said Paul Parker-Johnson, practice lead for cloud computing and virtual infrastructure at ACG Research. "You can easily see a testing organization being able to accelerate and do multiple evaluations by being able to deploy and scale out testers quickly," he said.

Many service providers are also very interested in evaluating and characterizing the performance of the virtual networks that they are considering for their NFV deployments, he said.

Service providers and developers can use different combinations of virtual and physical IxLoad products for NFV testing, depending on what they are evaluating.

"It's not going to replace physical IxLoad appliances," Zeto said. "[You] might want to use a physical tester to test high-scale traffic and then use virtual testers to measure individual points on the network. You might [use the virtual tester] to measure voice or video quality or transaction latency. And you might use the physical tester to put massive stress on the network."

Ixia is targeting evolved packet core (EPC) applications with its virtual IxLoad tester, Zeto said. EPC and customer-premises equipment are seen by many experts as two of the early popular use cases for NFV.

Park Johnson expects that service providers will also use the virtual IxLoad tester to evaluate virtual firewalls and other virtual network security functions.

Page 89 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Ixia also published a free e-book, Demystifying NFV, which offers a guide to NFV migration for mobile operators. The virtual IxLoad tester is available today. Ixia did not reveal prices for the software, but Zeto said the company will offer use-based licensing, versus the per-module licensing that Ixia charges for his chassis appliances.

Next article

Page 90 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Overture offers NFV orchestration and control software

Shamus McGillicuddy, Senior Analyst

Overture Networks, a carrier Ethernet infrastructure vendor, introduced new orchestration and control software that service providers can use to replace network services appliances with software delivered via network functions virtualization.

Overture introduced its Ensemble architecture for network functions virtualization (NFV) last year. Now the company is announcing the first products in that architecture -- Ensemble Service Orchestrator (ESO) and Ensemble Network Controller (ENC) -- for NFV orchestration and control.

"This is not just how to spin up virtual network functions, but how to connect them to customers with no forklift [equipment replacement]," said Prayson Pate, Overture founder and chief technology officer. "Service providers want to decouple hardware and software. That's good in theory, but how do you put it back together and deliver services? ESO and ENC unite the virtual and physical worlds."

ESO takes service orders for virtual network functions through a northbound interface that connects into a service provider's back-office systems, higher-level orchestration system or business applications.

Page 91 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

It translates those service orders into NFV orchestration commands for both the ENC software and an OpenStack cloud controller that comes bundled with Overture's Ensemble software.

The OpenStack controller orchestrates the instantiation of new network functions and services on virtual infrastructure within a service provider's data center or central office.

ENC then sends commands to carrier Ethernet infrastructure in the service provider network, reprogramming the network gear via command-line interface and protocols like Simple Network Management Protocol so traffic is routed to a provider's data center or central office where the architecture can apply the appropriate virtual network functions.

Overture also introduced the first in a series of "turnkey" NFV packages, known as Ensemble Solution Packs (ESP), which customers can deploy on top of the Ensemble architecture. The first ESP is a package that replaces the need for installing customer-premises equipment (CPE) on-site every time an enterprise orders new managed network services, such as firewalls and load balancers. The service pack, virtual managed enterprise CPE (vE-CPE), allows service providers to deploy those firewalls, load balancers and other services in their own data centers or central offices and route customer traffic to those functions.

While service providers are pushing hard for NFV products from vendors, standards around the concept are still developing, particularly at the points where network orchestration and control intersect with a service provider's back-office systems and customer portals.

Page 92 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"All of this is still a work in progress," said Akshay K. Sharma, research director for Stamford, Conn.-based Gartner Inc. "[The] ETSI [European Telecommunications Standards Institute] is still defining the northbound interfaces for [NFV] orchestration."

Overture is providing only the NFV orchestration and control on the network, Pate said. It has no intention of building software for the virtual network functions. For that, the company will partner with third-party vendors. Overture hasn't yet identified any partners in that area. Many infrastructure vendors who are building an NFV architecture will have to do the same.

"They'll have to partner with a Sonus for session border controllers, or an F5 Networks for load balancers and application delivery controllers, or with BroadSoft for unified communications as a service," Sharma said.

Overture said several tier-one service provides are testing or trialing the Ensemble NFV technology, and those providers are working closely with the company to advance the technology.

"They do have a lot of traction in proofs of concept and trials," said Ron Kline, principal analyst for network infrastructure at London-based research firm Ovum. "But in the end, can they get a large-scale deployment of this stuff going?"

Overture has also indicated that its Ensemble NFV architecture will eventually work with third-party network infrastructure. That integration will be critical to most service providers, Kline said. Overture will need to prove that capability over anything else.

Page 93 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"These networks tend to operate in multivendor environments," he said. "Several of the trials [Overture] told me about are multivendor in nature. You really need to negotiate the interfaces between the controller and those [third-party [elements]. Just because everything is 'open' doesn't' mean it's interoperable."

Next article

Page 94 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

New NFV vendor ecosystem, usual suspects: Cisco, Juniper ALU, HP

Rivka Little, Product Marketing Specialist

Last week's Mobile World Congress set the stage for an NFV showdown between Cisco, Juniper, HP and Alcatel.

All four are now officially network functions virtualization (NFV) vendors, offering technology that virtualizes key network functions on standard servers and then connects those servers using SDN and a unified orchestration platform.

The goal is to enable dynamic provisioning of applications, along with supporting network services. That means service providers can provision customized content and applications dynamically based upon user need.

In traditional hardware networks, service and application provisioning can take weeks -- or even months -- since it requires implementing new hardware to establish more capacity, as well as manually linking together all of the supporting services, such as firewalls and load balancers. With NFV, virtual network components can be provisioned with a few clicks, and supporting services can be deployed along with them.

Page 95 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

The ability to offer customized content will mean service providers can begin prioritizing specific sets of content -- business video over YouTube in the workplace, for example. It also means they can spin up capacity for traffic spikes on holidays or during disasters.

Cisco pushes for virtualized packet core and portability across operators Cisco has virtualized key capabilities of its Aggregation Service Router (ASR) 5000, and at Mobile World Congress, they demonstrated how these virtual features could be portable across disparate operator networks.

Cisco's Quantum Virtualized Packet Core lets service providers automate the way they authenticate and manage subscribers, and it lends a hand in dynamic provisioning of applications and services.

Cisco's strategy relies on a service broker layer that lets operators implement service models across their domains to extend functionality. Operators create profiles for services and applications, along with user and traffic policy. Then those profiles are shared through the broker and incorporated as part of the overall orchestration context.

"They've included in their design a service broker [that relies on] processing templates and descriptions of what the operators themselves want to achieve in an orchestration function," said ACG Research analyst Paul Parker-Johnson.

Page 96 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

"This broker layer allows for service description to be exposed or advertised from one operator to another, so the guys who are working on the match have less work to do in creating the resulting parameters that are then passed down to the orchestration layer to allow the traffic to pass."

Cisco allows service providers to incrementally move into NFV. There are four ways that operators can buy into Cisco's new system. They can start with virtualizing just one network function. A second option lets them buy a prepaid orchestration package. The third option lets operators buy an entire application bundle. The final option lets them buy network virtualization as a hosted service.

"It all has the same personality, but there are different levels of commitment," Johnson said.

Juniper might be an NFV vendor, but it's pushing SDN for service providers Juniper unveiled an expansion to its service provider SDN portfolio, and there's a new controller at the heart of the release that's not Contrail.

The strategy, rolled out at Mobile World Congress this week, combines NFV and SDN to let operators automate provisioning of applications, supporting network services and traffic optimization through a unified orchestration system.

Page 97 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Juniper said the goal is to let operators provide varying levels of content quality based upon the user and context. That means companies could prioritize video for business use over video for personal use, even to the same user on the same device.

To enable this, Juniper has one set of programmable technology aimed at the network layer, another aimed at the application layer, and then an in-between that integrates the two. At the network layer, Juniper has released software called Fusion, which lets operators manage thousands of network components -- whether they are routers or mobile devices -- through a single platform as if they were one cohesive unit. Meanwhile, a new SDN controller called NorthStar uses existing protocols, like Border Gateway Protocol, to control traffic between network components. NorthStar controllers automatically identify optimal paths for traffic based upon set policy.

Meanwhile, at the service layer, operators can use NFV technology to virtualize the service creation functions and subscriber management. Services are controlled and provisioned through the Service Control Gateway that lives on MX series routers, which can provision applications based on subscriber and policy. Then, there is the Carrier Services Gateway, which lets operators provision virtual network functions either directly on a router, on a standard hardened x86 server, or on a virtual platform in the cloud. Operators can use these three options as "a stepping stone" to implement various levels of NFV or to implement distributed services, said Mike Marcellin, senior vice president of marketing and strategy at Juniper.

Page 98 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

HP's NFV brings technology and a partner ecosystem Hewlett-Packard launched OpenNFV, which also aims to virtualize network features and enable dynamic application, network and service provisioning in operator networks. HP differentiates itself by taking a three-prong approach, which includes an overarching reference architecture, a partner ecosystem, and a testing lab for users.

HP's reference architecture, the HP NFV RA, stretches across physical and virtual network elements, enabling provisioning of network features, services and applications. The RA includes the HP Virtual Services Router that will be used to support and manage virtualized appliances in distributed clouds. Essentially, HP will use a combination of NFV on servers and SDN controllers to connect those servers through networks. All will work within a single orchestration framework.

HP also detailed the OpenNFV Partner Program and the OpenNFV Labs, which aim to develop an ecosystem of partners co-creating NFV features or applications. The lab will also encourage vendors to test how they interoperate in a multivendor environment. HP execs said they are already working with a range of equipment providers and carriers.

Page 99 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Alcatel-Lucent applies CloudBand orchestration to NFV Alcatel-Lucent (ALU) released technology this week that will let service providers virtualize and automate elements of the mobile network, making it possible to provision Voice over LTE and multimedia services on demand.

Using ALU NFV technology, mobile network operators can place evolved packet core (EPC), IP multimedia subsystem (IMS,) and radio access network features on virtual machines in the cloud. Then, network operators can use SDN technology from ALU's spin-off Nuage Networks to connect those virtual machines across data centers, as well as to optimize networks. Finally, they can then employ ALU's orchestration platform CloudBand to automatically provision these functions across distributed data centers.

Combined, the technology will let mobile operators provision and de-provision instances of voice or other real-time applications on demand to meet users' needs.

Specifically, virtualizing the EPC will let operators automate the authentication and management of subscribers as they access services. Meanwhile, virtualizing the IMS changes the way those multimedia services are provisioned.

Page 100 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

A virtualized IMS means voice services, for example, can be controlled by hypervisors and deployed among a pool of servers without having to be bound to a particular hardware server and CPU, explained Akshay Sharma, a research director at Gartner. Provisioning can occur dynamically in response to user need.

"Previously, we had to buy more capacity in boxes and [would] have it sitting idle until Mother's Day, [for example], when call volume went up," Sharma explained. "In the new world, we can [provision] new instances of those functions for call volume without having dedicated resources that sit idle for the rest of the year."

Next article

Page 101 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Alcatel-Lucent NFV technology for mobile means Voice over LTE at last

Rivka Little, Product Marketing Specialist

Alcatel-Lucent (ALU) released technology this week that will let service providers virtualize and automate elements of the mobile network, making it possible to provision Voice over LTE (VoLTE) and multimedia services on demand.

Using ALU network functions virtualization (NFV) technology, mobile network operators can place evolved packet core (EPC), IP multimedia subsystem (IMS) and radio access network (RAN) features on virtual machines in the cloud. Then, network operators can use SDN technology from ALU's spin-off Nuage Networks to connect those virtual machines across data centers, as well as to optimize networks. Finally, they can then employ ALU's orchestration platform CloudBand to automatically provision these functions across distributed data centers.

Combined, the technology will let mobile operators provision and de-provision instances of voice or other real-time applications on demand to meet user need.

Specifically, virtualizing the EPC will let operators automate the authentication and management of subscribers as they access services.

Page 102 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Meanwhile, virtualizing the IMS changes the way those multimedia services are provisioned. A virtualized IMS means voice services, for example, can be controlled by hypervisors and deployed among a pool of servers without having to be bound to a particular hardware server and CPU, explained Akshay Sharma, a research director at Gartner. Provisioning can occur dynamically in response to user need.

"Previously, we had to buy more capacity in boxes and have it sitting idle until Mother's Day, [for example], when call volume went up," Sharma explained. "In the new world, we can [provision] new instances of those functions for call volume without having dedicated resources that sit idle for the rest of the year."

In LTE networks, which are IP-based, voice has been such a challenge that operators have pushed it over legacy 3G networks and maintained LTE for data and video. In fact, a number of key players have delayed launching VoLTE services because of performance challenges, said Manish Gulyani, vice president of product marketing at ALU.

"Nobody has launched voice over LTE -- they are all on track to do it this year. But now, performance really matters. It's no longer just a data service," Gulyani said. Beyond voice, mobile operators are finding the need to burst up and down capacity to support machine-to-machine technology, as well as mobile worker access.

Page 103 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

This week at Mobile World Congress, ALU and China Mobile are displaying the combined SDN and NFV technology, allowing users to make calls on VoLTE handsets over a multivendor network that uses Alcatel's virtual network functions and orchestration.

A number of vendors are introducing carrier NFV, but few are able to introduce orchestration and SDN out of the gate.

"You could argue that ALU has some unique advantage in that they have IMS virtualized and they have a router and they have Nuage. They are ahead in connecting the dots," Sharma said.

How NFV and mobile will change business models ALU and other equipment vendors are banking on the concept that mobile operators will find their way to new revenue-generation models using NFV and SDN.

In old-school networks, it took weeks, sometimes even months, to provision new applications and their supporting network services. With NFV and SDN, this type of provisioning and service chaining can be done in minutes.

This kind of flexibility will mean that operators can charge for services on an as-you-go basis without being required to build out excess capacity for traffic spikes and dips. What's more, if Net Neutrality rules remain irrelevant, operators will soon be able to use SDN and NFV to prioritize certain types of content for a higher rate, Sharma said.

Page 104 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Going forward, ALU expects to see even more mobile network functions become virtualized, but it'll be a while before off-the-shelf servers and virtual machines can handle intensive applications, such as video, or replace core routers.

"There is work that needs to be done through the chipset to improve the performance of those platforms," Gulyani said. "We are working with vendors in the chipset space to get it to a place where you can get the performance."

Next article

Page 105 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Brocade Vyatta Platform provides software for NFV data centers

Shamus McGillicuddy, Senior Analyst

Brocade announced a new SDN architecture that will enable network functions virtualization within service provider data centers. At the heart of the architecture is the company's Vyatta software, a virtual router that Brocade is transforming into a platform for delivering virtual network functions.

The Brocade Vyatta Platform will pull together open source and Brocade technologies to provide the network software that service providers will need as they build new data center networks to support NFV initiatives.

"Brocade has done a lot with Vyatta to this point," said Bob Laliberte, senior analyst with Milford, Massachusetts-based Enterprise Strategy Group. "The question is: Do you view this platform as an ending point or just a beginning? They're looking at this as a platform to leverage going forward."

Laliberte expects third parties to develop services and security technologies that run on top of the Vyatta platform, which becomes less of a router and more of an engine for network functions virtualization (NFV) functions. "If you deploy Vyatta and think of it as a platform, what can you deliver on top of that as well in an automated and orchestrated fashion?" Laliberte said.

Page 106 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Service providers will build thousands of NFV data centers Service providers will be building "subscriber clouds, not to host applications, but to revolutionize or modernize the way they provide subscriber services," said Kelly Herrell, vice president and general manager for Brocade's software networking business unit. "As the telcos build out all this infrastructure in more regionalized areas, it's not just about producing one big mega data center. They'll use their central offices and other small facilities for smaller data centers. The number of data centers is going to explode. [CIMI Corp. President and Analyst] Tom Nolle says we could see an additional 30,000 to 100,000 data centers [built to support NFV]."

Brocade sees this as the real near-term SDN opportunity for networking vendors, and it's aligning its SDN efforts accordingly. The Brocade Vyatta Platform includes existing products and open source software from the OpenDaylight and OpenStack projects. The Brocade Vyatta architecture comprises three layers.

• NFV Connection Services: This layer is where the Vyatta software comes into play, including the Vyatta virtual router, virtual firewall and virtual VPN gateway, as well as Brocade's virtual ADX application delivery controller (ADC) -- all of which will be service-chained by the Vyatta platform.

Page 107 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

• NFV Structural Services: This is the traditional SDN control layer. Brocade's architecture calls for using the open source OpenDaylight controller in this layer. Herrell would not comment on whether Brocade would release its own commercial version of OpenDaylight, as other vendors have done.

• NFV Functional Orchestration: In this layer, Brocade will use OpenStack for NFV orchestration with proprietary enhancements. These enhancements include Brocade's Application Resource Broker, a software module and policy engine for Brocade's ADX platform that can automatically deploy ADC resources based on application need. Brocade will also include its Dynamic Network Resource Manager, an extension to OpenStack's Neutron networking framework.

"We've been advancing the technology at each layer. We're offering a platform, rather than a product," Herrell said. "An integrated set of software components that together give you what you are looking for, both in terms of services and management." Brocade will emphasize modularity with its platform. If a service provider wants to use HP or Red Hat's distribution of OpenStack, Brocade will interface with those distributions seamlessly, Herrell said.

Forty telecommunications providers across the globe are running proofs of concept with the Brocade Vyatta Platform, he said.

Page 108 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Brocade knows hypervisor-based network services Performance will be a huge issue in the first generation of NFV implementations, said Peter Christy, research director at New York-based 451 Research. Service providers might find that running high-performance virtualized network functions on hypervisor hosts could be more challenging than it looks.

"One of the things that Vyatta/Brocade really knows how to do is run networking functions in virtualized software, which includes mastery of things like multi-core CPU utilization and getting excellent I/O performance through a hypervisor," Christy said. "So I believe that Vyatta brings important intellectual property and know-how to the party."

Brocade will need to offer concrete information about the ecosystem of third-party vendors who will develop network services that run on top of Vyatta, versus how many network services it will try delivering on its own.

"There still seems to be a bit of ambiguity about the ecosystem," said Brad Casemore, research director for Framingham, Massachusetts-based IDC. "Obviously they have an ADC and a firewall and are developing other pieces. How much will they do themselves, and how much do they intend to do with a platform and an ecosystem of partners? I think they recognize that they will have to be open so customers can p choose the pieces they want."

Next article

Page 109 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Everything you need to know about the VMware NFV strategy

Shamus McGillicuddy, Senior Analyst

We sat down with Bruce Davie, a principal engineer at VMware, to discuss the how the company will enable Network Functions Virtualization (NFV). In this Q&A on the VMware NFV strategy, find out how the virtualization pioneer is optimizing its hypervisor to support NFV workloads and enhancing the service chaining capabilities of its NSX network virtualization software. Also find out how VMware will help telecoms orchestrate NFV services.

Telecom providers are telling you they want lower latency in hypervisors for NFV. How are you approaching this problem?

Bruce Davie: Going all way back to beginning of virtualization, the big question was how much overhead do I have to pay for having hypervisors in the first place, compared to running my workload on bare metal? So we've been optimizing performance for the entire lifetime of the company.

But there are tradeoffs when you turn the latency knob all the way to 11 [in a hypervisor]. You start turning off things that might help you be more efficient, use less power, get higher throughput. So, you can't say I want my hypervisor to be low latency and that's that. You have to say for some workloads, " I'm going to turn the knobs to get low latency and I'm willing to give up some other things to get that."

Page 110 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Improving latency or any kind of performance is always about finding the 10 little things that are each taking up a little bit of the budget and finding ways to improve them. There is no single magic bullet to get low latency.

A prototype we have worked on turns the latency as far as you can turn it to try get 100%, with worst case latency down to [the] 20 microsecond level. That's what I would call the extreme latency cases for something like nuclear reactor control, where you would make that choice rather than having other tradeoffs like efficiency or throughput.

We've made huge advances from ESXi 5.1 to 5.5. We have code that's written but not yet shipping that makes more advances.

What are the tradeoffs associated with pushing down latency in the hypervisor?

Davie: Take interrupt coalescing as an example. Normally, [a hypervisor] coalesces interrupts. Instead of the first interrupt coming and waking up the CPU, you can take several interrupts together and then wake it up. That's good for efficiency, but not so good for latency because that first interrupt had to wait for the next couple of interrupts. By coalescing interrupts, you do effectively less work per interrupt, but latency is worse. You turn it on and you get better efficiency, and if you turn it off [there is less latency]]. So, we give people the knob to make that choice. And efficiency and throughput can be kind of related because if you are inefficient, you are ultimately burning CPU cycles that might have been used for doing something else, like throughput.

Page 111 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Telecom providers have also requested higher throughput for small packets. Could you describe this problem?

Davie: You have to do a certain amount work on any packet, independent of how large it is. When you are doing large packets you can get a lot of throughput by doing relatively few packets per second. What happens with small packets is, you are still doing the same number of packets per second you were doing with large packets, but your throughput is going down because the number of bytes per packet is going down.

That's the kind of thing where you look at all the operations that you do on a per-packet basis, as opposed to per-byte basis. For us, it's mostly about providing enough [throughputs] to fully utilize all the resources on the server. It's really hard for an x86 machine to compete against a router full of ASICs, which is why there will be hardware vendors building switches for the foreseeable future.

In the NFV environment, you've got a server that has compute, networking, I/O -- a whole lot of things. And you want make sure you are using them all efficiently. A good use of that server would be [a] CPU running at 100% and a NIC that is loaded to 100%. Exactly how you get there depends on what workload you are running on the CPU. [In tests we have discussed at VMware], the CPU operation was trivial. It would receive the packet and transmit the packet. So there is not much useful computation being done. A much more likely thing would be the thing running inside the guest OS is actually a firewall or evolved packet core function which is doing quite a lot of computation on each packet. So you want that CPU to be completely busy and to be able feed packets to it fast enough to keep it busy.

Page 112 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

We're able to get to 4 million packets per second range for short packets in the next release. That would keep a lot of CPUs busy for a lot of [NFV] applications.

How does NSX contribute to the VMware NFV strategy?

Davie: The thing where there is the most interesting work to do is around service chaining. We have some good capabilities today, but we definitely have some thoughts on what we could do to be more powerful in that area.

There are only a very small number of things you can do conceptually for service chaining. I think the most important thing is that you need a system for creating abstract topologies to interconnect the virtual network functions, which is exactly what NSX does.

Essentially, a service chain is a topology of services, and NSX creates virtual topologies to interconnect VMs, which is a very fine place to run your virtual network functions. Traditionally, people might have done it with things like VLANs, just like people did things like segmentation with VLANs. Obviously we view NSX as a much better solution for building these topologies in a programmatic way.

The second thing you need for a service chain is a metadata channel to pass information from one point in the service chain to another. A good example here is that maybe the first block in a service chain gets a whole lot of information on what handset initiated a call and what the user's profile is. Some kind of classification goes on at the start of the service chain.

Page 113 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

[You] end up with this index that tells you that this user belongs to class 732 and somewhere down the chain I'm going to do something special for this user because he belongs to that class. He'll get to the video optimization stage of the service chain and I'm going to give him the premium video optimizer

You need to pass that metadata along the chain so the classification needed back here can be leveraged by some other function further down the chain. There is really only one place to put the metadata. You've got to put it in a packet header that travels with the packet. But, it probably doesn''t need to be in the packet itself because you don't want to modify the user's packet [and] given that [NSX] encapsulates packets in a virtualization header, that's the perfect place to put it.

We've recently published an Internet draft about an encapsulation header called GENEVE. GENEVE is effectively VXLAN plus flexible option [fields]. So those flexible options give you a great place to put metadata. You can think of that metadata as being something that the virtual network function at [the] beginning of the classification could write into the [GENEVE option field]. It travels along with [the] packet in [an] encapsulation header. It's handed off to another virtual network function that can now read that metadata and do something scheduled for the packet based on that.

Is this something that's possible to do in VXLAN but is better to do in GENEVE?

Davie: It's less obvious where you could put that in VXLAN. I was talking to somebody who had done it by putting it in an IP option.

Page 114 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

You do run out of places to put it if you are in a fixed header. One thing people have talked about doing is carrying a VLAN header along with the packet inside VXLAN. It's not ideal because it's still a pretty short field.

Are there other VMware NFV initiatives you can share?

Davie: The other place where there is a big piece for VMware to play in NFV is around orchestration. That's where I see the least maturity in terms of products. People are kind of doing demo level orchestration at the moment. That's an area where we could leverage some tools we have and do things through OpenStack to provide some validated capabilities.

You mentioned there are NFV trials happening with your hypervisor. Are you seeing any uptake of NSX?

Davie: The NSX team gets pulled in to discuss many of these NFV trials, in part because of the recognition of needing some of what NSX brings, and also because we're the networking team and they want that expertise.

But some pilots are so small that the agility benefits of NSX are less necessary. You can get away without agility when things are really small-scale. As people are planning their bigger pilots, I think that's where they will see the benefits of having an automated network virtualization component.

Are you building relationships with virtual network function vendors?

Davie: We've been building relationships with virtual network function vendors for a long time.

Page 115 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

If you asked anybody from VMware what our NFV strategy was a year ago, it would mostly [have] been around partnerships with traditional network equipment manufacturers.

What's the timeline on delivering a hypervisor that is ready for NFV?

Davie: I would say the hypervisor is ready today for a lot of telco applications. Part of the challenge is you have to really validate solutions [to] make the latency requirements on applications. I think with the low latency settings in ESXi 5.5, we can meet the requirements for of a lot of NFV applications, [including evolved packet core and customer-premises equipment].

Are there areas of NFV that remain a challenge for your hypervisor?

Davie: Virtualizing the radio access network is one that we view as a pretty tough latency challenge. It's kind of in the same category as high-frequency trading. I think [VMware CEO] Pat [Gelsinger] has said he wants 100% of applications to be virtualized. He's put the stake in the ground, like Kennedy saying we're going to the moon in 10 years. I think we can meet those numbers, but they do require some fairly extreme tuning of the hypervisor that would produce some other downsides. So virtualizing the radio access network is something we see as being a little way out for us at the moment.

Next article

Page 116 of 117

In this e-guide

Section 1: The ins and outs of NFV p.2

Section 2: NFV roadblocks p.16

Section 3: NFV upsides p.41

Section 4: How SDN and NFV work together p.53

Section 5: Tangible NFV p.73

Getting more PRO+ essential content

E-guide

Getting more PRO+ exclusive content This e-guide is made available to you, our member, through PRO+ Offers—a collection of free publications, training and special opportunities specifically gathered from our partners and across our network of sites.

PRO+ Offers is a free benefit only available to members of the TechTarget network of sites.

Take full advantage of your membership by visiting http://pro.techtarget.com/ProLP/ Images; Fotalia

© 2016 TechTarget. No part of this publication may be transmitted or reproduced in any form or by any means without written permission from the publisher.

Page 117 of 117