Your SlideShare is downloading. ×

OpenFlowHub Webinar - Indigo v2.0 and LOXI


Published on

The Big Switch team has been working overtime to develop a new version of the popular Indigo project. Indigo is an OpenFlow firmware agent for physical switches, and info on the current version can be …

The Big Switch team has been working overtime to develop a new version of the popular Indigo project. Indigo is an OpenFlow firmware agent for physical switches, and info on the current version can be found on

Why the need for a new version? We wanted to provided an extensible framework to enable switch and hypervisor vendors to implement OpenFlow agents, and provide an easier way to provide an upgrade path to supported new versions of OpenFlow.

Major new capabilities include a) a HAL abstraction layer to make it easy to integrate with the forwarding and port management interfaces of physical- or virtual- switches, b) a configuration abstraction layer to support running OpenFlow in a "hybrid" mode on your switch, c) LOXI - a marshalling/un-marshalling engine that generates OpenFlow libraries in multiple languages. Currently it generates C, but Java and Python are coming soon.

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. OpenFlowHub  Webinar  Series   Open  Source  SDN  Stack  &  Indigo  Deep-­‐dive   September  19th,  2012  
  • 2. Agenda  —  Overview  of  OpenFlowHub  projects  and  Big  Switch  —  Overview  of  Indigo  v1  —  Indigo  v2  and  LOXI   —  OpenFlow  1.x  Architectural  Challenges   —  What  is  “LOXI”   —  Indigo  2.0  Architecture   —  ImplementaPon  Status  —  Road  Map  —  How  to  get  involved  /  Q&A   2
  • 3. Big  Switch  Networks  The  Leader  in  Socware  Defined  Networking  for  the  Enterprise  Overview  —  Founded  in  2010  by  key  members  of  Stanford  SDN  Team  —  ProducPon  beta  deployments  since  2011  —  Product  revenue  since  2012  Big  Switch  is  the  Leading  Enterprise  SDN  Company  —  #1  Controller  in  the  Enterprise   —  15+  Fortune  500  Companies  are  using  BSN  Controllers  —  #1  Partnerships   —  80%  of  major  Networking  Vendors   —  Most  used  reference  controller  (e.g.  at  Interop  2012)  —  #1  by  product  partnerships   —  Key  joint  development  efforts  with  select  partners  —  We  expect  to  be  #1  by  revenue  of  pure  breed  SDN  companies  for  2012   3
  • 4. Engineering  Team  Unique  Leadership  for  SDN   —  SDN/OpenFlow   People  @  Big  Switch   —  Head  of  Stanford  OpenFlow  Lab   —  4  lead  architects  of  OpenFlow  at   Stanford   Howie  Xu   VP  Engineering   —  Lead  of  Stanford’s  ON.LAB   Head of entire VMware —  2  Post-­‐Doc’s  from  Berkeley’s  SDN  Lab   Networking Unit 2005-2011. Co- inventor of Hypervisor vSwitch.  Led UCS and Nexus 1000V —  VMware   collaboration with Cisco.   Rob  Sherwood   —  Head  of  VMware’s  Networking  Team   Architect   —  7  senior  staff  from  VMware’s   Author  of  FlowVisor  and  key  architect   of  OpenFlow  1.0   Networking  team   —  Lead  architects  of  DVS     —  Lead  architect  of  VXLan   Dan  Talayco   Architect   Former  member  of  the  Stanford   —  Networking   OpenFlow  Team.  Led  development  of   the  Indigo  reference  implementaPon   —  5  key  members  of  Nexus  1k  Team   —  Lead  of  the  N1k  for  MSFT  effort   Others  include:   Guido  Appenzeller:  Lead  author  of  OF  1.0  spec     Nick  BasPn:  Lead  dev  @  ON.Lab   4
  • 5. What  Makes  Big  Switch  Unique?  An  ecosystem  around  the  northbound  applicaPon  API   Application tier: Application! Application" Application" Application" Network Virtualization, packet brokering/ monitoring, application delivery control, firewalling… North-Bound API" Controller tier: Controller Platform " SDKs: OpenFlow, tunneling, state distribution, configuration and management, device-specific Floodlight" drivers… Switch " Switch" vSwitch" Data plane tier: vSwitch" OpenFlow-enabled Physical and Hypervisor vSwitch" switches: throughput/performance, flow table vSwitch" sizes, LAG, tunneling, L3 integration… vSwitch" vSwitch" 5
  • 6. Open  source  projects  from  Big  Switch   •  Apache-­‐licensed  OpenFlow  Controller   •  Core  of  the  Big  Switch  commercial  commercial   •  OpenStack  Quantum  plug  in   •  OpenFlow  agent  for  physical  switches   •  LOXI  -­‐  OpenFlow  Library  generator   •  ProducPon  use  in  OpenFlow  switches  today   •  TesPng  frameworks  for  Open  Flow   compaPbility  Defining an open SDN platform 6
  • 7. Indigo  1.0  ProducPon  support  for  OpenFlow  hardware  since  2009  —  OpenFlow  1.0  implementaPon  for  hardware  switches   —  Dan  Talayco  primary  author;  many  contributors  —  Released  under  OpenFlow-­‐license  (BSD-­‐like)  in  2009  —  Supports  1G  and  10G-­‐based  Broadcom-­‐chips   —  Triumph2,  Triumph3,  Scorpion,  Trident,  Trident+,  etc.  —  Rich  HAL  layer  for  portability  across  mulPple  plaqorms  —  Modest  hybrid-­‐switch  support;  only  for  control  channel  —  h"p://   7
  • 8. Indigo  1.0  Architecture   Web   OpenFlow UI   OpenFlow-­‐1-­‐0.h   Control Channel OFProtocol   CLI   OFDatapath  OpenFlow  Controller   Hardware  AbstracPon  Layer   ASIC-­‐driver  code   8
  • 9. OpenFlow  1.x  Challenges  All  implementaPons  depend  too  much  on  “openflow.h”!  —  OpenFlow  specificaPon  is  a  pdf  and  a  C  header  file   —  #include  “openflow/openflow.h”   —  PDF  is  ocen  incomplete,  must  rely  on  header  file  —  Result  #1:  Pght  coupling  between  wire  format  and  internal   data  structures  —  Result  #2:    any  change  to  the  protocol  causes   disproporPonate  code  changes  in  the  OpenFlow  agents   —  e.g.,  OF1.0  à  OF1.1  the  “port_id”  field  went  from  16  to  32  bits  —  OpenFlow  switch  development  has  stagnated  –  too  hard!     —  Affects  OpenVSwitch,  Stanford  reference  design,  Indigo,  etc.   —  PorPng  OpenFlow  to  new  languages  also  hard,  e.g.,  Java   9
  • 10. LOXI:  Logical  OpenFlow  eXtensible  Interface  LOXI  solves  the  “openflow.h”  problem  for  many  languages   Input Parser Code Gen Output openflow.h   V1.0   C   libLOXI.a   Back-­‐end   openflow.h   V1.1   LOXI   Java   LOXI.jar   Front-­‐end   Back-­‐end   openflow.h   V1.2   Python   openflow.h   Back-­‐end   V1.3   10
  • 11. LOXI  ProperPes  “Write  once  to  LOXI  interface,  works  across  all  OpenFlow”    —  LOXI  interface  hides  OpenFlow  wire  format  differences  —  In  LOXI,  write  match  on  MPLS  tag  XXX   —  OF1.0  –  returns  unsupported   —  OF1.1  –  encodes  as  OF1.1  fixed  length  match   —  OF1.2+  –  encodes  as  OF1.2  OXM-­‐style  match  —   LOXI  libraries  are  usable  by  switches  and  controllers   —  We  will  be  LOXI-­‐enabling  floodlight  as  well  —  Data  semanPcs  are  back-­‐end-­‐specific   —  libLOXI.a  works  stores  state  internally  in  the  version-­‐specific   wire  format  and  uses  “copy  on  grow”   11
  • 12. Indigo  2.0  Architecture   OpenFlow Web   Control ConnecPon   Channel ConnecPon   Instance   ConnecPon   UI   OFProtocol   OpenFlow-­‐1-­‐0.h   Instance   Instance   CLI   Config  AbstracPon  OpenFlow   OpenFlow  Core  Controller   OF     State  Manager   Config   OFDatapath   Proto   Data  Path  AbstracPon   Hardware  anager   OpenFlow   Port  M AbstracPon  Layer   Fowarding  Engine   ASIC-­‐driver  code   12
  • 13. Indigo  2.0  ProperPes    —  Apache  2.0  license  —  Wrixen  in  C  with  portability  in  mind   —  #define  MEMALLOC(bytes)  malloc(bytes)  vs.  kmalloc()   —  Not  implicitly  targeted  at  Linux-­‐only  —  DistribuPon  includes  example  datapath  drivers   —  e.g.,  pure  userspace  datapath  as  portable  reference   —  ExpectaPon  is  that  partners  will  write  their  own  ASIC  drivers  to   HAL  interface  —  Config  abstracPon  helps  integrate  with  exisPng  partner  UI’s   13
  • 14. Source  DistribuPon  Architecture   LoxiGen PackMan (Packet LOCI Manipulation) SPI VPI Indigo-2 (Software (Port abs) Architecture TCAM) Headers BigCode Libraries OF Socket Linux Manager Port Manager OF Connection Manager vSwitch UserSpace OF State Forwarding Manager Indigo Agent Core Indigo Linux Platform LRI on OVS Indigo HW LRI (planned) 14
  • 15. ImplementaPon  Status  Q3  2012  —  LOXI  with  C-­‐backend  and  Support  for  OF  1.0,  1.1,  1.2  wrixen   —  Currently  debugging  and  massaging  interface   —  Plans  for  Java  +  Python  Backend,  as  well  as  OF1.3  shortly  —  Indigo  2.0   —  HAL  interface  updated   —  Config  abstracPon:  sexled  on  ‘sysctl’-­‐like  interface   —  User-­‐space  Linux  datapath  socware  driver  wrixen   —  ConnecPon  manager  wrixen  to  LOXI  interface   —  Currently  wriPng  per-­‐message  handlers  in  LOXI  —  Very  acPve  development     15
  • 16. Roadmap  —  LOXI:   —  Create  Java  back-­‐end  for  floodlight   —  Create  Python  back-­‐end  for  OFTest  —  Indigo  2.0:   —  Pass  remaining  OFTest  tests  (hxp://   —  Add  support  for  OF  Config  Protocol   —  Add  “OVS”  datapath  compaPbility  HAL-­‐translator   —  Support  the  OVS  Linux  kernel  module   —  Support  exisPng  OVS-­‐based  hardware  ASIC  drivers   —  Extend  hybrid-­‐switch  support:  Spanning  tree-­‐protocol  —  IniPal  release  with  subset  of  above:   —  Public  release  target  soon  (subscribe  to  indigo-­‐announce)   —  Closed-­‐to-­‐partners  pre-­‐release  sooner     16
  • 17. Indigo  2.0  Linux  ImplementaPon  Proposed  IntegraPon  with  OVS  kernel  module   libLOXI Web UI CLI OpenFlow Configuration State Manager data path abstraction VPI shim Connector OVS Connector Port Forwarding Management Engine user space kernel space vswitch_mod.ko openvswitch_mod.ko Port Management Forwarding Engine 17
  • 18. ImplicaPons  for  OFTest  —  Next-­‐step:  LOXI-­‐fy  OFTest   —  Need  to  build  the  LOXI  python  backend   —  Port/merge  join  OF1.{0,1,2,3}  tests  to  LOXI  —  Increasing  interest  in  OFTest   —  Increasing  external  commixers   —  De  facto  standard  test  suite  from  ONF  TesPng  Working  Group  —  Go  to  hxp://  for  more  details   18
  • 19. Summary  —  OpenFlow  switch  implementaPons  are  Pghtly  coupled  to   openflow.h   —  EffecPvely  halted  development  —  LOXI  breaks  that  dependency  and  provides  a  future-­‐proof   common  interface  target  —  Indigo  2.0  builds  on  LOXI  and  adds:   —  ASIC  and  socware  friendly  HAL   —  ConfiguraPon  abstracPon  for  simpler  integraPon  and  OFConfig   —  Linux  reference  implementaPon  (virtual  switch  integrated  with   OVS  kernel  datapath)   19
  • 20. Complete  SDN  Stack  At  Launch   BGP Speaker" Networking" Management" Static Flow Application Plane & more" Virtual " " " •  Contributed by Open Source community •  Compatible with Big Flow Controller Standard Interface " (Rest API / Modules)" Control Plane Floodlight" •  Supported by largest community •  De facto northbound API LOXI" Data Plane Indigo-2" •  OVS (Open vSwitch) Physical •  LOXI (OpenFlow Library) Switch" OVS" •  Indigo (OF firmware agent) Testing and Simulation Tools •  OFTest 20
  • 21. Get  Involved  —  Subscribe  to  mailing  lists   —  indigo-­‐   —  Used  to  announce  new  versions  of  Indigo   —  hxp://­‐ announce/subscribe     —  indigo-­‐   —  Discuss  development  and  review  code  before  being  commixed   —  hxp://­‐dev/ subscribe  —  To  see  code  now,  contact   21