CloudNFV™ unites the

best of Cloud
Computing, SDN and
NFV
An open platform for implementing Network Functions Virtualization (NFV) based on cloud
computing and Software Defined Networking (SDN) technologies in a multi-vendor
environment
We have a network today - the Internet - that spans the globe and has even Founding members of the
extended into space. There are challenges in making all of the roles of this
enormous collective undertaking profitable enough to guarantee full CloudNFV initiative include:
participation, and there are a lot of “revolutions” that have promised to help—
the cloud, software-defined networking (SDN), and most recently, network
 6WIND
functions virtualization (NFV). There are many things we don’t know yet about  CIMI Corporation
these new concepts, but one thing we do know is that they can’t make the
network of today any less pervasive, useful or powerful than it is now.  Dell
Progress means moving up, not falling back.
 EnterpriseWeb
Network functions virtualization is potentially the unifying revolution of the
three, the thing that combines the cost management initiatives needed by  Overture Networks
operators, the revenue opportunities needed by everyone in the services  Qosmos
value chain, and the experiences that will dazzle our grandchildren even more
than our current experiences have dazzled us.

Hosting network functions in the cloud is a step toward unifying the network Click on a company name above
and information technology forever, creating a seamless mesh of technical to view a summary of their
elements that support every conversation, every transaction, every participation in CloudNFV
experience. All we have to do is take the opportunity that NFV presents us
and go forward with it, to expand
from managing costs to creating
To virtualize anything profitable experiences. The cloud
effectively, we have to virtualize shows us how to go beyond NFV,
how to take the first step toward
everything from resources to our dazzling goal.
services to functions… even to
One step doesn’t climb all the way
the users themselves. That’s to the future, though. NFV is
another example of how the most
the big step because infinite general concept of virtualization –
flexibility is only a short the transformation of abstractions
into realizations – can change
distance from chaos. everything about technology. If we
are to get to that utopian cloud of
tomorrow, we have to embrace
that definition of “virtualization,” not just fill in the stress cracks virtualization
creates. To virtualize anything effectively, we have to virtualize everything
from resources to services to functions… even to the users themselves.
That’s the big step because infinite flexibility is only a short distance from
chaos.

CloudNFV is aimed at taking both steps. You’d never believe us if we said

that we had the final answer to the unity of cloud, SDN and NFV. We’re not
saying that. We’re not saying that we have the vision of a future where
“everything is virtual” down pat either. We’re staying that we’ve tackled both
problems head-on. What we have set out to do is to create a framework that
demonstrates that such unity is possible and that it can be made profitable.

Like the Internet, CloudNFV is open. It’s not a company that’s going to sell
itself for a big payday or a forum that’s going to charge for membership. It is
an architecture supported by an open partnership. Everyone is welcome, and
while we obviously can’t speak personally with everyone who wants to know
more about our activity, we’re committed to communicating with as many as
we can, using every means available. This document is where we start.

To See Through All Eyes

There are a lot of ways of looking at Network Functions Virtualization.

 It might be aimed at reducing costs or at raising revenues.

 It solves a network problem or builds toward a cloud future.
 It is about deployment of functions or about consistency and economy
of operations.

Which is it? All of the above. This is the age of

virtualization.

You don’t get staked to a single perspective,

you create an architecture that sees everything
– sees through all eyes. That’s what we’ve set
out to do, but to understand how and why, we
have to start somewhere. The right place is the
model established by the formal ETSI Industry
Specification Group on Network Functions
Virtualization. We show that model in Figure 1.

Through ETSI NFV eyes, this is about moving

features from high-cost to low-cost
infrastructure. Functionality, now resident in
specialized appliances, is extracted in some
way and replicated in virtual form by an
independent software vendor or the appliance
vendor. When services are needed, these
components are assembled (or orchestrated)
and deployed on servers. The NFV plan is to
support everything from bare metal to an
architected cloud as a hosting platform. Once Figure 1. The Foundational Goal of Network Functions Virtualization
deployed, they are managed so as to create as
good of a service experience as the original
devices would have created.

OK, fine, but let’s look at this through our carrier regulatory attorney’s eyes.

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 2
Did you put your virtual functions in places that regulations might inhibit? Are
you exposing users to content regulation or lawful intercept issues? Clearly,
we need some policies in place to guide where virtual functions are deployed
and how they’re connected. It’s not just a matter of finding a technically
suitable server. Deployment is complicated.

Look now through the eyes of the vice president of operations.

What happens if the server hosting the function fails? Do I “reroute” through
another virtual function I created on standby? Do I spin up another VM and
load another copy? How do I reconnect all this? What happens if a portion of
the local electric grid failed, and my backup is in the same substation zone as
my primary? We need more policies, because operations and management is
complicated.

All of this complexity can add up. We know that virtual routing works and that The NFV plan is to support
it can save on CapEx. But, let’s look at this through another set of eyes, that
of a carrier CFO. everything from bare metal to
Will the capital cost savings created by moving to virtual functions hosted on
an architected cloud as a
servers be eradicated by more complex operating processes as we scale out hosting platform. Once
to more virtualization? How do we even manage this new virtual stuff? Where
did we put that function anyway and how do we know how it’s behaving? deployed, they are managed
Even applying all of those policies that we just mentioned could be costly so as to create as good of a
enough to jeopardize capital savings.
service experience as the
Our CFO eyes would also see the problem with investing to cut costs – in
original devices would have
many ways, that’s a contradiction in terms at best. Why not try to get new
revenue? A. whole industry has grown up riding on “Internet dialtone” after all, created.
and operators should be able to not only compete, but win in such a business
model—if they have the right tools. Most of them are already committed to
investment in the cloud, so why not try to harmonize that cloud investment
and a new network architecture and support revenue gains as much as
manage costs?

It’s time for another set of eyes here, that of the high-level architect.

When such a person looks at Network Functions Virtualization, they see what
Figure 2 shows—a trio of critical elements. We have the “network functions”
that represent the logic to be deployed and assembled into services; the
“functions virtualization” that
represents the logic that
deploys and connects the
virtual functions; and the
“operationalization” – the
logic that keeps everything
running and does the billing
and business functions.

This is the NFV ecosystem

at the highest level. An
ecosystem that is defined by
the ISG’s work, but that has
to be implemented as a
software project to make this
happen.
Figure 2. The Three Pillars of NFV

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 3
Our high-level architect would say, without hesitation, that what’s needed is a
running prototype of NFV, something that could test the basic assumptions
and perhaps even test different approaches. This architecture should also
integrate with SDN and the cloud, our other two revolutions.

At the April 2013 NFV meeting in Santa Clara, a group of six companies With CloudNFV there’s a
agreed to work toward building such a prototype as an open platform to
validate and explore NFV issues and assumptions. We called that platform
simple goal – make every
CloudNFV because it was architected – from its inception – to make network application that can run in the
functions into cloud components.
cloud into a potential virtual
We all saw CloudNFV as function. Cloud computing
it’s depicted in Figure 3–
a stack of futuristic and NFV are one.
technologies combined
to create a new network
model. NFV principles
from the ETSI ISG are
translated into hosted
Figure 3. CloudNFV is a Stack of Technology functions using cloud
Revolutions computing principles—
OpenStack to be
specific. With CloudNFV there’s a simple goal –make every application that
can run in the cloud into a potential virtual function.

Cloud computing and NFV are one.

So are CloudNFV and SDN, CloudNFV and OSS/BSS.

The network connections between functions and with users are created using
SDN. Management is accomplished through a data/resource model structured
according to TMF rules but optimized for virtualization and the cloud. We took
this approach deliberately to create a harmony of revolutions – to build the
greatest benefit case while gaining the most in terms of economies of scale
and operations.

CloudNFV answers all the questions we posed

above in what we think is always the best way to
address complex things—through simplification.
The basic CloudNFV architecture, shown in Figure
4, does everything that the ETSI model currently
defines. And, it does it through a combination of an
abstract data model, optimized cloud deployment
of network functions, and the best
hardware/software platform available to maximize
reliability, availability, performance, and
management/operations.

Browsing Through CloudNFV

If you follow along on Figure 4 for a moment, we
can show you the way CloudNFV works.

Every aspect of services, functions, and resources

is represented in a universal, agile, data model we
call “Active Virtualization.”
Figure 4. The CloudNFV Architecture

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 4
More on that later, but let’s start by saying that in the Active Contract portion
of our repository, we have a series of Service Templates that represent
structures of network functionality that can be ordered. Think of them as
abstract maps—cookie-cutter frameworks that stamp out the service when
somebody orders it. When that happens, the order process picks the correct
template and fills in any variable parameters (service locations, QoS,
whatever), creating a Service Contract. It’s like an order for a bicycle. You
specified the variables, like color and seat and trim, but all the rest of the
process is standard. So far, this process is pretty much how service ordering
works with real networks.

When an order is complete, we find that some of that order requires virtual
functions to be deployed, and that component of the order is then dispatched CloudNFV is about a
to the NFV process called “Orchestration.” Here, we use policy rules and
resource status from Active Resource to pick the best spot to put all these harmony of revolutions,
virtual functions, and also how to connect them using virtual networking. We a harmony of
call the combination of the where-to-host and how-to-connect instructions a
manifest. This manifest is given to OpenStack, which uses its Nova compute standards, a harmony
APIs and Neutron networking APIs, to create the NFV component of the
of vision. It isn’t a new
service on real cloud resources using real network connectivity to link its
pieces and link the whole service to the user. standard. It’s a fusion
When the virtual functions are deployed and connected, the resources all of the standards that
report their status and traffic to Active Resource and management processes we all believe are
running against Active Resource let you either reflect the result of your
deployment as a bunch of virtual devices with familiar MIBS that support driving the industry. It’s
current management systems, or create your own completely new and not limited to NFV. It
streamlined management processes.
creates a framework to
Whichever route you pick, your virtual management state is derived from the
real status of real hosts and real networks. We call these “derived operations,” deploy legacy services
in fact, and we have structured the data model of Active Contract to reflect the based on legacy
TMF SID (GB922) description of Services, but also to reflect how applications
really deploy in the cloud. That’s what makes real-time virtualization-based devices or to deploy
management possible. software-as-a-service
So there you have it, at a high level. CloudNFV is about a harmony of in cloud computing.
revolutions, a harmony of standards, a harmony of vision. It isn’t a new
standard. It’s a fusion of the standards that we all believe are driving the
industry. It’s not limited to NFV. It creates a framework to deploy legacy
services based on legacy devices or to deploy software-as-a-service in cloud
computing. It isn’t a different approach to NFV, it’s an optimized approach to
the requirements that the ETSI ISG are
Yes, this is a proof of creating. All of us are members of the ISG,
concept, but it’s a proof and everyone who wants to integrate with
of a very broad concept. us in the future will have to be a member
We invite you to join to prove their commitment. We’re also
coordinating our activity with the TMF
us—no fees, no because we believe the TMF service
pressures, just framework is critical to integrating
cooperation to advance CloudNFV into effective operations
the three critical practices, particularly as we transition
concepts of cloud, SDN, between real and virtual devices.
and NFV as a single CloudNFV isn’t a product. It’s proof that
and open effort. NFV can be implemented as an open
concept, instead of a proprietary monolith.

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 5
Finally, it’s not a point solution, but an element in a global grid. CloudNFV can
run in any – and every – carrier data center or any OpenStack-compatible,
optimized, commercial off-the-shelf server and create a cohesive global
service framework. It can also federate with other compliant NFV platforms
and even with cloud computing. Yes, this is a proof of concept, but it’s a proof
of a very broad concept.

Finally, and foremost, CloudNFV is open to broad participation. We’ve created

interface points that align with the ISG’s architecture, but we’ve also provided
a mechanism for customization of management and infrastructure integration
that goes beyond current ISG work. Subject to resource availability and
approval of an integration plan, we’re happy to work with other ISG members
to create an even broader platform, both geographically and technologically.
We invite you to join us—no fees, no pressures, just cooperation to advance
the three critical concepts of cloud, SDN, and NFV as a single and open
effort.

Hungry for More?

If this provides you enough of an understanding of CloudNFV, you’re
welcome to stop here. If you’d like a little more detail, we’ll have to jump off
our Figure 4 in two directions: one to show how we assemble virtual functions
into services and the other to show how our pieces connect with each other,
and with future integration partners in the project.

If we dig just a bit deeper into Figure 4, we can demonstrate our vision of
contract-driven management. Active Contract records the resource
commitments associated with a given set of virtual functions. When we want
to manage an NFV-based service, we do so by integrating the resource state
from Active Resource with the resource commitments made in Active
Contract. We call this “derived operations” because in a virtual world there are
no real devices and so there are no meaningful MIBs.

In our Active Contract service template, we identify a “Management

Visualizer” at every level of a service – retail down to individual virtual
functions. This Visualizer draws
information from Active Resource to
frame the management view
appropriate to that point in the
structure (at the service level, you
might have a red/yellow/green light
dashboard). When the service is
deployed, the Management
Visualizer can see from the Contract
what resources are used and it
knows how to derive the right
management view.

All of this is based on a “Service”

model taken from the TMF SID
GB922 framework we referenced
earlier, but that we’ve adapted for
NFV use as shown in Figure 5
Starting at the bottom, the NFV ISG
defines the individual, hostable,
elements of a service as “Virtual Figure 5. CloudNFV Service Hierarchy and the TMF Connection

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 6
Network Function Components” or VNFCs. Each of these has an associated
descriptor (a VNFD) to define the rules of hosting and connecting for that
particular function. When a service is created from virtual functions, it’s built
upward from these VNFCs as the figure shows. Our first “assembly” of
VNFCs is what we call a package, a term taken from cloud and Linux
deployment to describe a collection of application components that are
deployed as a unit.

VNFCs have interfaces, but packages have instructions on how those

interfaces are to be connected, both among the VNFCs in the package and
with external structures and users. Package descriptions define how these
connections are made thereby defining the interfaces that packages expose
up the line. Right now, what we call packages i the high end of what the NFV
ISG defines.

To get the rest of the way to services, we’ve jumped at our next level to TMF
GB922 terminology. A Resource-Facing Service is a collection of one or
more packages that map to specific current TMF or TMF-linked OSS/BSS
processes. RFSs, like packages, treat what’s in them as a collection of
exposed interfaces to be connected. To CloudNFV, the process of connecting
those interfaces is symmetrical from packages all the way to the retail top of
the chain. RFSs can be linked with commercial terms and commercial SLAs
to create Customer-Facing Services, and it is these services that combine
to create the retail service offering that we call a Retail Service and that the
TMF calls a “product”.

We can now express

our management model
more in terms of this
TMF-inspired structure,
and that’s shown in
Figure 6. When a
service is created, it’s
built from a Service
Template stored in
Active Contract and
filled in by the customer
or order entry process.
The template then
becomes a Service
Contract whose
structure of CFSs,
RFSs, packages and
VNFCs matches that
template. The Contract
is sent to CloudNFV’s Figure 6. "Derived Operations" and Management Model
Orchestration and
Management process for handling, and there we do a sophisticated policy-
and-resource-state analysis to determine where we need to site the VNFCs --
specifically in which VMs in the cloud they’ll be hosted. We also determine
how their interfaces will be connected by real services. When we have both of
these, we have that Manifest of deployment instructions that will process
through OpenStack (Nova for compute, Neutron for networking, etc.) to
deploy and connect the service as though it were a componentized cloud-
hosted application. The completion of package deployment means that
connection process simply moves up the ladder through RFSs and CFSs until

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 7
we have connected the final service end-to-end. The resource commitments,
you’ll recall, are stored in Active Contract as we go along.

When somebody wants to manage the Contract, they start with the Contract
itself (which provides the customer context, SLA objectives and resource
commitments) and use the Management Visualizers at each level of the
structure to view (and potentially alter) the variables that were deemed
appropriate to that particular structure. Each retail service, CFS, RFS and
package can define its own management view, but there are other
management options we’ll get to in a bit. A Management Visualizer has
instructions for both derivation of the variables it presents (where they come
from in Active Resource and how they are aggregated into a virtual vision of
status), and the presentation of those variables in terms of both format and
API. You can have any management derivation and presentation you like – a
-- just use a Management Visualizer to create it. You can also define multiple
presentations of the same derivations, etc. Everything is virtual, remember?

Let’s close our deeper look with an implementation-and-integration vision of

CloudNFV, which we show in Figure 7. Here, we start with two collections of
“stuff” – the collection of service information, virtual function information,

Figure 7. An Implementation Model of CloudNFV

implementation policies and the collection of service infrastructure/resources.

These two collections are connected to CloudNFV through Visualizers (as you
likely guessed) and form Active Contract and Active Resources, which are
themselves simply “visualizations” of our grand collection of information and
knowledge that we call “Active Virtualization.”

All of CloudNFV’s processes and functions are driven from Active Contract,
Active Resource, or both, gaining their information and functionality needs
through Visualizers that can build data models or process models equally
well. We optimize deployment using Visualizer data. We pass Manifests to
Orchestration through a Visualizer and when we manage something (real

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 8
resources, virtual resources, services, or just convenient and arbitrary
collections of things), we do so through Visualizers. If you want to integrate
with CloudNFV, you can bet that you’ll be using Visualizers to do it, too.

So who does all of this? Our next step is to introduce the companies who
have implemented the CloudNFV vision. First, we’ll take a look at Figure 8in
terms of who does what, and then we’ll let each of the companies frame their
participation in their own way.

The CloudNFV Team

CloudNFV is a cooperative project. Involved companies are listed in
alphabetical order below and illustrated in Figure 8.

6WIND provides high-performance data plane software that accelerates the

performance of NFV deployments. As the number one supplier of high-
performance networking software for telecom infrastructure implemented
today on physical platforms, 6WIND is well-positioned to also solve the data
plane performance challenges for virtualized solutions. Within CloudNFV, the
6WINDGate™ software is used in two places. First, it accelerates the Open
vSwitch (OVS) that switches network traffic to the Virtual Networking
Functions (VNFs). Second, it accelerates the VNFs themselves.

CIMI Corporation is the architect of the CloudNFV concept, the source of the
high-level design and the assembler of the team. Tom Nolle, president of
CIMI, is a well-known industry analyst, software architect and author.

Dell Inc. is the provider of the server systems, the data center SDN switches,
the Active Fabric Manager and OpenStack Neutron plugin, and the lab space
used for testing and demonstration. Data center hardware reliability is critical
to NFV. Dell has also been the systems integrator for CloudNFV and they
have coordinated the hosting of virtual functions for the demo.

EnterpriseWeb is the provider of “Active Virtualization” the encompassing

data/logic model that binds services and resources and provides the
optimization and management framework for CloudNFV. Most of our
integration with new partners will come about through connections
EnterpriseWeb supports. They also acted as the Implementation Coordinator
for the project.

Overture Networks is the provider of the orchestration logic for NFV, which
takes an optimized “manifest” of deployment and connectivity requirements
and realizes the actual instantiation via OpenStack APIs. Overture is the key
to multi-vendor network support (via Neutron) within CloudNFV and they also
provided the metro/Carrier Ethernet switching for inter-data-center
connectivity.

Qosmos plays two critical roles in CloudNFV. First, their traffic probes
provide us with monitoring of the critical flows that let us optimize network
utilization and performance. Second, their “DPI-as-a-Service” capability is
used in our demonstration to illustrate the NFV concept of Service Chaining.

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 9
In addition to these six founding firms, we’re pleased with the support
provided by Metaswitch Networks, whose
open-source IMS “Project Clearwater” was
the best cloud-ready virtual function Overall Architecture:
resource we could find. Clearwater already
enjoys operator support and is in trial in NFV Orchestration and Optimization, Active
various regions of the world, and they’ve Metro Ethernet Switches: virtualization and
Demo console:
been very helpful in acting as a test-bed in
integrating virtual functions into an operating Demo Console
demonstration.

If you’re interested in learning more about

each of the partners, we’re offering a short Demo
description of each company and their role, Virtual
Function
Data Path Acceleration:
provided by the firms themselves, as
Demo Virtual Function:
attachments at the end of this document.

We’ve Only Just Begun Servers, Data Center

Switching, Lab Facilities.
Traffic Telemetry and DPI
as a service: Systems Integration:
CloudNFV has a pretty intense mission, and
even though we’ve architected to simplify
development and deployment, we’re sure Figure 8. Meet the CloudNFV Team!
you understand that this has been no small
undertaking. Even documenting CloudNFV
isn’t trivial, and so we’re forced to develop documents as we progress in our
testing through the summer and fall of 2013. We ask everyone to be patient
as we prepare more material, and also that those who want to work with us in
some way go to our website and check the
current state of the project and the avenues for CloudNFV will
participation. The Documentation tab includes evolve as
a paper describing the various programs for
participating in CloudNFV and the way we’re
integration of new
organizing and running them. We ask components
everyone to recognize that we simply cannot advance its
do one-on-one discussions with everyone functionality. That
interested in learning about us or working with evolution is our
us. Please follow the guidelines and we’ll do
our best.
primary goal – a
goal driven by our
This reveal, us opening our activity to new desire to create a
participants, isn’t the end of our process. framework for
CloudNFV will evolve as integration of new
components advance its functionality. That
cloud-hosted virtual
evolution is our primary goal – a goal driven by functions,
our desire to create a framework for cloud- applications, and
hosted virtual functions, applications, and experiences that’s
experiences that’s as scalable and powerful as as scalable and
the Internet. Will there be other frameworks?
We’re sure there will, and we hope that those
powerful as the
who want to develop them will join with us, Internet.
learn from our successes and mistakes, and
participate in what might well be the grandest telecom experiment of all time.
Join your vision, your eyes, with ours and we’ll see the future.

Copyright © 2013 CIMI Corporation All Rights Reserved

CloudNFV is a Trademark™ of CIMI Corporation 10
 6WIND Summary for CloudNFV

Company Background

6WIND, a networking and telecom software company, provides high-performance data plane solutions that accelerate the
performance of Virtual Network Functions and Virtual Switches. As the #1 supplier of high-performance networking
software for LTE infrastructure, generally implemented today on physical platforms, 6WIND is well-positioned to solve the
networking performance challenges for Virtual Network Functions in NFV.

6WIND’s Software in CloudNFV

Within CloudNFV deployments, the

6WINDGate™ networking software is
used in two places.

First, 6WINDGate accelerates the

performance of Virtual Networking
Functions (VNFs).

Thanks to its fast path data plane

architecture 6WINDGate typically
delivers 10x the performance of a
standard Linux networking stack with
no changes required to the kernel.

6WINDGate includes a
comprehensive set of networking
protocols (IP forwarding, routing,
virtual routing, PPP, firewall, IPsec,
IKE, TCP termination etc.), ensuring that all VNFs are accelerated.

6WINDGate is fully compatible with standard Linux networking APIs so the VNF applications run unmodified.

6WINDGate enables operators to achieve best-in-class cost-performance from VNFs running under KVM, such as
firewalls and security gateways.

Second, 6WINDGate accelerates the Open vSwitch (OVS) that switches network traffic to the Virtual Machines (VMs) in
which the VNFs are instantiated.

Typically, 6WINDGate delivers a 10x improvement in OVS switching performance, with no changes required to the OVS
code itself. In many cases, this 10x increase in switching performance results in at least a 3x improvement in the number
of VMs that can be instantiated per server (the VM density).

As part of improving OVS performance, 6WINDGate accelerates the secure tunneling protocols such as IPsec, GRE,
VLAN etc which are required for high-bandwidth VM-to-VM traffic.

In these two environments, 6WINDGate runs within KVM, under the control of the OpenStack orchestration layer.

Revision 1.0 August 12, 2013

Whether to reduce cost, increase revenue or revitalize an entire ecosystem, Network
Function Virtualization (NFV), Software Defined Networking (SDN), and open cloud
computing technologies can together form a solid foundation for transforming our planet’s
vast communications infrastructure into the cloud age.

Dell Inc. is delighted to be a founding member and the Proof-of-Concept system integrator
of the CloudNFV™ open project. CloudNFV™ was launched by a consortium of seven
companies, led by CIMI Corporation, to realize the vision of NFV using standard open cloud
computing and SDN technologies, and to demonstrate so in an open Proof-of-Concept
phases. Dell will be hosting the PoC in its Silicon Valley lab.

Dell’s vast portfolio of globally available data center infrastructure, cloud and multi-cloud
management software solutions, and related services for development, integration and
support help customers worldwide to quickly deliver applications, streamline the
management of systems (including servers, networking, storage, NEBS compliant OEM
infrastructure), expand your virtual environment, and rapidly adopt cloud-based
infrastructure.

Dell is a leader in helping customers build, modernize and optimize data centers with a
unique transformative approach. Our experiences in data center deployment and
management, and our focus on results for customers add to the ingredients of success in
realizing the vision and benefits of NFV.

We are excited being part of CloudNFV™ and the coming transformation of our customer’s
network infrastructure, and the positive impact we can have in enabling a new Internet.

About Dell
Dell Inc. (NASDAQ: DELL) listens to customers and delivers innovative technology and services that
give them the power to do more. For more information, visit www.dell.com.

Dell is a trademark of Dell Inc. Dell disclaims any proprietary interest in the marks and names of others.

Dell Media Contact: Franklin Flint, OEM Telecommunications Marketing & Strategy,
[email protected]

Dell Technology Contact: Wenjing Chu, Distinguished Technologist, Dell Research,

[email protected]
EnterpriseWeb™ (www.enterpriseweb.com) is a lightweight and elastically-scalable application fabric that
supports the orchestration, optimization and management of Virtual Network Functions for CloudNFV™.

EnterpriseWeb enables CloudNFV’s Active Virtualization framework, which provides an extensible model for
semantically relating the entities, policies, services, resources, protocols and processes that all participate in
the delivery of a Virtual Network Function over diverse network and cloud hardware.

“Active” Virtualization is a critical distinction at the heart of CloudNFV. It extends well-established notions of
virtualization to allow for a more loosely-coupled and dynamically adaptable architecture.

Virtualization is an abstraction or set of abstractions that conveniently ‘hides’ complex relationships between
devices, software and services to effect a functional sub-system that can be addressed/automated collectively.
As with many conveniences, there is a trade-off. For virtualization to work the model generally imposes a fixed
set of rules that govern the relationships to provide a guarantee, which supports a specific utilization, but
precludes many others – it’s programmable, but not adaptable (rules are “baked-in”). Moreover, changes in
the components or the relationships between the components can break applications – it’s brittle. Traditional
virtualization can create physical constraints that compromise agility.

We see this in the design of Web-Services and RESTful APIs, which hide their implementation details behind static interfaces. If a
Service or API doesn’t meet a specific need of an application, even if the new requirement represents only a minor change in the
relationship of components, it nonetheless requires development of yet another discrete Service or API. This leads to library
growth, which increases related maintenance costs and lowers overall development productivity – an unintended, but material
consequence of the design.

EnterpriseWeb achieves the benefits of virtualization, hide complexity to automate collections of devices,
software and services, without the tight-coupling. With EnterpriseWeb the models bind to resources
dynamically – they stay truly virtual. This allows the components of an orchestrated service to independently
evolve. Components can be changed and even replaced, during live operations, without breaking the model.
The approach supports optimization as the model can query a network for the latest and most appropriate
resources. This is Active Virtualization.

In CloudNFV, we model services as combinations of virtual functions and network behaviors. Every service is
an abstraction. When those services are ordered we create an optimized map of how the abstraction becomes
real—and we then use CloudNFV’s orchestration model to instantiate virtual functions, then connect those
functions with each other and with users. We record the resource assignments, and we derive a continuous
view of the operating state of the service and all its components from those records—drawing on our
repository of resource state information collected from everywhere in the network and the cloud. Our
CloudNFV partners, 6WIND, Dell, Overture Networks and Qosmos can all provide us with telemetry on service
and resource conditions, and we translate these into meaningful management views.

EnterpriseWeb supports the agility goals of CloudNFV and the differentiated services that will dominate carrier
revenue models in the future.

Copyright 2013, EnterpriseWeb LLC CloudNFV is a Trademark of CIMI Corporation

DATASHEET

Overture’s Role in CloudNFV

Overture is participating in the CloudNFV project to support and advance the work
of the ETSI NFV ISG. In particular, Overture is contributing its Ensemble Service
Orchestrator (ESO), Ensemble Network Controller (ENC) along with the Overture
6500 and 65 metro service edge switching resources.
Overture is the preferred provider of Carrier Ethernet solutions for the metro edge.
Known for innovative solutions that enable high-capacity Ethernet services over any
media including fiber, copper and TDM, Overture has extended its commitment to
innovation with Ensemble Open Service Architecture™ (Ensemble OSA™). By leveraging
Overture’s Carrier Ethernet expertise and this new open architecture for software-
defined services, network operators and service providers worldwide can reduce
costs, maximize operational efficiencies and introduce new revenue-generating
services on a scale never before possible.
NFV Orchestration:
In the context of CloudNFV, the Ensemble Service Orchestrator (ESO) converts an
Optimizer-generated manifest describing hosting locations and connectivity into
deployment commands. ESO is a high-availability, open and field extensible platform
for managing the entire cycle of VNF onboarding, chaining, federation and operations
to support ETSI NFV use cases such as virtual Enterprise and IP Multimedia System
(IMS). ESO leverages the OpenStack™ cloud management system and the Ensemble
Network Controller to commission the VNFs, physical elements and the network
connectivity between them and the end users. ESO works with the Active Resources
construct to optimize resources across the virtual and physical worlds.
WAN Network Control:
In CloudNFV, the Ensemble Network Controller (ENC) serves as
the WAN infrastructure SDN controller, bridging the virtual network
overlay and the physical network worlds. It is a fully Metro Ethernet
Forum (MEF)-compliant controller extensible to MPLS and IP
networks. The ENC supports a direct interface to the ESO and will
soon be available as an OpenStack Neutron (formerly Quantum)
plug-in, forming the basis of the industry’s first Carrier Ethernet
FCAPS controller aligned with the CloudNFV model. It automates
the entire lifecycle of the metro edge network from service creation,
activation to assurance. It is a high-availability system and supports
the scale required to manage tens of thousands of devices at the
metro edge. In the initial CloudNFV demonstration, the ENC serves
as a peer to the Cloud Network controller, which together provide
abstraction and interfaces into the network resources, both physical
(switches) and virtual (vSwitches).
Networking Resources:
Overture’s innovative 6500 Carrier Ethernet Service Delivery
Platform provides the WAN connectivity to the various elements in
the CloudNFV ecosystem. The 6500 is used as the primary traffic
steering element, steering traffic to the virtual switches and chained
VNFs. The Overture 65 next generation Ethernet Access Device
(EAD) forms the end customer located service demarcation point.
Overture is pleased to support the CloudNFV initiative in demon-
strating the viability of a cloud-based NFV platform. Through
Ensemble OSA, service providers can capitalize on the NFV and
SDN revolutions to bring the benefits of cloud technologies and
virtualization to the metro edge.
Qosmos contributes to
standards through
Network Intelligence
and DPI NFV initiatives

Qosmos plays an active role in initiatives piloted by the Open Networking Foundation (ONF™) and ETSI
Network Functions Virtualization (NFV) Industry Specification Group (ISG), contributing to emerging
network standardization for DPI and Network Intelligence.

As a member of the ONF™, Qosmos participated in the elaboration of the MEC L4-L7 Requirements
document which was behind the L4-L7 service requirement adopted by the Technical Architecture
Working group. Qosmos continues to be an active contributor in this group.

As part of the ETSI NFV ISG, Qosmos contributed to the Software Architecture group for the use case
definition of the Virtual Networking Function Component (VNFC). Qosmos’ DPI engine was used as an
illustration in the definition.

Qosmos is a founding participant of the CloudNFV™ open project which was launched by a consortium of
companies, led by CIMI Corporation, to implement the NFV model using standard cloud computing tools
and principles as described by the ONF and NFV ISG. Qosmos is delighted to be part of this initiative and
to have the opportunity to demonstrate Proof-Of-Concept in the SDN & NFV deployment phases.
“Having DPI-as-a-service is a critical element in a number of service provider NFV applications and use
cases such as policy-based traffic shaping and management applications” Qosmos says.
The way to provide DPI VNFC characteristics will allow the service providers to optimize the VM
placement and orchestration upon the physical resources.

About Qosmos:
A pioneer in Network Intelligence based on DPI, Qosmos is the leading independent OEM provider on
the market, serving more than 50 vendors worldwide. Based in Paris, Qosmos has offices in Silicon
Valley, Singapore and London. For more information, please visit www.qosmos.com
Qosmos Media Contact
Madeleine Renouard, Marketing Communications Manager
Tel: +33 (0)1 70 81 19 00 / [email protected]