virtualizing network functions hb final

15
EDITOR’S NOTE NEW MANAGEMENT MODELS NEEDED FOR NFV HOW TO FINE-TUNE YOUR RFP PROCESS FOR NETWORK FUNCTIONS VIRTUALIZATION NETWORK FUNCTIONS VIRTUALIZATION: A PRIMER Virtualizing Network Functions: Could NFV Mean Network Nirvana? NFV promises both network savings and streamlining, but first you need to understand the technology and how to procure the configuration that works best for your network.

Upload: randy-dookheran

Post on 24-Dec-2015

16 views

Category:

Documents


1 download

DESCRIPTION

Virtualizing Network Functions

TRANSCRIPT

Page 1: Virtualizing Network Functions Hb Final

EDITOR’S NOTE NEW MANAGEMENT MODELS NEEDED FOR NFV

HOW TO FINE-TUNE YOUR RFP PROCESS FOR NETWORK FUNCTIONS VIRTUALIZATION

NETWORK FUNCTIONS VIRTUALIZATION: A PRIMER

Virtualizing Network Functions: Could NFV Mean Network Nirvana?NFV promises both network savings and streamlining, but first you need to understand the technology and how to procure the configuration that works best for your network.

Page 2: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 2

EDITOR’SNOTE

Could NFV Be the Network’s Holy Grail?

The scene: Late 2012. Global network operators feel the urge to add a new acronym to the already impressive list that rules their industry.

The result? NFV is born. Network functions virtualization is the effort to virtualize net-work equipment onto switches, servers and storage to reduce network cost and complexity. NFV does much more than satisfy that new-acronym itch. With incredible potential to save on capital equipment and network operations costs, as well as reach the holy grail of manag-ing legacy network components and virtual resources as one, NFV has quickly entered ser-vice provider lexicon.

This TechGuide provides you with the background you need to move forward with NFV. First, CIMI Corp. president Tom Nolle looks at the network-management aspects of NFV and discusses needed changes to exist-ing systems, with an emphasis on managing an

entire network service, not individual devices. He looks at both the options and the cast of characters in a position to make the needed changes.

Then Nolle lays out how telecom providers should go about procuring NFV in a Request for Proposal because standard RFP templates just won’t cut it. Network operators are anx-ious to deploy NFV, but they need to ask additional questions if they hope to reap its benefits. Nolle outlines the steps to create an NFV ecosystem that works.

Finally, for anyone who needs a short-and-sweet holistic look at NFV (and who doesn’t?), David Jacobs offers a primer on where NFV came from and how it works—an essential read no matter where you are in the NFV-deploy-ment process. n

Kate GerwigEditorial Director, Networking Media Group

Page 3: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 3

NEW MODELS

New Management Models Needed for NFV

When a cadre of giant global network oper-ators 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 capi-tal 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 opera-tions, 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 the 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.

WHY VIRTUAL NETWORK FUNCTIONS CAN’T

BE MANAGED LIKE TRADITIONAL 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 serv-ers 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” a current network man-agement system (NMS) and OSS/BSS by offer-ing 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

Page 4: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 4

NEW MODELS

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.

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 two, 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 func-tion components, virtual machines or contain-ers for hosting, etc. That means that every NFV virtual device is really a system of cooper-ating 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 appli-ance—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.

The problem with this approach is that we already have NMS, OSS and BSS 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

Page 5: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 5

NEW MODELS

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 consid-ered here is less what needs to be done opera-tionally 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 manage-ment that contrasts with the single-level prac-tices 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.

This model fits both the evolving NFV speci-fications 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’S RESPONSIBLE FOR BUILDING A

MANAGEMENT MODEL BEYOND OSS/BSS?

Something that lies between OSS/BSS 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 manage-ment models. The problem is that functional

What’s being described in either the “inside” or “on top of NFV” situations is a two-level process of orchestration and management.

Page 6: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 6

NEW MODELS

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 Open-Stack, to the IETF, the International Tele-communications 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.

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. —Tom Nolle

Page 7: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 7

RFP PROCESS

How to Fine-Tune Your RFP Process for Network Functions Virtualization

Many of the world’s telecom providers are so serious about network functions virtual-ization that they’re already starting the pro-curement process for the technology so they can decouple specific network functions from proprietary hardware appliances and run them in software. In most cases, procuring NFV will involve soliciting one or more requests for information (RFIs) or requests for proposal (RFPs).

The cautionary note is, however, that in many cases, the RFIs and RFPs won’t elicit the information the buyer actually needs. This is because an NFV request needs to be a mix-ture of typical RFI/RFP processes, as well as an exploration of the special issues and special risks of NFV.

In general, all RFIs and RFPs should begin by clearly delineating the business goals the pro-vider is trying to meet, then align those goals with NFV deployment. The model—that is, the

provider’s NFV RFP—must identify all of the necessary components of an architecture that will realize the benefits. The RFI or RFP should then solicit information needed to defend the key architecture assumptions and ask for sug-gestions on how to improve the project as outlined.

Some operators have a standard form for RFIs and RFPs, and this can be a good starting point as long as these general issues are addressed, and the special issues of NFV are properly developed.

Keep in mind that NFV poses a special risk in the area of benefits and deployment scope. Most operators looking at NFV admit that their views have changed in terms of how NFV will benefit them in the future. The initial goal of NFV was to reduce capital expenditure (Capex) by substituting low-cost software hosted on commodity servers in place of higher-cost custom network hardware devices. But most

Page 8: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 8

RFP PROCESS

operators don’t believe that using NFV will lower Capex enough to help the bottom line.

Carriers are now looking for a combination of lower operations expenditures and improved service revenues. Since service agility or opera-tions efficiency are typically developed end-to-end, this change raises the risk that an NFV project will affect too small an area of a service to make a significant difference.

STEPS TO PLOT OUT YOUR NFV

ECOSYSTEM DEPLOYMENT

Even in this early stage of NFV trials, we already know that the lack of appropriate scope to meet expected benefits is the number one problem found in RFIs and RFPs.

The best way to ensure your benefits and NFV project scope align is to draw three dia-grams. The first should show you infrastructure as it is today, the baseline state. The second diagram should show your vision of what a complete NFV deployment would look like, and the third should show what a credible interme-diate state like a field-trial configuration, could look like.

Focus on what changes in the three diagrams, because changes will create both your benefits and your costs. If you propose to reduce the total cost of ownership for VPN infrastructure by 30%, for example, and you have drawn dia-grams that show less than a fifth of your infra-structure is actually affected by the NFV model, then your benefit case is unlikely to be met.

NFV is an ecosystem, and in fact it is being standardized as an open ecosystem. That means you’ll need to call out a complete NFV ecosystem in your RFI or RFP and get specific responses for everything in it. The easiest way to do that is to remember that there are three pieces to NFV. You’ll need to get information on each one.

■n The virtual network functions needed. Does the vendor provide them, are they available from third parties, or is there another option? Are they open-source or licensed, and if they are licensed, what is the cost? It is critical to understand the sources of the virtual network functions because your future services will depend on getting their features from some specific source.

Page 9: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 9

RFP PROCESS

■n The infrastructure on which the functions run. What specific server, operating system and middleware combinations are needed, and what are the terms of their availability and support? The best cost points are reached with commodity platforms, but some cus-tomization of hardware and software for com-munications performance may be worth the cost.

■n The management and orchestration (MANO)

software that automates the virtual network

functions deployment and supports lifecycle

management. MANO is an area of special concern because most NFV solutions don’t actually include all of the tools needed to manage a service that includes NFV elements on an end-to-end basis. That makes it harder to realize overall gains in operations effi-ciency or service agility.

You need to understand how these parts go together, and it’s tempting to simply reference the NFV ISG architecture of the European Tele-communications Standards Institute. This isn’t sufficient at present because the standards

are not complete. In addition, risks are always associated with “standard approaches.” Vendors may support the standards but extend them and use their extensions in their implementa-tion of one or more of the three areas above. This can create silos of proprietary NFV that will weaken integration and make it harder to unify service creation and operations.

HOW TO HANDLE SUGGESTED VENDOR

CHANGES TO THE NFV RFP PROJECT

The final issue is that of suggested changes to the project. Most operators believe that they should ask vendors for suggestions or improve-ments, but this can turn an organized RFI or RFP into a series of responses so different that they can’t be compared to a single standard or to each other. It’s best to offer a presumptive model that will meet your goals and require that all who respond offer responses based on that model first. Then they can suggest alternatives.

If you allow vendors to propose modifica-tions or extensions, require that they produce the three diagrams in their proposals so you

Page 10: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 10

RFP PROCESS

can compare their suggestions to your base case more easily. That also helps induce the vendors to propose complete alternatives and not just isolated tweaks that might have pro-found implications.

It’s a matter of policy whether you want to consider a vendor that proposes extensions and declines to provide a solution for your own base case. If you’re confident in the value of your approach, you should consider this non-responsive. If you don’t, you may have to reissue your document in order to allow the variation to be fair to all vendors and to solicit the largest base of solutions.

The most important thing to remember

about NFV is that it will rarely displace all your legacy infrastructure. Currently, opera-tors believe that in full deployment, software-defined networking and NFV combined would make up between a fifth and a third, respec-tively, of their network infrastructure.

An extensive NFV deployment is likely to demand harmonizing your technology choices at a higher operations level to secure efficient service creation and continuing operations. Since those are the two things now seen as the prime benefits of NFV, a top-down and com-plete NFV project has to be the goal, or there’s a risk you’ll have no NFV project at all. —Tom Nolle

Page 11: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 11

NFV PRIMER

Network Functions Virtualization: A Primer

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 gate-ways. 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 ser-vice 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 lat-est generation of processor chips and network interfaces to reduce or eliminate the need for

traditional, dedicated network devices.While software-based routers and switches

have been available for many years, moving network functions to servers in high through-put networks was not possible with previous generations of processors and network inter-faces. 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 pro-vide greatly increased throughput and process-ing capability because they’ve been optimized to support virtualization. Newer processors contain multiple cores to spread the load across multiple virtual machines and applications. Additionally, adapters include hardware fea-tures that support multiple 10 GbE interfaces, while offloading tasks previously done on the processor. Per core packet queues and adapters

Page 12: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 12

NFV PRIMER

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 com-plexity. Though carriers and service provid-ers have led NFV efforts, the technology helps any enterprise with a vast network and a wide diversity of functions.

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 rap-idly 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 func-tions virtualization, a server that is a firewall today can be a VPN gateway tomorrow with just a shift in software.

NETWORK FUNCTIONS VIRTUALIZATION

OFFERS FLEXIBLE SOFTWARE

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 func-tions 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. New concepts in network soft-ware can come from the open software commu-nity, from academia or from minimally funded

Page 13: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 13

NFV PRIMER

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 sim-plify operations in a network functions virtu-alization 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 opera-tion of network hardware devices, it can just as easily integrate into an NFV environment,

communicating with software-based compo-nents on commodity servers. What’s more, these servers and software can be designed to be OpenFlow-friendly, unlike many existing hardware switches.

NFV CHALLENGES NEED SOLUTIONS TO EVOLVE

Multiple challenges must be resolved for the NFV concept to be widely adopted:

■n A standardized interface must be developed between virtual appliances and the underly-ing hardware and hypervisor to make appli-ances portable across different operators’ or enterprise networks.

■n Testing is still required to determine the performance penalty that occurs due to replacing specialized devices with commod-ity servers. (The penalty can be minimized by choosing appropriate software, according to the proposal’s authors.)

■n A migration path must be developed to enable NFV implementations to coexist with

Page 14: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 14

NFV PRIMER

existing management infrastructure and with legacy network equipment.

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

■n Automation services must be developed for NFV implementations to scale.

■n 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.

■n 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.

■n 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 Specifica-tion Group (ISG) has been formed within the auspices of the ETSI to address existing chal-lenges. Several computer and network equip-ment vendors have joined with the service providers to advance this initiative. Plans also call for working closely with the Open Net-working Foundation as it continues to accel-erate the adoption of SDN technologies and standards. —David B. Jacobs

Page 15: Virtualizing Network Functions Hb Final

HOME

EDITOR’S NOTE

NEW MANAGEMENT

MODELS NEEDED FOR NFV

HOW TO FINE-TUNE

YOUR RFP PROCESS

FOR NETWORK FUNCTIONS

VIRTUALIZATION

NETWORK FUNCTIONS

VIRTUALIZATION:

A PRIMER

VIRTUALIZING NETWORK FUNCTIONS: COULD NFV MEAN NETWORK NIRVANA? 15

ABOUT THE

AUTHORS

TOM NOLLE is president of CIMI Corp., a strategic consult-ing firm specializing in telecom and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecom strategy issues.

DAVID B. JACOBS of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.

Virtualizing Network Functions: Could NFV Mean Network Nirvana?

is a SearchTelecom.com e-publication.

Kate Gerwig | Editorial Director

Rivka Gewirtz Little | Executive Editor

Kara Gattine | Senior Managing Editor

Jessica Scarpati | Features and E-zine Editor

Brenda L. Horrigan | Associate Managing Editor

Linda Koury | Director of Online Design

Neva Maniscalco | Graphic Designer

Doug Olender | Senior Vice President/Publisher [email protected]

TechTarget 275 Grove Street, Newton, MA 02466

www.techtarget.com

© 2014 TechTarget Inc. No part of this publication may be transmitted or re-produced in any form or by any means without written permission from the publisher. TechTarget reprints are available through The YGS Group.

About TechTarget: TechTarget publishes media for information technology professionals. More than 100 focused websites enable quick access to a deep store of news, advice and analysis about the technologies, products and pro-cesses crucial to your job. Our live and virtual events give you direct access to independent expert commentary and advice. At IT Knowledge Exchange, our social community, you can get advice and share solutions with peers and experts.

COVER ART: THINKSTOCK