This document proposes a novel use of Openflow and its applications in connecting Docker containers and simplifying cloud deployment. Some key points: - It aims to divide cloud infrastructure into smaller, independent parts to simplify deployment and scaling while using SDN techniques to reassemble them into a cloud with unlimited scalability. - Near term applications include a zero-configuration plug-and-play cloud that reduces costs and expedites cloud maturity. Long term it could enable inter-cloud connectivity. - It analyzes problems with current cloud networking practices and proposes using Openflow to map overlay entities to unique identifiers and route packets without encapsulation, eliminating the need for overlay entities to know each other.

1. A Novel Use of Openflow
and Its Applications in
Connecting Docker and Dummifying Cloud
Build, Ship, Run any Cloud, any Scale
DaoliCloud Company
April, 2015
Sign-up a free trial account now at
www.daolicloud.com

2. 2
Lift going up: Deployment, operation maintenance and scale-
out enlargement of cloud IaaS pool, e.g., Openstack, from now
on become plug-n-play easy for “dummies”
Lift going down: What? Docker is not connected? Don’t you
know Docker is for the cloud? Don’t you know cloud needs a
controller? No? You’re finished! Yes? Read on!
Lift Version of this Presentation
© DaoliCloud Company, all rights reserved, 2011—2015
Zero Configuration Plug-n-Play Cloud for Dummies, Wrapped in Docker Image
begin
image image

3. © DaoliCloud Company, all rights reserved, 2011—2015 3
• Executive Summary
• Cloud Networking Requirements and Current Practices
• A Novel Use of Openflow
• Application: Zero-Configuration Plug-n-Play Cloud
• RAIC：Redundant Array of Inexpensive Cloud
• Plug-n-Play RAIC Properties
• Long Term Value
• Conclusion
• Technical Backup Material
Content

4. 4
Innovation in SDN
To divide (differentiation) cloud into small parts so that cloud deployment,
operation maintenance, and scale-out enlargement jobs are dummified into
plug-n-play simplicity; and then using SDN technique to reassemble
(integration) small parts back to cloud of unbound scalability
Applications
Near term: Zero-Configuration Plug-n-Play Cloud for Dummies, to reduce
cost for cloud deployment and operation-maintenance; to expedite cloud
maturity and time to market; Long term: Inter-Cloud
Executive Summary
Minimized
dummified
plug-n-play
cloud 1
SDN Controller to
reassemble cloud
into unbound scale
© DaoliCloud Company, all rights reserved, 2011—2015
Minimized
dummified
plug-n-play
cloud N

5. 5
Cloud Networking Requirements:
1. Number of overlay entities (VMs, Docker containers) > > capacity
of underlay IP resource
2. Network isolation for multi-tenancy
Current Practices:
Encapsulation: MAC in UDP (e.g., VXLAN) or IP in IP (e.g., GRE)
• Req 1 met: Each encapsulation makes a tunnel to reuse underlay
resource
• Req 2 met: Each tunnel forms an independent VPN to isolate
overlay network
Cloud Networking Requirements and
Current Practices
Payload encapsulation nullified overlay network
functions (overlay headers become payload data)
Encapsulation
header label
= control plane
info placed in
forward plane
Underlay
packet
headers
L4/L3/L2
© DaoliCloud Company, all rights reserved, 2011—2015

6. 6
Encapsulation establishes software connection among cloud
servers in a cloud OS, e.g., Openstack, to scale UP cloud OS
• When a cloud OS is scaled UP, its deployment and operation-
maintenance jobs become very complex, only few “clever”
people can do the job, which efficiently shrink cloud market,
and prolong time to market
• A scaled-UP cloud, if too big, is unstable in operation; cloud
scale-UP has a humble size limit
• Encapsulation builds a physical large L2 network to include a
large number of irrelevant entities into a communications
group while in most cases communications take place only
between two entities; large L2 wastes resource + increases
complexity
Problem Analysis: Current Cloud Networking
© DaoliCloud Company, all rights reserved, 2011—2015

7. “1 Cloud 2 Openstack” = scale OUT
Cloud Scalability: Scale UP or OUT?
“1 Cloud 1 Openstack” = scale UP
To orchestrate thousands of servers?
To build a Tower of Babel?
Mission impossible
Difficult to deployment
and operation maintenance
Connecting thousands of servers
= very low system stability
E.g., message queue gets too big
User space connected Openstack:
Each independent Openstack has a
small scale, very easy to deploy and
operate maintain, however, cloud user
still sees a cloud of unbound scale
…Openstack
or Docker
…
…
…
OpenStack
or Docker
Openstack
or Docker
OpenStack
or Docker
Independent Cloud
7
Independent Cloud
Independent Cloud
Let connection take place
upon user communications
© DaoliCloud Company, all rights reserved, 2011—2015

8. 8
Role of L4-port includes to let communications initiator recognize
dialog contexts “invented here”
Upon starting an overlay dialog, the underlay host has the dialog
initiator’s id, can OF packetin (id, L4-ports) to the OF controller
L4-ports has sufficient entropy to 1-1 code flow for underlay hosts
to unicast route & resume overlay packets
Encapsulation is not needed, so that cloud hosts needn’t know one
another in time of cloud OS deployment and service operation
A Novel Use of Openflow (more detailed know-how
in technical backup material)
Overlay/underlay
packets headers
L2/L3/L4 mapping
coding & replacing
© DaoliCloud Company, all rights reserved, 2011—2015

9. Application: Cloud OS Horizontally Decoupled
9
Controller 1 Controller 2 Controller N…
Distributed SDN Controller Cluster, can be distributed in CDNs
Plug-n-Play Openstack/Docker Servers
…
…
…
Plug-n-Play
OpenStack
or Docker
SDN Control Plane:
Openflow Packetin
L4-ports coded flow
SDN Data Plane:
Overlay L4-port coded flow
on-the-fly connects overlay
nodes via underlay servers,
making cloud unbound for
users yet tiny for underlay
OpenStack
or Docker
OpenStack
or Docker
OpenStack
or Docker
Web (SSL)
connection
On-the-fly
data-plane
connection
Plug-n-Play
Plug-n-Play
© DaoliCloud Company, all rights reserved, 2011—2015

10. 10
Smallness in IaaS realization is desirable
Small scale of physical
implementation for IaaS
resource management
is like differentiation in math
to enable smooth integration
Invisible network patching boundary for small clouds are very useful:
• Only so can cloud have truly unbound scalability and elasticity
• Cloud OS becomes easy to deploy, stable to operate and maintain
• Arbitrary network topologies, widely distributed, inter-cloud
• Each server is an SDN router (distributed Neutron), no chokepoint
Provided network
patching boundary is
invisible by tenants;
Integration is beautiful
thanks to fine differentiation
©DaoliCloudCompany,all rightsreserved,2011—2015

11. 11
RAIC：Redundant Array of Inexpensive Cloud
Plug-n-Play IaaS Pool
Scale OUT
• Adding SDN controllers
just like adding new
base stations
• Adding cloud resource
just like new mobile
phones entering market
Overlay nodes in arbitrary
network topology and
geological distribution
Straightforward inter-cloud
© DaoliCloud Company, all rights reserved, 2011—2015

12. 12
Plug-n-Play RAIC Properties
• Completely automatic “Zero-Configuration Plug-n-Play
Cloud for Dummies”, cloud wrapped in Docker image
• High availability, inter-datacenter distribution and arbitrary
network topology, every server is an Openflow controlled
router, no chokepoint
• Arbitrary elastic scalability
• User mode patch clouds to pool CPUs, disks & routers
• Hybrid Cloud
• Heterogeneous connecting VMs + Docker containers
• No special requirement on switches and networking boxes
© DaoliCloud Company, all rights reserved, 2011—2015
begin
image image

13. 13
Long Term Value for Inter-Cloud
Cloud is unbound large, meaning its service logic scalability
However the physical implementation of the cloud should follow
distributed computing principle, and open standards for
interoperability
Without packet encapsulation, inter-cloud connectivity and
interoperability become straightforward
DaoliCloud wishes to collaborate widely with the industry and
academia to make cloud computing really big, stable and quality
services
©DaoliCloudCompany,all rightsreserved,2011—2015

14. 14
Conclusion
DaoliCloud’s SDN Cloud Networking Virtualization Technologies:
• Contribute to Openflow with a useful innovation
• Application: Zero-Configuration Plug-n-Play Cloud for Dummies
• Greatly eased cloud OS (e.g., Openstack) deployment, operation
and maintenance, these translate to speed-up cloud maturity
• Inter-cloud
Sign-up a free trial account NOW at
www.daolicloud.com
Download your own copy of “Plug-n-Play Cloud for Dummies”, plug-
n-play now!
Technical whitepapers and Product Introduction are available at:
www.daolicloud.com
Also available at:
www.slideshare.net/WenboMao
© DaoliCloud Company, all rights reserved, 2011—2015

16. 16
Technical backup material
Inherent problems for cloud networking
MAC address explosion One rack of servers in current CPU
condensity can host 10s of thousands containers. In conventional
flood-&-learn MAC populating, a ToR switch must hold multiple
such numbers of MACs since a cloud should be larger than one
rack. Moreover, can so MAC populated ToR work efficiently, and in
an affordable cost?
L2 broadcast control ARP broadcast is the only practical way to
plug-&-play construct a physical L2. However broadcast has
prohibitively high cost; to build a very large physical L2 is certainly
to look for trouble. In the next slide we shall discuss how current
technologies for L2 broadcast control, and their irrelevance to large
scale cloud networking.
The following cloud networking problems are already bad enough
for the scale of hypervisor-based CPU virtualization; the explosive
scale of container-based CPUs will only worsen the matter
©DaoliCloudCompany,all rightsreserved,2011—2015

17. 17
Technical backup material
Cloud networking current technologies analysis
Problem with VPN, GRE, NVO3, VXLAN, NVGRE, STT, LISP, MPLS,
etc. encapsulation protocols:
Key issue They connect cloud OS hosts in scale UP manner: that’s why
they’re aka “large L2” protocols. Enlarging L2 hopelessly kills scalability
for cloud services. Also killed enroute is cloud service interoperability.
Technical assessment
1. To avoid MAC explosion and control L2 broadcast, encap for
servers/hosts; to isolate tenants, encap for each tenant; to patch cloud
for truly large scalability, encap further for IDCs; in general, to connect n
instances, O(n^2) encapsulations are needed.
2. IP connectivity is carefully architected to be connectionless flows so
that forward plane only conducts per flow checking for routing, this very
important architecting is nullified by encap into per packet checking
labelling (yellow header in Slide 5), that’s why encap is inefficient.
3. Encap enlarges packet over MTU (Maximum Transmission Unit), and
hence fragmentation/reassemble, additional cost.
©DaoliCloudCompany,all rightsreserved,2011—2015

18. Solution know-how: Virtual Ethernet Bridge (VEB)
distributed at vNICs is SDN programmable
Any entity worldwide is mapped to a
“Physically Associated Address” (PAA)
e.g., PAA = (MACs, IPs, ContextTag)
L4 ports: Very good usage for ContextTag
Forward plane:
Unicast cable for entities
in distributed clouds
Control plane of a tenant
a, b: plug
a, c: unplug
b, c: plug
a, b: plug
a, c: unplug
b, c: plug
Important property of PAA:
Worldwide Unique
L4 Ports can code sufficient
entropy for PAA uniqueness
Overlay network of arbitrary topology on distributed VEB no longer need encapsulation
A unicast cable plugging entities x and y = (PAA_x, PAA_y), in which:
L2 MAC addresses link x, y to their respective default gateways
L3 IP addresses = underlay IP addresses of the respective default gateways
L4 Ports numbers encode unique mappings between overlay entities and PAAs
18
VEB VEB
SDN
Controller
©DaoliCloudCompany,all rightsreserved,2011—2015