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