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 http://indigo.openflowhub.org. 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. 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://indigo.openflowhub.org
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
LOXI.py
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://ocest.openflowhub.org)
— 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://ocest.openflowhub.org
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-­‐announce@openflowhub.org
— Used
to
announce
new
versions
of
Indigo
— hxp://groups.google.com/a/openflowhub.org/group/indigo-­‐
announce/subscribe
— indigo-­‐dev@openflowhub.org
— Discuss
development
and
review
code
before
being
commixed
— hxp://groups.google.com/a/openflowhub.org/group/indigo-­‐dev/
subscribe
— To
see
code
now,
contact
paul@bigswitch.com
21