Open Networking Lab
Ali Al-Shabibi
Open Source Tools
&
Agenda
• Introduction to ON.Lab;
• Who we are?
• What we are doing?
•
ONOS Overview
ONRC Organizational Structure
Berkeley
Scott Shenker
Sylvia Ratnasamy
Open Network Lab
Exec Director: Guru Parulkar VP Eng: Bill Snow
Chief Architect: Larry Peterson
19 Engineers/Tech Leads Opensource Tools/Platforms for SDN community PhD/Postdocs Research
Stanford
Nick McKeown Guru Parulkar Sachin KattiWhy is Open Source important
Hardware substrate Software-Defined Networking Opensource Culture • Commoninstruction set like x86
• OpenFlow fits well here • Software drives innovation • Thousands of developers to shake up the industry
Team
19 full-time, 3 part-time, 4 interns SDN
C++, Java, Python Virtualization, Debugging
Distributed Systems, Hadoop, NoSQL OpenFlow, Mininet, OVX, Controllers
Networking, Routing, Optical, Operating Systems
High Availability, Scaling, Security Product Management, Test
Open Source, UI
ONOS
OVX
Mininet
OpenCloud The useless… The Management2014 Tools & Platforms Update
3rd party components Network OS Apps Apps Network OS Apps Apps Open Interfaces Open Interfaces Network Hypervisor Forwarding FlowVisor, OpenVirteXMININET, Cluster Edition ONOS
Agenda
•
Introduction to ON.Lab;
• ONOS Overview
• Who’s it for?
• How we went about it?
ONOS Target Deployment:
Service Provider Networks
• WAN core backbone
• Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE)
• Metro networks
• Metro cores for access networks • Cellular access network
• LTE for a metro area • Wired access/aggregation
• Access network for homes • DSL/Cable Core Cellular Metro Wired Access 200-500 routers 5K- 10K ports 20K-100K devices 100K-10M+ ports 10K-50K routers 2M-3M+ ports 10K-50K devices 100K- 1M+ ports
Key Performance Requirements
for Core Backbone Network
Network
ONOS
Application Application High Throughput ~500K - 1M path installation/sec Low Latency ~10 - 100ms ~200GB - 1TB And will grow…We decided to build a distributed NOS
to meet these performance requirements
Global Network View/State
~3-6M Network State op/sec
Can One Build Distributed Network OS
Stacking Open-Source Blocks?
It’s kinda possible… and we kinda did
Distributed Network OS with
Simple Scale-Out
Controller Instance 1 Instance 2 Instance 3
Data plane
Network Graph
Global network view
Control Application Control Application
Interconnection (e.g. 10G Ethernet)
Cassandra
Distributed Key-Value Store
Titan Graph DB
Network Graph (Eventually consistent)
ONOS Architecture –
Commodity components
Instance 1 OpenFlow Manager+ Instance 2 OpenFlow Manager+ Instance 3 OpenFlow Manager+ + Floodlight Drivers
Control Application Control Application
Scale-out Distribu ted Regist ry (Str o n g ly C o n si sten t) Zo oke epe r Coordi natio n Distributed Network Graph/State
Applications Blueprints API
14
Host
Host Host
Can One Build Distributed Network OS
Stacking Open-Source Blocks?
Good for rapid prototyping
BUT …
Lacks performance and
performance visibility
Why Is It Hard To Get Performance
Using Off-The-Shelf Software?
• Complex off-the-shelf open source
components
• Difficult to get visibility under the hood
Cassandra
Distributed Key-Value Store
Titan Graph DB
In-memory Network Graph (eventually consistent)
Host
Host Host
Instance 1 Instance 2 Instance 3
OpenFlow Manager+ OpenFlow Manager+ OpenFlow Manager+ + Floodlight Drivers Control Application Di str ibuted Regist ry (Str o n g ly Co nsi st ent) Z o o kee p er Control Application Scale-out Coordi natio n Distributed Network Graph/State
Applications ONOS Graph API
Indexing
ONOS Graph Abstraction
RAMCloud
Ultra-low latency distributed data store in DRAM
Ev ent Not ificati ons Ha ze lcast
ONOS Today
0.01 0.1 1 10 100 1000 April 2013 Cassandra Jan 2014 RAMCloud Feb 2014 RAMCloud + New Data Model
Feb 2014 RAMCloud + New Data Moldel
+ Kernel Bypass + Infiniband Latency [ms] (log scale) (*) (*)
Add Switch (w/ 4 ports) Add Link
Network State Updates
0.075 0.099 0.15 0.244 0.722 22.205 Kernel Bypass w/ Infiniband
ONOS Conclusion
• After 3 major architectural revisions ONOS is on a track to deliver a distributed OS with features as well as
performance
• Off-the-shelf open source components light-weight with optimizations and custom components
• 10-100x improvement in performance
• ON.Lab will do an open-source release and demonstration of several use cases in 2014
Agenda
•
Introduction to ON.Lab;
• Who we are?
• What we are doing?
•
ONOS Overview
•
OpenVirtex Overview
• What is it?
• Why was it created?
Why Network Virtualization?
• Enables multi-tenancy
• Decouples the physical network from the virtual network
• Allows security and
Why build OpenVirteX
• OpenVirteX enables network virtualization of OpenFlow Networks • Complementary to FlowVisor • OpenVirteX brings SDN to Virtual Networks• Each virtual network
• Separation of data and control • Logically centralized control
plane
• Programmability
OpenVirteX
NOS NOS NOS
OpenFlow Network
Cloud Internet
IP X IP Y IP Z IP T
Clients
Use Case
Use Case
Enterprise Network Migration to Cloud
Cloud Infrastructure Network OpenVirteX
OpenVirteX Architecture
Bump in wire • Building on our FlowVisor
experience
• Enables programmability of virtual networks
• Idea is to empower users to control and define behaviour of their virtual network
• Bump in control channel, thus OVX must be as efficient as possible
OpenVirteX
OpenFlow Network
NOS NOS NOS
OpenFlow
OpenVirteX Architecture
Design your own network
Embedder OpenVirteX Virtual Network Spec Virtual to Physical Mapping
OpenVirteX Architecture
LLDP Discovery LLDP Resolution Map Southbound OpenFlow Interface Northbound OpenFlow Interface Switch message handling NOS Message Handling Switch IO Loop NOS IO Loop Network Link Address vSwitch Port Virtual Network Link Address Switch Port Physical APIOpenVirteX Features
Topology Virtualization Physical Network Map LLDPLLDP Virtual Networks Network OS Network OS LLDP LLDP Physical NetworkOpenVirteX Features
Address Virtualization
• Tenant IPs are rewritten in order to avoid dataplane collisions
• The rewriting inserts a tag to enable OVX to identify the packets owner
• Rewriting process is
completely transparent to NOS and end hosts
Tenant Network OS OpenVirteX Virtual IP Physical Network Tenant VM Virtual IP Virtual IP Tenant VM Physical IP Physical IP Physical IP Edge Switch
• Each tenant has his own programmable virtual network
• Each virtual network behaves like an
OpenFlow network
• Thus, the tenant’s NOS can do traffic
engineering, some fancy routing, etc.
OpenVirteX
NOS NOS NOS
OpenFlow Network
OpenVirteX Features
• Giant Switches behave like normal OF switches • If a link goes down,
OpenVirteX can route around the failure
• Can be done similarly for virtual links
OpenVirteX Features
Giant Switch Resiliency
Next Steps
• Upcoming Features:
• Virtual Network pausing
• Virtual Network Snapshotting and Migration
• External Connectivity (as well as inter virtual networks)
• Support for 1.x (both north and south bound) • General Purpose embedder
OpenVirteX Conclusion
• OpenVirteX is an OpenFlow Network
Virtualization platform which:
• Supports dynamic creation of virtual networks
• Provides the ability to specify the topology as well as the addressing to be used
