OpenDaylight: Introduction, Lithium and...
Transcript of OpenDaylight: Introduction, Lithium and...
OpenDaylight: Introduction, Lithium and Beyond Colin Dixon Technical Steering Committee Chair, OpenDaylight Senior Principal Engineer, Brocade Some content from: David Meyer, Neela Jaques, and Kevin Woods
Outline • Introduc)on…
• …to SDN • …to OpenDaylight…
• …with a brief aside into YANG • New in Lithium • Plans for Beryllium
dst port
0E 6
dst port
0E 6
0A 1
dst port
0E 6
0A 1
0C 4
Traditional SDN (OpenFlow) The separation of the control and data planes • Modern switches
• Control/data plane both on switch • Data plane: fast, reads tables • Control plane: slow, writes tables
• SDN • Decouple control/data planes • Data plane on the switch • Control plane elsewhere, e.g., an x86 server, can do fancier things
Switch Chip
Control Plane CPU
Ports, 1-‐6
SDN Controller
This gets smaller, turns into
controller to switch chip translator
Most features go here
0A-‐>0E 0A-‐>0E 0A-‐>0C
Table miss, send to controller
Install table entry, send
packet
0C-‐>4
Modern, Inclusive SDN
control
mgmt
control
mgmt
control
mgmt
Vendor A Vendor B Vendor C
Logically Centralized
SDN Controller
Northbound API
Industry Standard Control/Management
Protocols Standard Modeling Language
Vendor A
control
mgmt
control
mgmt
Vendor B Vendor C
control
mgmt
What is OpenDaylight OpenDaylight is an Open Source So9ware project under the Linux Founda=on with the goal of furthering the adop)on and innova)on of So9ware Defined Networking (SDN) through the crea)on of a common industry supported plaYorm.
To create a robust, extensible, open source code base that covers the major common components required to build an SDN solu)on
Code
To get broad industry acceptance amongst vendors and users: • Using it directly or through vendor products • Vendors using OpenDaylight in commercial products
Acceptance
To have a thriving and growing technical community contribu)ng to the code base, using the code in commercial products, and adding value above, below and around.
Community
OpenDaylight Releases • Hydrogen (first release)
• February 2014 • 13 projects, 1.3m lines of code
• Helium (second release) • October 2014 • 25 projects, 2.1m lines of code
• Lithium (latest release) • June 2015 • 40+ projects, 2.3m lines of code
Model-‐Driven Service Abstrac)on Layer (MD-‐SAL)
Core Architecture
No)fica)ons
RPCs
YANG Models
Data
App/Service
App/Service
Plugin Plugin
Controllers in a Cluster
Base Network Service Functions
VTN Coordinator
DDoS Protection
SDNIWrapper
DLUX Web-based GUI
Custom Basic AuthN Filter AAA AuthN Filter Neutron AuthN
AD-SAL REST APIs MD-SAL RESTCONF (REST) APIs Neutron APIs
Topology Manager
Stats Manager
Switch Manager
Host Tracker
OpenStack(via Neutron)
OpenStack Neutron Service
OVSDB VTN Plugin2OC
Model-Driven Service Abstraction Layer (MD-SAL)API-Driven Service Abstraction Layer (AD-SAL) Clustering
Fwdng Rules Mgr
DOCSIS Service
LISPService
SDNI Aggregator
GBPService
Service Flow Chaining
L2Switch
SNBIOVSDB SNMP BGP PCEP NETCONF Plugin2OCOpenFlowPCMM/COPS LISP 1.0 1.3 TTP
OpenFlow1.0
Shared Data Models
RPCs and Notifications
AAA: Authentication, Authorization & AccountingAuthN: AuthenticationBGP: Border Gateway ProtocolCOPS: Common Open Policy ServiceDLUX: OpenDaylight User ExperienceDDoS: Distributed Denial Of Service
DOCSIS: Data Over Cable Service Interface SpecificationGBP: Group Based PolicyLISP: Locator/Identifier Separation ProtocolOVSDB: Open vSwitch DataBase ProtocolPCEP: Path Computation Element Communication ProtocolPCMM: Packet Cable MultiMedia
Plugin2OC: Plugin To OpenContrailSDNI: SDN Interface (Cross-Controller Federation)SNBI: Secure Network Bootstrapping InfrastructureSNMP: Simple Network Management ProtocolTTP: Table Type PatternsVTN: Virtual Tenant Network“Helium”
Core service wiring and dependencies
App/service-specific wiring and dependencies
Abstraction Layers
Controller Platform and Services
Southbound Interfaces and Protocol Plugins
Northbound/RESTAPIs
Authentication
Applications and Orchestration
ServicesLegend
What is YANG? • Data modeling language for NETCONF
• RFC 6020
• Great, what is NETCONF? • Think of it as an SNMP replacement with nice features • YANG models ~= SNMP MIBs
• OK, fine, but what is YANG?
What is YANG? • Three core abstrac)ons
• Data • RPCs (just data in and data out) • No)fica)ons (just data out)
• So, it’s really all about the data
DATA
What does YANG data look like • container ~= struct • list ~= map/dic)onary • leaf ~= primi)ve types • grouping ~= interface
• Others: typedef, pointers, constraints, etc.
grouping node-attributes { leaf node-id { ... } } container network-topology { list topology { key "topology-id"; leaf topology-id { type topology-id; } list node { key "node-id"; uses node-attributes; } list link { key "link-id"; uses link-attributes; } } }
OpenDaylight Community • Like any Open Source Project, OpenDaylight primarily consists of those who show up to do the work.
• Running around 250 commits per week over 12 months, trending up • 30 Days: ~625 commits, ~100 contributors (7/13/15–8/12/15; during a release)
• Spikes to ~2x this near releases • 12 Months: ~13,250 commits, ~365 contributors (8/12/14–8/12/15)
• Strong integra)on and tes)ng community • This stuff really malers
Source: https://www.openhub.net/p/opendaylight
OpenDaylight Community
New in Lithium
Major Shifts in Lithium • Depreca)on of the AD-‐SAL
• Move to MD-‐SAL: OVSDB, LISP, etc.
• OpenStack/Neutron Integra)on • Significant closing of the feature gap
• More implementa)ons • OVSDB, GBP, VPN Svc, VTN, LISP
• Service chaining/NFV • SFC project, integra)ng with GBP
• Security • Formal process defined • Handled many issues/fixes
• More on policy • NIC as a vendor-‐neutral layer • Big push on SFC+GBP
• Release process refinement • Beler documenta)on process • Beler integra)on/test process • Offsets for coordina)on
• 20+ new projects
OVSDB migration in Lithium • Split network virt. and driver • Moved both to use the MD-‐SAL • Significantly beler CI and tes)ng with OpenStack
• Aspira)ons of moving to support policy/NIC
OpenStack
Neutron (REST)
OVS
Helium
OpenFlow + OVSDB + Nicira Extensions
OpenStack
Neutron (REST)
Tunnel Mgmt
OVS
Lithium
REST/YANGAdapter
Neutron (YANG)
OVSDB Network VirtualizationNetwork virtualization layer that is still “hard-wired” to
Neutron above, but now uses more general APIs below.
OVSDBPlugin
OpenFlow+Nicira Extns?
Relevant Southbound Protocol
OpenStack
Neutron (REST)
Many h/w- and v-switches
Future
REST/YANGAdapter
Higher-Level Network Virtualization API
App
Neutron (YANG)
Neutron ODL Policy Adapter App
OVSDB Network VirtualizationNetwork virtualization layer that now uses the more
general APIs above and below.
Relevant Southbound Protocol
OVSDBThis project is a
monolithic combination of:(1) a network
virtualization layer that is “hard-wired” to Neutron above
and OVS below as well as (2) an
OVSDB protocol library.
Traffic Direction Tunnel Mgmt
OVSDBPlugin NETCONF OpenFlow
+Nicira Extns?
Traffic Direction
New Projects in Lithium • Meta
• Release Engineering -‐ autorelease • Release Engineering -‐ Builder • Controller Core Func)onality Tutorials
• Drivers • CAPWAP-‐Support • Distributed LLDP with Auto Alach Capability • Link Aggrega)on Control Protocol • Internet of Things Data Management (IoTDM)
• SNMP Plugin • Source Group Tag eXchange Protocol (SXP) • Unified Secure Channel
• Apps • Applica)on Layer Traffic Op)miza)on (ALTO) • Integra)on of Maple Programming Model • Network Intent Composi)on • Neutron Northbound
• Services • Persistence • Device Iden)fica)on and Driver Management • Discovery • Time Series Data Repository • Topology Processing Framework • VPN Service
Lithium Dependency Diagram
S3P: Security, Stability, Scalability, Performance • Goal to improve the quality of key features
• OpenFlow, OVSDB, NETCONF, MD-‐SAL, etc.
• Significant progress on OpenFlow (thanks Luis/Integra)on team) • See following slides
• Broader progress expected in Beryllium
OpenFlow flows/sec performance
hlps://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-‐csit-‐1node-‐cbench-‐performance-‐only-‐stable-‐lithium/plot/
hlps://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-‐csit-‐1node-‐cbench-‐performance-‐only-‐stable-‐lithium/plot/
OpenFlow REST flows/sec, scalability
hlps://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-‐csit-‐1node-‐config-‐performance-‐only-‐stable-‐lithium/plot/Config%20Performance/
hlps://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-‐csit-‐1node-‐periodic-‐scalability-‐daily-‐only-‐stable-‐lithium/plot/Inventory%20Scalability/
S3P To Dos OpenFlow • Stability tes)ng
• Longevity beyond an hour – Test wrilen wai)ng for infra OK
• Under different kinds of load – Summer intern will take care
• Performance in a cluster • OpenFlow doesn’t currently work in a cluster
• Scalability beyond switches • Flows, hosts, links, etc. – Host and Links tests are coming
• More SB Protocols • NETCONF – Pantheon and Carol (BRCD) will bring tests
• OVSDB – Intel working on this (asked Colin for BRCD thoughts)
• BGP • PCEP
• More NB interfaces (use cases) • Neutron • SFC
Beryllium Plans
Beryllium Releas • Focus on S3P, Migra)on, and HA/clustering
• Tries to balance maturity (the above) with feature velocity • Some projects will be mature • Some of the Karaf features in mature projects will be stable • Stable features will have S3P, Migra)on, and HA/clustering requirements • Stable and “normal” distribu)on; stable only has stable features
• Trying to drive appropriate projects/features to mature/stable
Release Plan: hlps://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan
Trying to move offset 0 projects to mature • Controller • MD-‐SAL • NETCONF • AAA • YANG Tools • odlparent