Open Source Tools & Platforms Open Networking Lab Ali Al-Shabibi
Agenda Introduction to ON.Lab; Who we are? What we are doing? ONOS Overview OpenVirtex Overview
ONRC Organizational Structure Berkeley Scott Shenker Sylvia Ratnasamy PhD/Postdocs Research Stanford Nick McKeown Guru Parulkar Sachin Katti 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
Why is Open Source important Hardware substrate Common instruction set like x86 OpenFlow fits well here Software-Defined Networking Opensource Culture Software drives innovation Thousands of developers to shake up the industry
Team The Management useless ONOS 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 OpenCloud Mininet OVX 19 full-time, 3 part-time, 4 interns
2014 Tools & Platforms Update 3 rd party components Apps Apps Apps Apps SDN-IP Peering Open Interfaces Network OS Network OS Network Hypervisor ONOS FlowVisor, OpenVirteX Open Interfaces Forwarding MININET, Cluster Edition
Agenda Introduction to ON.Lab; ONOS Overview Who s it for? How we went about it? OpenVirtex Overview
ONOS Target Deployment: Service Provider Networks WAN core backbone Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) 200-500 routers Metro networks 5K- 10K ports Metro cores for access networks Cellular access network LTE for a metro area Wired access/aggregation Access network for homes DSL/Cable 20K-100K devices 100K-10M+ ports Cellular 10K-50K devices 100K- 1M+ ports Metro Wired Access Core 10K-50K routers 2M-3M+ ports
Key Performance Requirements for Core Backbone Network High Throughput ~500K - 1M path installation/sec ONOS Application ~3-6M Network State op/sec Global Network View/State Application We decided to build Network a distributed NOS to meet these performance requirements ~200GB - 1TB And will grow Low Latency ~10-100ms
Can One Build Distributed Network OS Stacking Open-Source Blocks? It s kinda possible and we kinda did BUT
Distributed Network OS with Simple Scale-Out Control Application Interconnection (e.g. 10G Ethernet) Control Application Network Graph Global network view Interconnection (e.g. 10G Ethernet) Controller Instance 1 Instance 2 Instance 3 Data plane
Distributed Registry (Strongly Coordination ONOS Architecture Commodity components Applications Distributed Network Graph/State Scale-out Consistent) Zookeeper Control Application Network Graph (Eventually consistent) Instance 1 OpenFlow Manager + Control Application Titan Graph DB Cassandra Distributed Key-Value Store Instance 2 OpenFlow Manager + Blueprints API Instance 3 OpenFlow Manager + Host + Floodlight Drivers Host 14 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 Difficult to tweak for custom optimizations
ONOS Today Distributed Registry (Strongly Coordination Event Notifications Hazelcast Applications Distributed Network Graph/State Scale-out Consistent) Zookeeper Control Application Control Application In-memory Network Graph (eventually consistent) ONOS Graph Abstraction Titan Graph DB RAMCloud Cassandra Distributed Key-Value Store Ultra-low latency distributed data store in DRAM ONOS Graph API Indexing Instance 1 Instance 2 Instance 3 OpenFlow OpenFlow OpenFlow Manager + Manager + Manager + Host + Floodlight Drivers Host Host
Network State Updates Latency [ms] (log scale) 1000 100 10 1 0.1 (*) (*) 22.205 0.722 0.244 Add Switch (w/ 4 ports) Add Link 0.15 0.099 0.075 0.01 April 2013 Cassandra Jan 2014 RAMCloud Feb 2014 Feb 2014 RAMCloud RAMCloud Kernel Bypass + New Data Model + New w/ Infiniband Data Moldel + Kernel Bypass + 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? Built in collaboration with CREATE-NET
Why Network Virtualization? Enables multi-tenancy Decouples the physical network from the virtual network Allows security and isolation of the users traffic
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 NOS NOS NOS OpenVirteX OpenFlow Network
Internet Use Case Enterprise Network Migration to Cloud Clients Cloud IP X IP Y IP Z IP T
Use Case Enterprise Network Migration to Cloud IP X IP Y IP Z IP T OpenVirteX Cloud Infrastructure Network
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 NOS NOS NOS OpenFlow OpenVirteX OpenFlow OpenFlow Network
OpenVirteX Architecture Design your own network Virtual Network Spec Embedder Virtual to Physical Mapping OpenVirteX
Network vswitch Network Switch OpenVirteX Architecture Virtual Address Map Physical Address Link Port Link Port Northbound OpenFlow Interface NOS IO Loop Switch IO Loop Southbound OpenFlow Interface LLDP Resolution NOS Message Handling Switch message handling LLDP Discovery API
OpenVirteX Features Topology Virtualization LLDP Network OS Network OS Virtual Networks LLDP Physical Network Map LLDP LLDP Physical Network
OpenVirteX 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 VM Edge Switch Virtual IP Physical IP Tenant Network OS Virtual IP OpenVirteX Physical IP Physical Network Physical IP Tenant VM Virtual IP
OpenVirteX Features Control Function Virtualization 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. NOS NOS NOS OpenVirteX OpenFlow Network
OpenVirteX Features Giant Switch Resiliency 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 Giant Switch
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 HA and Scaling
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 OpenVirteX will be released in Q2 14 Contributions to OpenVirteX will be welcomed and greatly appreciated
The End finally. Small teams can do amazing things Opensource is fundamental for changing the ossified field of networking AT&T, CIENA, NEC, ERICSSON, amongst others are supporting our efforts to build ONOS and OVX
Questions? Thanks! ali@onlab.us