Cloud Expo New York: OpenFlow Is SDN Yet SDN Is Not Only OpenFlow Software Defined Networking (SDN) is a new approach to networking, both to the data centre, and as a connection across data centers. SDN defines the networks in software, meaning designers can operate, control, and configure networks without physical access to the hardware. Effectively, SDN frees the network and applications from underlying hardware. New technologies are making it possible for enterprises to use virtualized networks over any type of hardware in any physical location - including unifying physical data centers and federating cloud-based data centers. In his session at the 12th International Cloud Expo, Patrick Kerpan, the CEO and co-founder of CohesiveFT, will highlight customer use cases to demonstrate a broader SDN definition.

1. Copyright CohesiveFT - 1/20/15
OpenFlow is SDN,
SDN is not only OpenFlow
CloudExpo East - SDN & Networking Innovations Track
June 10 2013
Patrick Kerpan, CEO
CohesiveFT
1
Tweet it live:
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

2. Copyright CohesiveFT - 1/20/15
Agenda
•Company Background
•SDN in the News
•The Application Layer of Cloud
•OpenFlow and Definitions
•“BigTent”Thinking
•CohesiveFT’s Answer to SDN Needs
•SDN and the Future of Networking
•Contact Information
2
Tweet it live:
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

3. Copyright CohesiveFT - 1/20/15
What We DoWho We Are
Company Background
• Cohesive FlexibleTechnologies Corp.
(CohesiveFT)
• Founded in 2006 by IT and capital
markets professionals with experience
in operations, enterprise software and
client-facing services
• First SDN product launched in 2007,
followup products in 2008 and 2011
• Cloud, vendor, and standards neutral
for greater customization and control
• Enable enterprises to run business
operations via the cloud
• Customers have 50M virtual device
hours in public, private, & hybrid clouds
secured byVNS3
• Only company to promote
comprehensive cloud container
solution for migration, deployment and
control
• First Application SDN product in IBM’s
SCE and SCE+
3

4. Copyright CohesiveFT - 1/20/15
Experience: Customers &Verticals
4
ISV SaaS Integrators Self Service Enterprise

5. Copyright CohesiveFT - 1/20/15
• 36M virtual device hours in public,
private, & hybrid clouds secured by
VNS3
• Over 8,000 users built, imported,
transformed and delivered 33K+
virtual server templates with Server3
• Numerous enterprises migrated
complex applications to the cloud with
Context3
• 18+ Industry and Cloud partners
Customers Include:
• Global Mutual Fund Company
• Global ERP provider
• Global BPMS provider
• Global Cloud-basedThreat
Detection
• Global Fashion Brand
• GlobalToy Manufacturer
• US National Sports Association
• and many more global, transnational
and local customers
AchievementsOur Clients
EMAILVERSION
5

6. Copyright CohesiveFT - 1/20/15
UserControlProviderControl
Compute Storage Network
Virtualization
Layer
Web Server Runtime
IaaS
PaaS
Layer 0
Layer 4
Layer 3
Layer 2
Layer 1
Layer 5
Layer 7
Layer 6
Limits of access, control, & visibility
DeveloperTools
The Application Layer Of Cloud
6
Application
Layer
Hardware
Ownership
Layer

7. Copyright CohesiveFT - 1/20/15
Separte Provider and App Layer Concerns
7
Hardware
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC
PhysicalLayer
SDN Market can be divided into 2 segments
1. Application Controlled
• CohesiveFTVNS3
• Cisco Cloud Service Router
• Citrix CloudBridge
2. Provider Controlled
• Nicira/VMware
• Open vSwitch
• Cisco Nexus 1000v
• IBM
• Cisco
• Juniper
VirtualLayerApplicationLayer
Cloud Instance
OS
App Stack
ProviderControlled
Hypervisor
Hardware
Compute
Storage
Network
Multiplexed access to:
AppControlled
} OpenFlow
Layer 0
Layer 4
Layer 3
Layer 2
Layer 1
Layer 5
Layer 7
Layer 6
Perimeter of access, control, & visibility

8. Copyright CohesiveFT - 1/20/15 8
Hardware
Separte Provider and App Layer Concerns
PhysicalLayer
SDN Market can be divided into 2 segments
1. Application Controlled
• CohesiveFTVNS3
• Cisco Cloud Service Router
• Citrix CloudBridge
2. Provider Controlled
• Nicira/VMware
• Open vSwitch
• Cisco Nexus 1000v
• IBM
• Cisco
• Juniper
VirtualLayerApplicationLayer
Cloud Instance
OS
App Stack
ProviderControlled
Hypervisor
Hardware
Compute
Storage
Network
Multiplexed access to:
AppControlled
} OpenFlow
Layer 0
Layer 4
Layer 3
Layer 2
Layer 1
Layer 5
Layer 7
Layer 6
CURRENT VISION - OpenFlow Stops Here
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

9. Copyright CohesiveFT - 1/20/15
OpenFlow - Early SDN definition
The authors of the original ONF paper
outlined 5 dimensions that need to be
considered for a virtualized network:
It is only the last of these,
forwarding tables, that begins
to imply a solution to these
challenges.
9
Tweet it live:
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC
...
Bandwidth
Topology Device CPU
Traffic
Forwarding
Tables

10. Copyright CohesiveFT - 1/20/15
Stepping though Nicira’s Definition of SDN
10
Nicira founders defined the 7 Properties of network virtualization as:
1. Independence from network hardware
2. Faithful reproduction of the physical
network service model
3. Follow operational model of compute
virtualization
4. Compatible with any hypervisor platform
5. Secure isolation between virtual networks,
the physical network, and the control
plane
6. Cloud performance and scale
7. Programmatic networking provisioning and
control
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

11. Copyright CohesiveFT - 1/20/15
Independence from network hardware
11
1. Independence from network hardware
Tweet it live:
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

12. Copyright CohesiveFT - 1/20/15
Reproduction of physical network model
12
2. Faithful reproduction of the physical network service model
Tweet it live:
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

13. Copyright CohesiveFT - 1/20/15
Follow op. model of compute virtualization
13
3. Follow operational model of compute virtualization
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

14. Copyright CohesiveFT - 1/20/15
4. Compatible with any hypervisor platform
14
4. Compatible with any hypervisor platform
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

15. Copyright CohesiveFT - 1/20/15
Secure isolation
15
5. Secure isolation between virtual networks, the physical network, and
the control plane
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC
ONF

16. Copyright CohesiveFT - 1/20/15
Cloud performance and scale
16
6. Cloud performance and scale
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

17. Copyright CohesiveFT - 1/20/15
Programmatic networking provisioning & control
17
7. Programmatic networking provisioning and control
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

18. Copyright CohesiveFT - 1/20/15
“Big Tent” Thinking within SDN Conversation
18
Two distinct Cloud Constituencies Remain:
• Cloud Service Providers
• Cloud Applications
The SDN conversation must address concerns of
both Providers and Applications to answer the future
concerns of:
• Who “owns” and “controls” each aspect of the application?
• How can you move L2 / L3 networking among data centers
driven by the customer, without provider interaction?
• How do you use OpenFlow in existing implementations?
• How do you improve tunneling approaches?
• How do you do encryption throughout?
Tweet it live:
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

19. Copyright CohesiveFT - 1/20/15
Overlay networks solve common pain points:
19
Attest to data in motion encryption
Capacity expansion into public cloud
Cloud WAN / connect to customer &
partner networks
Federate common, shared infrastructure
Control in 3rd party infrastructure
Disaster recovery / readiness
@cohesiveFT #SDN talk at
@CloudExpo #cloudExpoNYC

20. Copyright CohesiveFT - 1/20/15
CohesiveFT founders believedVirtual Networking and the ONF definition can benefit
from additional application-centric focus on:
• Self-service
• Mass Customization for enterprise
• Journeyman Experience for end users
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.
CohesiveFT’s Answer to SDN Needs: VNS3
20
Provider Owned/Provider Controlled
Provider Owned/User Controlled
VNS3 - User Owned/User Controlled
User Owned/User Controlled

21. Copyright CohesiveFT - 1/20/15
Insights revealed the need for integration,
governance and security in the app layer.
Enterprises need to control addressing,
protocol, topology and security
across federated clouds.
Cloud Providers must meet the enterprise
app needs to extend networks to the cloud.
• Federate across cloud targets
• Reuse existing IT resources and skills
• Compatibility with any vendor, OS, cloud
CohesiveFT’s Answer to SDN Needs: VNS3
21
As we put our own systems into the cloud, we were uncomfortable
with the implied trust, and explicit loss of control of our network.

22. Copyright CohesiveFT - 1/20/15
Application Use Case: Look like a Telco
• Customer:African mobile application technology company
• Challenge: Mobile users need to connect to SMS with users on other
networks in a market with a patchwork of carriers
• What do you need to do this (in Lagos, Nigeria)
• Telcos require me to have a “data center” of public IP addresses used in my private LAN
• Also, of course require me to have real public IP endpoint addresses
• Any form of connectivity like IPsec, BGP Peering, GRE, etc..
• Of course redundant servers on reliable raised floor
• Cloud handles the raised floor, but how do you do the network piece
without virtualized network looking like the network the telco wants.
• This would have cost hundreds of thousands of dollars pre-cloud, tens of
hundreds worst case with the cloud combined with network virtualization.
22

23. Copyright CohesiveFT - 1/20/15
• Service provider with innovative mobile management solution.
• Like other “born in the cloud” companies - the software gains
tremendous leverage out of the cloud for the compute and storage
elements. How to get the same leverage from networking?
• Each customer requires an almost identical, secure, encrypted network
that not only keeps others out, but keeps the information in.
• Just useVLANS?
• VLANS don’t span datacenters in the cloud
• VLANS don’t span vendors; doesn’t allow use of clouds as “points of presence”
• VLANS aren’t encrypted throughout the cloud
• VLANS usually don’t allow UDP multicast
• VLANS don’t separate network location from identity
• Customer is running 125+ dynamic network bubbles (and adding more
weekly) that can be moved from cloud to cloud as necessary.
Application Use Case: Network Reproducibility
23

24. C O H E S I V E
FLEXIBLETECHNOLOGIES
Confidential - CohesiveFT 2012
Application Use Case: Network Zones
24
PhysicalLayer
Virtual
Layer
Perimeter of access, control, & visibility
ProviderControlled
Series of Hypervisors
Compute Storage Network
Multiplexed access to:
Customer 1 -Topology 2
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Customer 1 -Topology 1
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Customer 2 -Topology 1
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS

25. C O H E S I V E
FLEXIBLETECHNOLOGIES
Confidential - CohesiveFT 2012
Application Use Case: Network Zones
25
5
PhysicalLayerVirtual
Layer
Series of Hypervisors
Compute Storage Network
Multiplexed access to: Customer 1 -Topology 1
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Customer 2 -Topology 1
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Customer 1 -Topology 2
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Green
Zone
5PhysicalLayerVirtual
Layer
Series of Hypervisors
Compute Storage Network
Multiplexed access to:
Yellow
Zone
5
PhysicalLayerVirtual
Layer
Series of Hypervisors
Compute Storage Network
Multiplexed access to:
Red
Zone

26. C O H E S I V E
FLEXIBLETECHNOLOGIES
Confidential - CohesiveFT 2012
Application Use Case: Virtual Network Zones
26
5
PhysicalLayerVirtual
Layer
Series of Hypervisors
Compute Storage Network
Multiplexed access to:
Customer 1 -Topology 1
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Customer 2 -Topology 1
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
Customer 1 -Topology 2
Cloud instance 1
App Stack
OS
Cloud instance 2
App Stack
OS
Cloud instance 3
App Stack
OS
One “flat” infrastructure with network connectivity throughout.
Virtual networks are created with “green”,“yellow” and “red” properties
• Green Properties
• Connections allowed from netmask representing internal
ingress/egress
• Connections from virtual network clients
• Connections allowed from cryptographically recognized
virtual network managers
• Security lattice incorporating host firewall and hypervisor
firewall
• No IPsec connectivity
•Yellow Properties
• Connections allowed from netmask representing internal
ingress/egress
• Connections from virtual network clients
• Connections allowed from cryptographically recognized
virtual network managers
• Security lattice incorporating host firewall and hypervisor
firewall
• IPsec connectivity allowed to virtual net
• Red Properties
• No Connections allowed from netmask representing
internal ingress/egress
• Connections from virtual network clients
• Connections allowed from cryptographically recognized
virtual network managers
• Security lattice incorporating host firewall and hypervisor
firewall
• IPsec connectivity allowed to virtual net (MAYBE)

27. Copyright CohesiveFT - 1/20/15
OpenFlow TodayApplicationVirtual Network
Application Use Case: Creating theVirtual Net
• Must and does span datacenters
• Must and does span vendors
• Virtual network controllers get
explicitly defined local and public IP
addresses via automation
• Virtual network controllers connect
and peer via cryptographic identity and
checksums
• Application (and its executive owners)
are in control of addressing, protocol,
topology, security
• Application owner can make
attestation of control
• Talking about NOW not what is
possible in the future.
• Mostly within a datacenter
• Does not cross the Internet or
Vendors
• Proposed “How does controller get its
address?” - make DHCP call
• Proposed “How do controllers find
each other?” - do Bonjour broadcasts
• Vendor is in control of addressing,
protocol, topology, security.
• Vendor can make attestation of control
27

28. Copyright CohesiveFT - 1/20/15
Demo Use Case: Come take a look
28
AWS VPC US-West-2
VPC Subnet: 10.0.0.0/23
Client #2
Public IP: 50.112.160.110
VPC IP: 10.0.1.36
Client #1
Public IP: 50.112.160.109
Overlay IP: 172.31.1.1
VNS3 Manager #1
Public IP: 50.112.160.108
Overlay IP: 172.31.1.250
IPsec Device
Make: Cisco
Model:ASA
Public IP: 63.250.226.147
CohesiveFT Network Lab
Chicago, IL
Remote Subnet: 192.168.3.0/24
Remote Server
LAN IP: 192.168.3.3
IPsec Tunnel
192.168.3.0/24 - 172.31.1.0/24
192.168.3.0/24 - 10.0.1.0/24
VNS3 Overlay
Network
Subnet: 172.31.1.0/24
Client #3
Public IP: 54.251.136.83
Overlay IP: 172.31.1.2
Client Extra
Public IP: 54.251.136.84
VPC IP: 10.0.3.238
AWS VPC Singapore
VPC Subnet: 10.0.2.0/23
IBM SCE
Boulder, CO
Terremark
vCloud Express
Client #4
Public IP: 170.225.97.160
Overlay IP: 172.31.1.3
Client #5
Public IP: 204.51.114.245
Overlay IP: 172.31.1.4
VNS3 Manager #2
Public IP: 54.251.136.82
Overlay IP: 172.31.1.249
VNS3 Manager #3
Public IP: 170.225.96.174
Overlay IP: 172.31.1.248
VNS3 Manager #3
Public IP: 204.51.124.79
Overlay IP: 172.31.1.248
Peered Peered Peered

29. Copyright CohesiveFT - 1/20/15
ThankYou
Patrick Kerpan, CEO
CohesiveFT Americas
200 S.Wacker Dr.
Suite 1500
Chicago, IL 60606
Chris Purrington, Global Sales Director
CohesiveFT Europe
134 EastbourneTerrace
Paddington London
W2 1BA
29
Public Relations
Heidi Groshelle
groshelle communications
Tel: +1 415.821.1454
heidi@groshelle.com