1 Copyright CohesiveFT

Highlights

This point of view offers CohesiveFT’s insight and thoughts on virtualization and networking:

1. Recent news shines a light on the long journey to the SDN spotlight.

2. OpenFlow brought attention to the need for virtual networks.

3. CohesiveFT has insights from inside the virtualization and network worlds.

4. SDN is necessary for the application controlled layer of cloud computing.

5. Considerations for the future of SDN include OpenFlow.

6. Big tent definition must emerge to truly capture the capabilities of SDN.

viewOpenFlow is Software Defined Networking, Software Defined Networking is not only OpenFlow.

A brief summary of the roots of Software Defined Networking (SDN), our predictions for the future of application layer emphasis, and a proposal to create a broader “big tent” definition.

Software Defined Networking and the Long Road to Nicira’s Overnight Success

With its recent acquisition of Nicira, VMware has done it again; they have take a space and made it an "overnight success". The first time they did this was when EMC floated the IPO of VMware in 2007. A company that sowed the seeds and did the spade work for x86 virtualization, over the coarse of a back-breaking 9 years, made itself and the topic of computer virtualization, an "overnight success" to those who hadn't been watching, learning and participating over the course of those years.

In this CohesiveFT “point of view,” we offer our thoughts on the long history of the development of what is now called software defined networking. Through the news of OpenFlow, Nicira, and VMware, the industry now has a term for what we have been working on since 2008 - Software Defined Networking -with our focus being at the application layer. Our insights into the application use-cases drives our vision of a “big tent” definition for the future of network virtualization.

Poin

t of

Software Defined Networking is in the news, but what exactly is the news?

The most recent example is that software defined networking (SDN) is now the rage, and we are even seeing a mini-wave of software-defined-network "washing" as established companies and startups attempt to bask in the $1.25 billion VMware - Nicira acquisition glow1. In this most recent example, just like with x86 virtualization (which had XenSource, Virtual Iron, Transitive, and others also driving computer virtualization forward) there have been others carrying the water in the network virtualization, cloud networking, virtual private cloud, application networking aka “Software Defined Networking” space.

CohesiveFT is one of these companies that has been driving the space forward with a production product serving customers’ needs since 2008. Another such company is F5, whose staff have written some interesting blog pieces lately on the topic of SDN and OpenFlow2. Unlike F5 which seems to be putting the "SDN" moniker at an arms length and claiming relationship of continuum and complement; at CohesiveFT we embrace the terms of software defined networking and network virtualization, and believe that like the phrases computer virtualization and storage virtualization, network virtualization will be a "big tent" encompassing many overlapping, orthogonal, and complementary facets of the broad concept.

In this paper, we will provide brief overviews and histories. For those who aren't intimately familiar with the OpenFlow project which has driven the recent boom in SDN conversation and start up-funding, we will provide a short overview of the evolution of those concepts and their motivations. For those who don't know CohesiveFT and its products, we will provide an

overview of our VNS3 (vns-cubed) product's features and its motivations.

What you will see in common between these is the motivations; what will be different is the customer and the initial deployment landscape for usage.

Figure 1: The Cloud Data Center

As a pre-cursor point, Figure 1 above shows what we believe is a fundamental concept in understanding cloud computing use cases and market dynamics. To summarize what the illustration expresses is that the needs and concerns of the cloud service provider are distinctly different than the needs and concerns of the cloud service user (the application topology deployed to the cloud and its owner). We call this the service provider-controlled layers and the application-controlled layer. We choose the designation "application-controlled" because the term "user" or "owner" is confusing in this context. Does it mean the end user of a web application, the contract owner of the cloud relationship, the system administrator of one of the pieces of the application topology? We designate the application itself as the proxy for these "user concerns.”

2 Copyright CohesiveFT

SDN in the News

CohesiveFT was one of the first advocates of fast fat and flat to describe the emerging form and functional demands upon the cloud datacenter; the infrastructure of the cloud service provider. The traditional datacenter has too much knowledge flowing in a vertical direction from application to infrastructure and infrastructure to application. Virtual infrastructure, as it manifested in the VMware enterprise datacenter or in the Xen-focused Amazon public cloud data center, made it clear that the network segmentations which occurred for security, organizational, or application purposes were vestigial since application nodes run anywhere within a virtualized compute pool, and ideally the infrastructure operators know nothing about the application, its semantics, relationships or behaviors.

To emphasize the point, a cloud service provider wants to be able to spin up virtual computers as quickly as possible, terminate them quickly, provide access to virtualized storage slices, and give access to network resources (mostly in the form of "bulk anonymous transport"), and from a business success point of view needs this infrastructure to be easy to own, manage and operate, as well as increasingly, to federate.

Where does this meet with the concerns of the cloud application? As the cloud application and its "owner," I want application nodes in the form of virtual machines to go up and down quickly, I want access to storage, I want access to network resources, and from a business success point of view I need my applications in this infrastructure easy to own, manage and operate - as well as increasingly - to federate.

In this symmetry, the needs and concerns sound similar if not the same, but they are not. One set is from the point of view of the "landlord" and the other from the point of view of the "tenant.”

3 Copyright CohesiveFT

Background: Fast, Fat and Flat

Speaking from experience:How CohesiveFT’s VNS3 product attributes (in white) stack up to the seven properties of network virtualization (in gray):

Independence from network hardware

Our designation of fast fat and flat: we were desirous of a high performance LAN with great Internet access + un-encumbered "bulk transport" within & across cloud data centers. VNS3 network managers are virtualized devices that live on top of the bulk transport but are not dependent on the network hardware.

Faithful reproduction of the physical network service model

VNS3 is a networking device, it provides the features and functions needed to provide a virtual network that the customer controls and can lay out topologically in ways they see fit.

Follow operational model of compute virtualization

CohesiveFT was "born in the cloud" not wiring closets - we get the operational model of compute virtualization by running within the model of compute virtualization as virtualized devices. The elasticity of the cloud allows VNS3 devices to provide purpose-specific, or application-specific virtualized network topologies.

Compatible with any hypervisor platform

By running in the compute virtualization model we can conceptually and practically deliver VNS3 virtual networks to any of the major public cloud infrastructures, private cloud infrastructures, and enterprise virtualization infrastructures.

Secure isolation between virtual networks, the physical network, and the control plane

We believe the user experience model and the deployment models available for VNS3 meets the essence of this demand for the application-controlled layer of cloud infrastructure.

Cloud performance and scale

VNS3 virtual networks can be spun up globally using the clouds as points of presence to connect to data centers creating cloud-based WAN/LANs in minutes. Because of the dynamic nature of such "scriptable networks" network issues can be dealt with by deploying or re-deploying network infrastructure nodes, providing network elasticity just like cloud provides compute elasticity.

Programmatic network provisioning and control

VNS3 has had an extensive REST-based API and command line API since late 2009, and the most recent release allows all capabilities of the device to be programmatically controlled with no need to ever use the browser based UI.

There is in fact a whole parallel construct of language where each of these participants in the cloud computing landscape use the same words to talk about different things. Both talk about provisioning, deployment, monitoring, managing, patching, and of course networking.

Despite all the years of IT, all the products, all the whitepapers, and all the analysts, these concepts are used loosely and in multiple dimensions. Using the structure of Figure 1., there are people working for the Cloud Service Provider who work predominantly at the physical layer of the infrastructure who claim to perform all of these tasks, there are people working for the Cloud Service Provider who work predominantly at the virtual infrastructure layer (the hypervisors, the SAN, the vSwitch) who claim to perform all of these these tasks, and of course caretakers of the application deployed to the cloud, working for the company deploying the application, wholly concerned with the needs of the application, also claim to perform these tasks.

Unfortunately, in some ways, SDN now gets to join the club, and exist as a concept "up and down" the infrastructure stack as well as across the perimeter of visibility and control that exists between the Cloud Service Provider and the applications running in its cloud.

A brief history of the evolution of OpenFlow

Google-able history provides an initial whitepaper written by the team, many whom now drive OpenFlow and work for Nicira, entitled OpenFlow: Enabling Innovation in Campus Networks3. It declares a set of motivations for what began as a narrow, but laudable purpose; "a way for researchers to run experimental protocols in the networks they use every day […] and allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density."

The paper also highlights the obstacles to having this capability from the "incumbent” network vendors saying, "Commercial switches and routers do not typically provide an open software platform, let alone provide a means to virtualize either their hardware or software […] and, of course, open platforms lower the barrier-to-entry for new competitors."We at CohesiveFT would point out our conclusions about the project team at that time:

• Focused on experimentation allowing rapid innovation of new network protocols and a potential platform to let new protocols run side-by-side with production traffic.

• Focused on "bounded" spaces with references to "campuses," "wiring closets" and "labs"

• Had a sense of the market-altering forces of open standards, virtualization and open source software, albeit quite practical at the time about the current state of behavior of incumbent network vendors.

The next evolution of the concepts comes with the whitepaper by some of the initial authors with some new collaborators, "FlowVisor: A Network Virtualization Layer" discussing experiences with an initial prototype of an OpenFlow controller and the design targets for their work as well as outlining some areas needing more work4.

4 Copyright CohesiveFT

Background: OpenFlow

The needs and concerns of the cloud service provider are distinctly different than the needs and concerns of the cloud service application. We call this the service provider-controlled layers and the application-controlled layer.

The authors outline five dimensions that need to be considered for a virtualized network:

• Bandwidth • Topology • Device CPU • Traffic • Forwarding Tables

Bandwidth is the ability to control the bandwidth allocated to a particular virtual network. Topology is that "each slice should have its own view of network nodes (e.g., switches and routers) and the connectivity between them. Device CPU is akin to standard x86 computer virtualization implying the CPU of the network device needs to be able to be sliced such that each virtual network gets appropriate compute resources. Traffic means that virtual networks should only see each others traffic if dictated and allowed. And, forwarding tables speaks to the need to isolate forwarding table entries between the different virtual networks encapsulated by a device managing more than one virtual network.

Evolution of Network Virtualization Definition

A very strong maturation of concepts emerged with the creation of the commercial concern "Nicira" (now part of VMware) and its Seven Properties of Network Virtualization.

They set quite a high hurdle by declaring, "Network virtualization, if done correctly, should be able to run any workload that is compatible with existing networks, over any type of hardware at any location. The following list of

seven properties must be in place to gain these benefits. Without them, it is not possible to unlock the true potential of cloud."

The seven properties in summary are:

• Independence from network hardware• Faithful reproduction of the physical network

service model• Follow operational model of compute

virtualization• Compatible with any hypervisor platform• Secure isolation between virtual networks, the

physical network, and the control plane• Cloud performance and scale• Programmatic network provisioning and

control

For each of these properties, the Nicira whitepaper clearly elucidates their full meanings for each of these properties, and we recommend their review. From this, we at Cohesive also would evolve our conclusion with respect to the vantage point of the project. We would like to argue that the original writers are:

• No longer thinking about wiring closets and campuses, but rather cloud scale.

• Still wanting to allow "side by side" experimental traffic but strong recognition of the fact that enterprise applications will need a "faithful reproduction of the physical network service model".

• And now as a commercial concern, wanting to carve out its space in the landscape, effectively declare independence from Cisco, Juniper, et. al. - although obviously constructing solutions to stand atop their existing concepts, skill sets and install base.

5 Copyright CohesiveFT

Analysis: OpenFlow

From CohesiveFT's point of view, it is only the last of these, forwarding tables, that begins to imply a specific implementation for the solution to these challenges.

We noticed the original five dimensions of a virtual network were more prescriptive of an implementation, while the new seven properties of network virtualization define an essential outcome: “network virtualization, if done correctly, should be able to run any workload that is compatible with existing networks over any type of hardware at any location.”

In these evolved seven properties and their implied, if not explicit, declaration of independence from the hardware layer, they also create constitutional precepts of software defined networking that essentially free CohesiveFT and others from the most narrow definition of software defined networking, one limited to various implementations of OpenFlow.

CohesiveFT and SDN for the Application Controlled layer of cloud computing

CohesiveFT was founded by executives with backgrounds in running businesses for large global software vendors, as well as running large ($1B+ IT budget) enterprise organizations, as well as software startups. Without detailing the history of the company - one can look back in the blogosphere and find similar motivations which drove our foray into software defined networking.

Within these motivations there is a high degree of commonality with those outlined above in the evolution of OpenFlow. The premise for CohesiveFT was that open source, open standards, virtualization and service-oriented architecture would reshape the world of data center computing. That was the "aha" that made us ask, given that insight, what products would enterprise customer's need?

Our first broad answers to that question were that the new data center would require attributes not commonplace in the world of enterprise computing solutions; to meet the needs of the emerging enterprise market a solution would need to emphasize:

• Self-service - a user could if they wished engage and deliver without vendor interaction or interference.

• Mass customization - the user could "bring their own" or customize extensively.

• Multi-sourced - an aggregate of multiple vendor offerings.

• A "journeyman" user experience - that a user of general experience in the computing domain could engage and succeed without the typical deep expertise required for the domain.

Customization and control were the conceptual backdrop to the creation of CohesiveFT's VNS3. As CohesiveFT began to put its own computing systems into the cloud, even as a company "born in the cloud," we were uncomfortable with the implied trust, and explicit loss of control of our network infrastructure.

As a result we deployed a solution which we later released as an open source project VcubeV, which was a simple and naive pre-cursor to the hybrid, mesh capable, switch, router, firewall, VPN concentrator and protocol redistributor that VNS3 is today.

But this simple project allowed us to begin to assess what were the critical capabilities which network virtualization needed to provide to the enterprise customer.

Addressing - meaning full control of address regardless of where running. In the cloud this creates the opportunity to run N copies of an identical network context, each in their own "network container". At its simplest this allows application migration with a minimal number of configuration change requests, at its most sublime it allows dramatically faster, cheaper disaster readiness and recovery infrastructure. Additionally, and we believe quite significantly, it needs to provide the essence of what Cisco/VMware are pursuing with OTV (overlay transport virtualization) which allows network location to be separated from network identity.

6 Copyright CohesiveFT

Background: CohesiveFT

Control of addressing also means I can pick up addresses and move them between network locations irrespective of data center, cloud provider, or even traditional subnet CIDR logic.

To provide a simple example, I could start with addresses 192.168.10.1 through 192.168.10.10 in one cloud and simply move alternating addresses to another cloud data center such that network identities of 192.168.10.<1 3 5 7 9> are in one location and addresses 1921.68.10.<2 4 6 8 10> are in another location - but it is one logical network to my applications.

Protocol - meaning you can't be held hostage to the constraints of a particular cloud infrastructure and what it believes to be practically routable or conceptually allowed. Broadly it means that the virtual network doesn't have to be Layer N anything, sometimes it behaves layer 2, sometimes layer 3, sometimes in between.

From a practical implementation perspective the main manifestation of this in VNS3 is that it allows x-cloud UDP Multicast since the presence of that protocol is an expectation of many pieces of enterprise software, if only for service discovery and service election.

Topology - meaning exactly as Nicira puts it "faithful reproduction of the physical network service model." Enterprise staff have mental models for security and deployment structure built up from their physical data center experience. Let's let them keep those mental models as new ones are developed that take advantage of the immaterial physics of virtualization.

Security - meaning as much as anything "attestable control" of key security components including the ability to answer appropriately the question "Is my data-in-motion moving in plain

text in a third party network over which I have no insight, visibility or control?" You do not want to be the enterprise IT manager who answers "yes" to this question.

The ability to encrypt not only from data center edge to cloud VLAN edge, but throughout all application interactions is critical for any regulated or even cautious enterprise. As part of this control, the customer defines their encryption and controls any related artifacts such as certificates and keys.

We believe there are echoes of commonality between these initial motivations for CohesiveFT and those that have driven the service provider-controlled network virtualization evolution. The difference is service providers start at the bottom with the "device" and network flows. We begin at the top with the enterprise application, its owner and their collective technical and organizational demands.

It is on the basis of VNS3's "fitness" to the elucidated properties of network virtualization that makes us call for a bigger tent, one where a variety of techniques exist for meeting the needs of the two distinct constituencies of the cloud; the cloud service provider and the cloud application.

Considerations for the future of SDN

CohesiveFT is not the only vendor we would put into this space. For example, we certainly believe F5 does software defined networking and would invite them to "come on in" and share their vantage point and expertise as opposed to segmenting themselves away as complementary but fundamentally different.

7 Copyright CohesiveFT

Background: VNS3

CohesiveFT determined that the foundation of the enterprise need were the ability to control addressing, protocol, topology and security.

Figure 2: SDN Market and Cloud Layers

Figure 2 shows that network virtualization will have an impact on the different layers of the cloud data center with differing but interoperable techniques, and differing adoption lifecycles. The install base of the multi-decade old core network infrastructure will take some time to upgrade, especially in the enterprise.

Will Google, Amazon, Facebook, Twitter, etc. adopt some of these capabilities if they believe it will help them run their Internet-scale data centers? Of course they will, these are companies the are not averse to building their own server hardware out of precise yet idiosyncratic sets of components that work best for their businesses.

Adoption at the hypervisor level via Open vSwitch, Nexus 1000v or other hypervisor switch entrants is not a big deal if there is independent utility, since the install base is relatively small. However, it would not be a surprise to see OpenFlow controller functions incorporated into server operating systems, which increasingly are “the hypervisor,” like so many other network functions have.

Adoption at the cloud application level of solutions like VNS3, and its competitors is taking place today. This is of course the place with the least entrenched install base and as such, is the

easiest and most motivated to adopt some change, as long as the change is "mappable" to existing models and skill sets. How does OpenFlow fit in the application-controlled layer of the cloud data center?

Before answering that we think it is useful to look at the areas described as challenges in the service provider-controlled space today. As referenced by Mike Fratto, Network Computing Editor, there are "problems that the SDN vendors state – Virtual Machine (VM) mobility, the limited range of VLAN IDs, the inability to move L2/L3 networking among data centers and the inflexibility of current networking command and control."5

Interestingly there are workable solutions for many of these issues in the application-controlled space today, precisely because their networks are so virtual. As such, they don't have the cares and responsibilities of the actual bulk transport networks and data centers below them.

We would claim that VM mobility is workable when you can separate network location from network identity, that you can create an infinite number of un-related and related VLANS for application-specific purposes without concerning yourself with location or competition of resources due to the network elasticity afforded at the application layer, L2 and L3 traffic can be routed and isolated cross-datacenter and cross-cloud. Command and control is a growth area for us, as our customers get bigger virtual networks we need more capable management solutions for them.

As techniques like OpenFlow gain a foothold in the physical and virtual infrastructure layers and the multi-tenancy models mature, then OpenFlow conversations should be taking place between the provider-controlled layer and the application-controlled layer.

8 Copyright CohesiveFT

Prediction: Future of SDN

In the shorter term we are looking how to use OpenFlow in our existing implementation as a path to supporting MPLS, better plugins for protocol encapsulation so that there is a less defined sensation of Layer 2 versus Layer 3, and potentially improved tunneling approaches. All of these could potentially be done in the application-controlled layer even if there is not a significant install base at the vSwitch layer or the physical transport layer to interoperate with.

CohesiveFT is also looking how our experiences providing tenant-specific, encrypted, mesh virtual networks could be of value as Open Network Foundation looks at tunneling and encryption for OpenFlow controllers.

SummaryWe certainly believe SDN should be a big tent and encourage all sorts of means and mechanisms to be born in the virtual networking primordial soup. The behaviors of the Open Networking Foundation will in some ways determine if there is a big tent, or an encampment of tiny tents. If it behaves as "OpenFlow = SDN, SDN = OpenFlow" then that is a possible outcome.

Mike Fratto from Network Computing put out the tantalizing and controversial headline "Prediction: OpenFlow Is Dead by 2014; SDN Reborn in Network Management", and it would seem to be predicting a collapsed tent. It may be that his objections are not too different from what we are saying, although we think OpenFlow is an insightful and elegant launching point for unbundling the traditional network stack - and that it will be here and significant in 2014 and beyond.

Yet, we believe there are "horses for courses" and customers have needs right now that can be fulfilled by network vitalization in the broadest sense but will not be fulfilled via OpenFlow in the short term. As an example look how long

IPsec adoption took, or MPLS adoption, or IPv6. And of course the incumbents will not go gently into the night. There must be big tent thinking, CohesiveFT, Open Networking Foundation and other network virtualization advocates must capture the new momentum with a broad SDN definition.

9 Copyright CohesiveFT

Big Tent Thinking

References:1. Preimesberger, Chris. (Aug. 30, 2012). 2012:

Software-Defined Networking Becomes a Buzzword. eWeek.com http://www.eweek.com/c/a/Virtualization/VMWorld-2012-SoftwareDefined-Networking-Becomes-a-Buzzword-346692/

2. MacVittie, Lori. (May 14, 2012). SDN, OpenFlow, and Infrastructure 2.0 f5 |DevCentral.Weblogs. https://devcentral.f5.com/weblogs/macvittie/archive/2012/05/14/sdn-openflow-and-infrastructure-2.0.aspx\

3. McKeown, Nick; Anderson, Tom; et al. (Mar. 14, 2008). OpenFlow.org. OpenFlow: Enabling Innovation in Campus Networks. http://www.openflow.org/documents/openflow-wp-latest.pdf

4. Sherwood, Rob. Gibb, Glen; et al. (Oct. 14, 2009). OpenFlow.org.  FlowVisor: A Network Virtualization Layer. http://www.openflow.org/downloads/technicalreports/openflow-tr-2009-1-flowvisor.pdf

5. Fratto, Mike. (May 8, 2012). Network Computing.com. Prediction: OpenFlow Is Dead by 2014; SDN Reborn in Network Management. http://www.networkcomputing.com/data-networking-management/prediction-openflow-is-dead-by-2014-sdn/232901611

See Also:1. Fratto, Mike. (May 10,

2012). Network Computing.com. Searching for an SDN Definition: What Is Software-Defined Networking?

2. OpenFlow: http://www.openflow.org/wp/learnmore/

3. Open Network Foundation: https://www.opennetworking.org/about

10 Copyright CohesiveFT

Big Tent Thinking

Point of View written by:

Patrick KerpanCEO, CohesiveFT200 S. Wacker Dr. Chicago IL 60606

Contact Information

To have a deeper discussion on how the point of view impacts your business, please contact:

CohesiveFT MarketingU.S. Toll Free: 888.444.3962marketing@cohesiveft.com